Camunda 8.10-alpha2: More Consistency for Builders, More Control for Operators

Camunda 8.10-alpha2 is live and available for download. If you're a SaaS customer who's up to date, you may have already noticed some of these changes as we roll them out to you automatically. For everyone else, please read on.

This release brings a focused set of improvements across our connectors, Desktop Modeler, and Helm chart management. Each improvement is designed to make building and operating with Camunda faster, more consistent, and easier to maintain.

What’s new and why it matters

With 8.10-alpha2, we're continuing to invest in the consistency and control that help teams move faster and deliver more reliably. With standardized document handling across connectors, you can spend less time figuring out how to configure something and spend that time on delivering document-centric automations, including your AI pipelines, file processing, and email workflows. With full start form support in the Desktop Modeler, process developers can work in the tool they prefer without sacrificing capability or creating inconsistencies in how end users start processes.

For self-managed operators, this release brings meaningful improvements to how you manage and maintain your Camunda deployment. Camunda now has validated Helm v4 support and offers cleaner infrastructure ownership. This gives you more predictable upgrades, less operational risk, and a deployment footprint you fully control.

For the full list of what's changed, check out the release notes.

New standardized document source dropdown for connectors

As document-heavy automations become more common across your processes, having a consistent way to configure document inputs across connectors becomes essential. With Camunda 8.10-alpha2, every connector that accepts document inputs now surfaces the same standardized experience, so you configure it once and apply that knowledge everywhere in your process.

All connectors that accept document inputs (AWS S3, Google Cloud Storage, Azure Blob Storage, Google Drive, Box, Slack, Teams, SendGrid, Email, Bedrock, Embeddings Vector DB, and more) now share a standardized document source dropdown with four input methods:

• Inline content — paste or enter content directly
• External URL — reference a document by URL
• Camunda document — reference a document managed by Camunda
• List — pass a list of documents

Under the hood, a new @TemplateDocumentProperty annotation was introduced and applied across all associated connectors, auto-generating the standardized dropdown in element templates. Template versions have been bumped to engine version 8.10 (the minimum required to support inline document input) and backward compatibility with older templates is preserved since the runtime was not changed.

As document handling becomes more central to automation use cases, this kind of consistency directly accelerates how fast you can build and maintain document-centric processes. It's a pattern you internalize once and apply everywhere.

Start forms on none start events with Desktop Modeler

If you can define a start form on a none start event (a start event with no defined trigger) in the Web Modeler, why can't you do the same in the Desktop Modeler? Well, now you can.

Configuring a start form was already supported in the Web Modeler, but the Desktop Modeler did not offer support leading to an inconsistent experience. If you were working in the Desktop Modeler and needed a start form, your options were to switch tools or hand-edit the XML directly. Neither provided a very good user experience.

That all changes in 8.10-alpha2. A new Form group now appears in the properties panel for your root-level none start events in the Desktop Modeler, with full parity to what you already have in the Web Modeler. Two form types are supported:

• Camunda Form (linked) — reference a deployed Camunda Form by ID
• Camunda Form (embedded) — embed form JSON directly in the BPMN diagram

A few details worth noting:

• Forms are cleaned up automatically when a start event is moved into a subprocess or replaced with a typed start event — no orphaned configuration to track down.
• A deprecation hint guides users from embedded forms toward linked forms, which is the recommended approach going forward.
• Diagrams with start forms can now be authored, edited, and exchanged seamlessly between the Web and Desktop Modeler.

If you imported a diagram that already had a start form configured in the XML, that configuration was always there, but wasn't visible or editable in the Desktop Modeler. Now it is.

Helm chart updates for self-managed

Helm v3 is reaching end of life in 2026 and Helm v4 introduces changes in templating, chart dependency resolution, and OCI artifact handling. If you're running Camunda self-managed on Kubernetes, you need confidence that upgrading your Helm client won't disrupt your existing production deployment. We've done the validation work so you don't have to guess.

With Camunda 8.9, we introduced dual support for both Helm v3 and Helm v4 giving teams a low-risk opportunity to migrate their Helm client while maintaining a Camunda supported version deployment. Shipping with Camunda 8.0, Camunda Helm charts 15.x are fully validated and compatible with Helm v4 and Helm v4 is the required version for 8.10 and later. Helm v3 is no longer supported in that chart series.

However, to give operators a safe migration window, Camunda Helm charts 14.x serve as the bridge release, supporting both Helm v3 and v4 simultaneously. That means you can migrate your Helm client while staying on a fully supported Camunda version before you upgrade to 8.10.

The recommended migration path is:

1. Upgrade to Camunda 8.9 (on Helm v3)
2. Migrate your Helm client from v3 to v4 (while staying on 8.9)
3. Upgrade to Camunda 8.10+ (on Helm v4)

Full migration documentation is available, and a dedicated blog post walking through every step published this month. If you manage CI/CD pipelines that deploy Camunda, put that one on your reading list.

Bitnami dependency sub-chart removal

Bitnami sub-charts were always intended as a convenience for getting started quickly. In 8.10, they are no longer part of the Camunda Helm charts in the 15.x chart series.

As Camunda deployments mature into production environments, most operators want full control over how PostgreSQL, Elasticsearch/OpenSearch, and Keycloak are configured, versioned, and upgraded. Bundled defaults that made sense for evaluation can become constraints in production, particularly for teams with dedicated DBA, security, or platform engineering functions who need to manage these dependencies on their own terms.

Starting with Camunda Helm charts 15.x, the sub-charts have been removed entirely. You provision and configure PostgreSQL, Elasticsearch/OpenSearch, and Keycloak independently using your own versions, your own configurations, and your own upgrade schedules.

What you get in exchange:

• A thinner, more focused Helm chart that deploys Camunda components only, with no implicit third-party side effects
• Chart upgrades that are no longer entangled with third-party component version bumps
• Full control over security posture without bundled defaults to override or work around

A detailed migration guide is available to help you transition from the bundled sub-charts to independently managed dependencies. If you're running a production self-managed deployment, start there before you upgrade.

Try it and tell us what you think

Camunda 8.10-alpha2 is available for download now. SaaS customers who are current will see these changes automatically.

Take the new document source dropdown for a spin, update your Desktop Modeler diagrams with start forms, and if you're managing a self-managed Kubernetes deployment, take a look at what the Helm v4 migration path means for your environment.

As always, the full details are in the release notes. And if something catches your attention — or something doesn't work the way you'd expect — we'd love to hear from you on the Camunda forum.