Using it in a pipeline

debesis-ccp was built for this and nothing else: no prompts, no sessions, no browser. Everything below assumes CCP_API_URL and CCP_API_TOKEN are set from your CI credential store.

Start every pipeline with whoami

debesis-ccp whoami

It costs one call and turns the two most common failures into an immediate, legible error: an expired token exits 3, and a token missing a scope exits 4. Without it, both surface later as a confusing failure in whichever step happened to need the permission.

Gate on registry quota before you push

debesis-ccp registry-quota --fail-if-blocked

This reports your registry storage cap and usage, and with --fail-if-blocked it exits non-zero when you are over. Run it before the image build, not after: failing in five seconds is better than failing after a fifteen-minute build that had nowhere to go.

Redeploy with a new image

debesis-ccp redeploy --service 31 --image-tag registry.example.com/payments/api:$BUILD_NUMBER

How the delta model works

This is the subtlest part of the CLI and worth understanding before you rely on it.

redeploy copies the service’s latest revision and applies only the deltas you name. Anything you do not mention is replayed verbatim. So the command above changes the image tag and nothing else — replicas, probes, resources and environment all carry over exactly as they were.

Within that:

• --env KEY=VALUE and --secret NAME=ID are merged into the carried-over maps, not substituted for them. Removing something takes an explicit --unset-env KEY or --unset-secret NAME.
• Scalars — --sku, --cpu, --memory, --min-replicas, --max-replicas, --liveness-path, --readiness-path, --probe-protocol, --description — override the carried-over value.
• Key material is never replayed.

The practical consequence: a pipeline that only ships new images never has to restate the service’s whole configuration, and therefore cannot silently reset a setting somebody changed in the console.

Redeploy a managed service

Cache, messaging and SQL instances have their own redeploy verb. It is not the command above — that one is compute — and SQL’s is not the same as the other two.

Cache and messaging: latest revision plus deltas

debesis-ccp cache redeploy --service 44 --sku 9
debesis-ccp messaging redeploy --service 51 --template 17

The same idea as compute: the instance’s latest revision is copied, and only the flags you name are applied — --template, --sku, --cpu, --memory, --disk, --description, plus --maxmemory-policy on cache. Everything else is replayed from the stored spec.

It reads the latest revision, not the latest ready one. A revision row is written when a deploy is dispatched, before the instance reports ready, so an instance that never came up still has one — which is exactly the situation you need to redeploy out of.

Your key is never replayed. The platform strips key material before it stores a spec, so --kek (or CCP_API_KEK) has to be present on the redeploy just as it was on the create.

SQL: a resurrection, not a redeploy

debesis-ccp sql redeploy --service 37

This one takes no overrides at all, and that is deliberate rather than unfinished. It brings the instance back onto its own retained data, carrying nothing but your key. A populated data directory already dictates the instance’s name, its sizing and its credentials — offering flags to change them would be offering a lie.

So resizing a SQL instance is the separate expand operation, and a different tier is a new instance. Neither one is a redeploy.

The same thing from create

Cache and messaging also take --service-id on create, which redeploys that instance in place instead of creating one. Both paths call the same endpoint; redeploy is just the clearer way to say it. SQL’s create has no --service-id at all — its in-place path is the resurrection above.

Machine-readable output

Any API command takes --json:

debesis-ccp services --env 21 --type compute --json > compute-services.json

Jenkins

pipeline {
  agent any
  environment {
    CCP_API_URL   = 'https://api.debesis.dev'
    CCP_API_TOKEN = credentials('ccp-payments-token')
  }
  stages {
    stage('Token is valid and scoped') {
      steps { sh 'debesis-ccp whoami' }
    }
    stage('Room in the registry?') {
      steps { sh 'debesis-ccp registry-quota --fail-if-blocked' }
    }
    stage('Redeploy with the freshly built image') {
      steps {
        sh "debesis-ccp redeploy --service 31 --image-tag registry.example.com/payments/api:${env.BUILD_NUMBER}"
      }
    }
    stage('Archive what is running') {
      steps {
        sh 'debesis-ccp services --env 21 --type compute --json > compute-services.json'
        archiveArtifacts artifacts: 'compute-services.json'
      }
    }
  }
}

GitLab CI

deploy:
  image: python:3.12-slim
  variables:
    CCP_API_URL: https://api.debesis.dev
  before_script:
    - curl -fsSL https://docs.debesis.dev/cli/debesis-ccp -o /usr/local/bin/debesis-ccp
    - curl -fsSL https://docs.debesis.dev/cli/debesis-ccp.sha256 -o /tmp/sum
    - (cd /usr/local/bin && sha256sum -c /tmp/sum)
    - chmod +x /usr/local/bin/debesis-ccp
  script:
    - debesis-ccp whoami
    - debesis-ccp redeploy --service 31 --image-tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

CCP_API_TOKEN comes from a masked, protected CI/CD variable — never from the file above.

GitHub Actions

name: deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      CCP_API_URL: https://api.debesis.dev
      CCP_API_TOKEN: ${{ secrets.CCP_API_TOKEN }}
    steps:
      - name: Install debesis-ccp
        run: |
          mkdir -p "$RUNNER_TEMP/bin"
          curl -fsSL https://docs.debesis.dev/cli/debesis-ccp -o "$RUNNER_TEMP/bin/debesis-ccp"
          curl -fsSL https://docs.debesis.dev/cli/debesis-ccp.sha256 -o "$RUNNER_TEMP/sum"
          (cd "$RUNNER_TEMP/bin" && sha256sum -c "$RUNNER_TEMP/sum")
          chmod +x "$RUNNER_TEMP/bin/debesis-ccp"
          echo "$RUNNER_TEMP/bin" >> "$GITHUB_PATH"

      - name: Token is valid and scoped
        run: debesis-ccp whoami

      - name: Room in the registry?
        run: debesis-ccp registry-quota --fail-if-blocked

      - name: Redeploy with the freshly built image
        run: debesis-ccp redeploy --service 31 --image-tag "$IMAGE:$GITHUB_SHA"
        env:
          IMAGE: registry.debesis.dev/acme/api/prod/api

CCP_API_TOKEN is a repository or environment secret. The runner already has python3, so there is nothing else to install.

Pin the version if a pipeline must not move

https://docs.debesis.dev/cli/debesis-ccp always serves the current release. Every release is also published at an immutable path that carries its version — /cli/v<version>/debesis-ccp — so a pipeline that should never change underneath you can fetch that one instead. The version in this release is at the top of the command reference.

Working with your own encryption key

If you supply your own key, set CCP_API_KEK from your secret store and the CLI uses it for operations on encrypted values:

debesis-ccp secret set --env 21 --name DB_PASSWORD --value-stdin < /run/secrets/db

Prefer --value-stdin over --value so the plaintext never appears in a process list or a shell history file. The same applies to the key itself: --kek-stdin exists for the same reason.

Debesis cannot recover your key. That is what makes the guarantee real — with a customer-supplied key, nobody here can decrypt these values either.