Home / Use Cases / Camunda 8 process automation from CI

Camunda 8 process automation from CI

Why this matters for your team: process changes ship through the same review-and-release pipeline as application code — versioned, tested, and audit-traceable — instead of someone manually redeploying a diagram from a desktop tool.

Teams running Camunda 8 at scale often want process definitions to be versioned, reviewed, and deployed the same way application code is — not maintained as a separately-edited BPMN file that someone remembers to redeploy. BPMN Kit's packages compose into exactly that pipeline.

The pipeline

import { writeFileSync } from "node:fs";
import { execSync } from "node:child_process";
import { Bpmn } from "@bpmnkit/core";
import { CamundaClient } from "@bpmnkit/api";

// 1. Generate (or load) the process definition
const xml = Bpmn.export(
  Bpmn.createProcess("invoice-approval")
    .startEvent("start")
    .userTask("review", { name: "Review Invoice" })
    .exclusiveGateway("gw", { name: "Approved?" })
    .branch("yes", (b) => b.condition("= approved").serviceTask("pay", { taskType: "pay-invoice" }).endEvent("end-paid"))
    .branch("no", (b) => b.defaultFlow().endEvent("end-rejected"))
    .withAutoLayout()
    .build()
);
writeFileSync("invoice-approval.bpmn", xml);

// 2. Deploy to Camunda 8 — the deployment endpoint takes a multipart file
// upload, so it's deployed via the casen CLI rather than @bpmnkit/api's
// (JSON-only) typed client.
execSync("casen deploy deploy invoice-approval.bpmn --target camunda8", { stdio: "inherit" });

// 3. Start a new instance through the typed API client
const client = new CamundaClient({
  baseUrl: process.env.CAMUNDA_BASE_URL,
  auth: {
    type: "oauth2",
    clientId: process.env.CAMUNDA_CLIENT_ID,
    clientSecret: process.env.CAMUNDA_CLIENT_SECRET,
    tokenUrl: process.env.CAMUNDA_TOKEN_URL,
    audience: process.env.CAMUNDA_AUDIENCE,
  },
});
await client.processInstance.createProcessInstance({ processDefinitionId: "invoice-approval" });

Add a simulation step between generation and deployment to catch broken conditions or unreachable paths before they reach a real cluster, and the whole flow — generate, test, deploy — runs as ordinary CI steps.

The casen CLI

For interactive or scripted operations against a running Camunda 8 cluster — deploying resources, and managing process instances, jobs, incidents, and decisions from the terminal — the casen CLI wraps @bpmnkit/api (and, for the multipart deployment endpoint, a direct authenticated request).

Frequently asked

Do I need the Camunda Modeler to deploy processes built this way?

No — the casen CLI (or a direct multipart request to Camunda 8's deployment endpoint) deploys BPMN 2.0 XML straight to your cluster, whether that XML came from @bpmnkit/core, was hand-authored in Camunda Modeler, or came from anywhere else. Once deployed, @bpmnkit/api's typed client starts and manages instances.

Can this run in a CI pipeline?

Yes — every package here is a plain Node.js/TypeScript library with zero or minimal runtime dependencies, so generating, linting, and deploying a process is just a script step in any CI system.