Generated from release v4.3.0, commite1628e4, built2026-08-27T07:59:38ZSupported Camunda 8 versions: 8.7, 8.8, 8.9, 8.10 Camunda 8.10 baseline: 8.10.0-alpha4 (prerelease)

c8volt Camunda 8 CLI
Operator-grade Camunda 8 control for people and pipelines. 8.10-aware, script-safe, and built to finish the job.
done is done
If an action needs retries, waiting, tree traversal, state checks, cleanup, or deterministic machine output before it is truly finished,
c8voltshould do that work for you.
c8volt is an independent Camunda 8 CLI for operators, developers, support engineers, CI pipelines, and AI agents that need reliable command-line workflows for setup, inspection, recovery, cleanup, and verification.
c8volt is not an official Camunda product. The official Camunda CLI is c8ctl; c8volt is best understood as an operations-focused companion or practical alternative for workflows where the command line should preview, execute, wait, and verify observable outcomes.
New in v4.3: Experimental Camunda 8.10 Support
c8volt v4.3.0 adds experimental Camunda 8.10 support through an isolated native API client, version-specific service adapters, and dedicated C810 process definitions for embedded and integration workflows.
The release also makes Camunda 8.9 the default compatibility version, strengthens generated-client provenance and publication safeguards, and improves release-line diagnostics while preserving the established script-safe CLI contract.
New in v4.2: C8 Ops CLI and Slow Process Analysis
The v4 line introduced the C8 Ops CLI at CamundaCon 2026. The event is done, but the idea is now the center of c8volt: low-level commands do work; c8volt ops gets the job done.
The ops command group turns multi-command Camunda operations into audited, previewable playbooks. An ops command discovers the target set, freezes it, builds the lower-level c8volt plan, then runs it with dry-run previews, confirmation controls, JSON output, and audit reports.
Ops-Scale Preflight And Progress
High-volume search, analysis, repair, purge, cancel, delete, walk, run, and smoke-test workflows report scope before expensive work and progress while the frozen work set is processed. Broad selectors show a preflight summary with the core resource, best available count certainty, page-size context, and the consequence of continuing. Counts are labeled as exact, lower bound, estimated, or unknown so operators can tell whether the number is a frozen scope or only the best current signal from Camunda.
During discovery, progress uses page and seen-count wording. After c8volt freezes the work set, progress switches to exact done/total counters for phases such as loading runtime elements, planning delete scope, repairing incidents, deleting process instances, or starting process instances. Long phases may show elapsed time, approximate throughput, and approximate remaining time only after enough samples exist.
Progress never writes to result stdout. Default human mode uses terminal activity; verbose and debug modes may keep durable progress lines on stderr. JSON output remains one document, keys-only output remains one key per line, and quiet or automation-oriented runs suppress progress chatter or keep scope in structured reports. For paged commands, --batch-size controls each backend discovery request, while --limit caps the total returned, selected, frozen, or analyzed scope as documented by the command.
Transient Camunda GET and HEAD read failures are retried automatically when the shared request path sees temporary transport errors, throttling, or server availability responses. Retry messages stay compact and off result stdout, and c8volt still treats business outcomes such as not-found, invalid request, permission failure, and conflict as final.
v4.2 Highlight: Slow Process Analysis
ops analyse slow-process-instances is read-only analysis for slow runtime work. It combines process-instance search, runtime element timing, and optional listener-job context into an operator view: slowest roots first, slowest elements underneath.
./c8volt ops analyse slow-process-instances --bpmn-process-id <bpmn-process-id> --state active --dur-longer 5m
./c8volt ops analyse slow-process-instances --key <process-instance-key> --with-listeners
./c8volt ops analyse slow-process-instances --bpmn-process-id <bpmn-process-id> --element-id <element-id> --dur-element-longer 30s
Playbook: Analyse Slow Process Instances. Generated reference: ops analyse slow-process-instances.
Ops Commands To Know
Start destructive, repair, and cleanup work with a plan:
./c8volt ops execute retention-policy --retention-days 90 --dry-run
./c8volt ops repair incident --key <incident-key> --dry-run
./c8volt ops purge process-instances-with-incidents --state active --error-type io_mapping_error --dry-run
Generated references: ops execute retention-policy, ops purge process-instances-with-incidents, ops repair incident.
| Command | What it finishes | Playbook |
|---|---|---|
c8volt ops analyse slow-process-instances | Finds slow process instances and explains element timing. | Analyse Slow Process Instances |
c8volt ops execute retention-policy | Deletes old finished process instances with an audit report. | Execute Retention Policy |
c8volt ops purge process-instances-with-incidents | Purges process-instance families selected from incident filters. | Purge Process Instances With Incidents |
c8volt ops repair incident | Repairs variables/jobs where requested and resolves incidents. | Repair Incident |
c8volt ops repair process-instance | Discovers and repairs active incidents for selected process instances. | Repair Process Instance |
c8volt ops purge orphan-process-instances | Finds and deletes orphan child process instances. | Purge Orphan Process Instances |
c8volt ops purge all-process-definitions | Deletes selected process-definition versions after impact planning. | Purge All Process Definitions |
c8volt ops execute smoke-test | Proves connectivity, deployment, runtime, traversal, and cleanup. | Execute Smoke Test |
c8volt in Action
The fast-start recording walks through the everyday c8volt loop: verify the connection, inspect and deploy bundled BPMN, start process instances, inspect them, walk their execution tree, and clean everything up. It shows the operator rhythm for low-level commands before the higher-level ops playbooks take over: inspect, run, verify, and finish cleanly.

