Overview
The CLI enables CI/CD workflows for:- Resource provisioning - Apply GVC, workload, and infrastructure configurations
- Image delivery - Build and push container images to Control Plane
- GitOps - Maintain infrastructure as code in version control
Quick start
Create a service account
Create a service account with appropriate permissions for your pipeline.See Create a Service Account for details.
Store credentials and context
Generate a key and store these environment variables in your CI/CD platform:
CPLN_TOKEN- The service account key (required)CPLN_ORG- Your organization name (recommended)CPLN_GVC- Your target GVC name (recommended)
Install the CLI
Install a pinned version of the CLI in your pipeline:
- npm
- Binary
Pin the CLI version for reproducible builds.
Service account setup
Create the service account
- Console
- CLI
- Navigate to Org → Service Accounts
- Click Create
- Enter a name (e.g.,
ci-pipeline) - Assign to a group with appropriate permissions (e.g.,
superusersor a custom group)
Generate a key
Create an authentication key for the service account:- Console
- CLI
- Open the service account you created
- Click the Keys link
- Enter a key description (e.g.,
ci-pipeline-key) and click Add - Copy and download the generated key securely
CPLN_TOKEN.
Environment variables
Set these variables in your CI/CD platform:Required
CPLN_TOKEN- Service account key (keep secret)
Optional but recommended
CPLN_ORG- Default organizationCPLN_GVC- Default GVC
Common pipeline workflows
Build and push images
cpln image build runs the build locally through Docker — a Dockerfile build shells out to docker buildx build, and a buildpacks build runs the pack CLI — so the runner needs a working Docker daemon, and --push requires docker-credential-cpln on PATH (installed alongside the CLI). On runners without a daemon (for example, GitLab runners without privileged Docker-in-Docker), build with a daemonless tool such as kaniko or buildah and push directly to the org registry instead: the registry is <org>.registry.cpln.io, the username is the literal string <token>, and the password is the service account key.Apply resources (GitOps)
Resource ordering
Resource ordering
A single
cpln apply invocation orders resources automatically — agent, secret, cloudaccount, gvc, identity, volumeset, policy, workload, then all remaining kinds — so a workload and the GVC it references can live in the same file (or directory) in any order.Ordering only matters across separate cpln apply invocations: if you split resources into multiple pipeline steps, apply the referenced resource (e.g., the GVC) before the resource that references it.Multi-document YAML
Multi-document YAML
Separate multiple resources with Apply with:
--- in a single file:Handling renames
Handling renames
Renaming a resource in YAML creates a new resource. The old resource must be deleted manually:
Export existing resources
Export “known good” configurations as templates for GitOps:- Console
- CLI
Use the Export action to download JSON or YAML.
Use
json-slim or yaml-slim to remove non-essential properties like IDs, versions, and timestamps. This gives you only what’s necessary for applying the resource with cpln apply.Platform-specific examples
Complete working examples for popular CI/CD platforms:GitHub Actions
Full workflow with build, push, and apply
GitLab CI
Pipeline configuration for GitLab
Bitbucket Pipelines
Bitbucket pipeline with Docker build
CircleCI
CircleCI config with multi-stage workflow
Google Cloud Build
Cloud Build with Secret Manager
Best practices
Pin the CLI version
Pin the CLI version
Specify an exact CLI version for reproducible builds:Update the version explicitly when you want to adopt new features.
Use dedicated service accounts
Use dedicated service accounts
Create separate service accounts for different environments:
ci-devfor developmentci-stagingfor stagingci-productionfor production
Store secrets securely
Store secrets securely
- Use your CI/CD platform’s secret manager
- Never commit tokens to version control
- Rotate service account keys regularly
- Avoid printing
CPLN_TOKENin logs
Test in non-production first
Test in non-production first
Apply changes to development or staging environments before production:
Use slim output for templates
Use slim output for templates
Export resources with This creates clean templates suitable for version control and
yaml-slim or json-slim to remove metadata:cpln apply.Troubleshooting
Authentication failures
Authentication failures
- Verify
CPLN_TOKENis set correctly in your CI/CD secrets - Check the token hasn’t expired or been revoked
- Ensure the service account has the required permissions
Wrong org or GVC
Wrong org or GVC
Verify that the Or set in the profile:
CPLN_ORG and CPLN_GVC environment variables are set correctly.Or explicitly set org and GVC in commands:For more troubleshooting help, see the Troubleshooting page.
Next steps
Container Images
Use the CLI inside container images
Profiles
Learn about profile management
cpln apply
GitOps resource management guide
Service Accounts
Create and manage service accounts