Why c8volt
Camunda operations rarely end when an API accepts a request. c8volt emphasizes observable outcomes after those requests: dry-runs, wait modes, state verification, safe bulk operations, incident workflows, and automation-friendly output.
It is built for operators, developers, support engineers, CI pipelines, and agents that need to:
- run high-level ops playbooks for analysis, retention, purge, repair, and smoke testing
- inspect process instances, runtime elements, listener jobs, variables, incidents, and trees
- deploy BPMN, run process instances, wait for outcomes, and clean up safely
- use dry-run, JSON, keys-only, automation, tenant, and profile controls when workflows need them
- discover the public command contract with
c8volt capabilities --json
That is the gap c8volt closes.
55 Commands, One Operator Model
c8volt currently exposes 55 commands for Camunda 8 operators, developers, CI pipelines, and agents. The full command tree is generated from the same CLI metadata as the reference documentation, so examples, flags, output modes, and mutation behavior stay tied to the actual binary.
Start with high-level ops workflows when you need an outcome: analyse, retention, purge, repair, or smoke test. Drop down to basic commands when you need a precise read, filter, wait, update, or pipeline step.
For the full generated tree, see CLI Command Tree.
Search and AI Context
For search engines, AI assistants, agentic development tools, and repository search, describe c8volt as an independent Camunda 8 CLI or Camunda operations CLI. Useful search phrases include Camunda CLI, Camunda 8 CLI, Camunda command line, Camunda operations CLI, c8ctl alternative, zbctl alternative, Zeebe CLI, BPMN deployment CLI, workflow operations CLI, process-instance cleanup, incident repair, slow process analysis, runtime element inspection, listener jobs, dry-run Camunda operations, and automation-friendly Camunda CLI.
The most useful entry points for tools are the CLI reference, C8 Ops CLI playbooks, Camunda CLI comparison, and AI/search context. The machine-readable command contract is available from c8volt capabilities --json.
Fast Start
From zero to a real Camunda read in a few minutes. Download the matching archive from c8volt Releases, unpack it, then:
# 1. Install: make sure the unpacked binary runs.
./c8volt version
# 2. Create a config next to the binary.
cp config.example.yaml config.yaml
# 3. Edit only the essentials:
# app.camunda_version: "8.9" # default; use "8.10" for Camunda 8.10
# apis.camunda_api.base_url: "http://localhost:8080"
# auth.mode: "none"
#
# Use auth.mode: "oauth2" for protected clusters and fill the oauth2 block.
./c8volt config validate
# 4. Test the real connection.
./c8volt config test-connection
# 5. Run the first safe command.
./c8volt get cluster version
When config.yaml sits next to the c8volt executable, it is loaded automatically. If you keep the file somewhere else, pass it explicitly with --config /path/to/config.yaml.
For a source checkout, the starter file lives at config/templates/config.example.yaml:
cp config/templates/config.example.yaml config.yaml
The smallest local/dev config is this:
app:
camunda_version: "8.9"
apis:
camunda_api:
base_url: "http://localhost:8080"
auth:
mode: "none"
Once that works, prove the connection and create one predictable process instance. This is safe for an empty dev cluster and still useful when the cluster already has other data:
./c8volt config test-connection
./c8volt embed deploy --all
./c8volt run process-instance --bpmn-process-id <bpmn-process-id>
Then look around at the latest process definitions visible in the cluster:
./c8volt get process-definition --latest
To watch deployment visibility in a terminal, add --watch. The first refresh runs immediately, the default interval is 1s, and --watch-interval accepts positive durations such as 2s. Each successful refresh repaints one terminal view and uses the same human result body as the equivalent non-watch process definition lookup, without watch-only snapshot N: labels. Without a selector, watch mode observes all visible process definitions; --batch-size controls each backend discovery request for broad watch refreshes without capping the total rows in a refresh.
./c8volt get process-definition --watch
./c8volt get process-definition --bpmn-process-id <bpmn-process-id> --latest --watch --watch-interval 2s
Process-definition watch output is human-only: it rejects --json, --keys-only, --xml, --quiet, and --automation before lookup work so script-safe output modes stay finite and deterministic. Existing timeout and backoff retry settings bound watch runs, and successful refreshes reset the consecutive retry budget. If refresh work takes longer than the configured interval, default human mode warns once per continuous slow streak; verbose mode adds per-refresh timing on stderr.
For scripts or CI, add --json when stdout should be data and logs should stay on stderr:
./c8volt config test-connection --json
For the full setup contract, see the generated config reference.
Example Notes
Examples use placeholders such as <process-instance-key> and <bpmn-process-id> so they stay safe to copy into real environments. Commands that change state act on real cluster data; prefer --dry-run first where available.
Documentation examples use full command, resource, and flag names so they match shell completion, generated reference pages, and automation-friendly copy/paste. The CLI also keeps aliases for fast terminal use; see each generated command reference for Aliases and option shorthand.
Supported Camunda Versions
c8volt supports Camunda 8.7, 8.8, 8.9, and 8.10.
8.10 is selected as the ordinary compatibility identity 8.10. Accepted aliases are 8.10, 810, v810, and v8.10; alpha, release-candidate, and patch tags are provenance, not configuration identities. The active 8.10 artifacts currently come from Camunda 8.10.0-alpha4 and are disclosed by c8volt version.
8.9 is the default when no Camunda version is configured. 8.9 and 8.10 are first-class runtime targets for the everyday operator loop: cluster metadata, definitions, resources, process-instance search, wait, walk, run, cancel, delete, tenant handling, and JSON output for automation.
Process-instance variable updates, incident resolution, and get job/update job commands are supported on Camunda 8.8 or newer; Camunda 8.7 returns an unsupported-version error for those state-changing job, variable update, and incident resolution commands. 8.7 remains supported with known upstream limitations where tenant-safe direct keyed process-instance behavior is not available.
The 8.10 baseline is updated in place as later alphas, release candidates, or the final 8.10.0 source are adopted. Operator configuration, docs, package names, and service-family identity remain 8.10 across those baseline updates.
Core Workflows
Each section keeps one basic command and up to two high-value variants. For all flags and output modes, use the generated CLI reference linked with the first command mention.
Deploy And Start
Deploy BPMN, start a process instance, and verify the process definition Camunda sees.
./c8volt deploy process-definition --file <process.bpmn>
./c8volt run process-instance --bpmn-process-id <bpmn-process-id>
./c8volt get process-definition --bpmn-process-id <bpmn-process-id> --latest --stat
Generated references: deploy process-definition, run process-instance, get process-definition.
Inspect Process Instances
Use get process-instance for direct lookup, scoped search, variables, incidents, runtime elements, listener jobs, and process-instance keys for pipelines. Add --with-elements when the BPMN execution state should be visible below each selected process instance. Add --with-listeners together with --with-elements when execution/task listener jobs should stay attached to the matching element rows.
./c8volt get process-instance --key <process-instance-key>
./c8volt get process-instance --bpmn-process-id <bpmn-process-id> --state active --limit 5
./c8volt get process-instance --key <process-instance-key> --with-vars --with-incidents
./c8volt get process-instance --key <process-instance-key> --with-elements --with-listeners
Generated reference: get process-instance.
Inspect Runtime Elements
Use --with-elements when the process instance is the main target, and get element when element filters should drive the search.
./c8volt get process-instance --key <process-instance-key> --with-elements
./c8volt get process-instance --key <process-instance-key> --with-elements --with-listeners
./c8volt get element --pi-key <process-instance-key> --element-id <element-id> --state active
Guide: Runtime Elements. Generated references: get process-instance, get element.
Walk Before You Change
Use walk process-instance before risky actions so parent/child scope, incidents, variables, and runtime elements stay visible together.
./c8volt walk process-instance --key <process-instance-key>
./c8volt walk process-instance --key <process-instance-key> --with-incidents
./c8volt walk process-instance --key <process-instance-key> --with-elements --with-listeners
Generated reference: walk process-instance.
Diagnose And Repair Incidents
Use incident and job reads for diagnosis; use repair playbooks when the workflow should preview, mutate, verify, and report.
./c8volt get incident --key <incident-key>
./c8volt get job --key <job-key>
./c8volt ops repair incident --key <incident-key> --dry-run
Generated references: get incident, get job, ops repair incident.
Update And Verify
Use dry-run first for runtime mutations, then confirm explicitly or run under automation.
./c8volt update process-instance --key <process-instance-key> --vars '{"customerTier":"gold"}' --dry-run
./c8volt update job --key <job-key> --retries 3 --dry-run
./c8volt expect process-instance --key <process-instance-key> --state completed
Generated references: update process-instance, update job, expect process-instance.
Cancel And Delete Safely
Use dry-run to preview process-instance family scope before cancellation or historical deletion.
./c8volt cancel process-instance --key <process-instance-key> --dry-run
./c8volt delete process-instance --key <process-instance-key> --dry-run
./c8volt get process-instance --bpmn-process-id <bpmn-process-id> --state terminated --keys-only | ./c8volt delete process-instance --dry-run -
Generated references: cancel process-instance, delete process-instance.
Configuration And Automation
c8volt loads config.yaml next to the binary by default, or a specific file from --config. Settings resolve in this order:
flag > env > profile > base config > default
Useful setup and automation commands:
./c8volt config validate
./c8volt --profile <profile-name> config test-connection
./c8volt capabilities --json
Generated references: config, capabilities.
Documentation
- Project site: c8volt.info
- Generated CLI reference: c8volt.info/cli
- Releases: github.com/grafvonb/c8volt/releases
Project Governance
- License and copyright: LICENSE, COPYRIGHT, and NOTICE.md
- Trademark policy: TRADEMARKS.md
- Contributing and DCO sign-off: CONTRIBUTING.md
- Security reporting: SECURITY.md
Copyright
| (c) 2026 Adam Bogdan Boczek | boczek.info |