EximeeBPMS is developed in line with the security practices used by the largest Polish banks. The platform’s architecture supports the requirements imposed on systems of critical importance, and the team actively monitors and eliminates vulnerabilities in each subsequent release. Security is one of the core areas of product development, and all deployments are carried out in accordance with banking standards and procedures.

EximeeBPMS systematically eliminates vulnerabilities as part of its security roadmap:

• The 1.1.1 release was a dedicated security release, removing four high-severity CVEs in dependencies, including Spring Framework, Spring Security, and Apache Commons FileUpload.
• Version 1.3.0 introduces Script Guard – a mechanism that blocks RCE attack vectors originating from process definitions, enforced both during BPMN model parsing and execution – as well as a backpressure mechanism for External Tasks, increasing the platform’s resilience to overload.

Starting from releases after 1.3.0, every security fix in the changelog cites the identifier of the removed CVE, enabling banks to clearly verify vulnerability status during audit processes.

Security is built into the EximeeBPMS release cycle. Dependencies are continuously scanned for vulnerabilities, the code undergoes static analysis, and every published container image is scanned with Trivy – detection of a critical vulnerability blocks publication. Images are digitally signed (cosign/Sigstore) and delivered with a full CycloneDX SBOM, while deployment manifests are automatically validated against Kubernetes security profiles.

Security improvements are explicitly documented in each version’s changelog – including strengthened identifier entropy (UUID v7), configurable OAuth2 endpoints, and the Script Guard mechanism – and vulnerability fixes cite CVE identifiers. Vulnerability reports are accepted under responsible disclosure, in line with the project’s published security policy.

EximeeBPMS protects data in both on-premises and cloud-ready environments using security mechanisms aligned with banking standards, including encrypted communication, environment isolation, OAuth2/OIDC-based access control, and an architecture designed for systems of critical importance. This enables secure authentication, user and group mapping, access control, SSO/SSO logout, and flexible identity and authorization configuration across deployment models.

Migration from Camunda 7 to EximeeBPMS is predictable because EximeeBPMS preserves full compatibility with BPMN 2.0, Camunda 7’s execution semantics, and its component architecture. The platform uses a native BPMN 2.0 engine running on the JVM, and its modules – REST API, Tasklist, Cockpit, Admin – are analogous to those known from Camunda 7.

Process models run without changes, and integration code is automatically adapted: OpenRewrite-based migration scripts rewrite dependencies, packages, and imports without manual refactoring of process logic.

The migration baseline is Camunda 7.23.0; projects on older versions must be upgraded first.

Since version 1.2.0, EximeeBPMS runs on Spring Boot 4.x – applications using older Spring Boot versions require the standard migration described in the guide. Process design remains possible in Camunda Modeler.

A detailed migration workflow is available in the documentation.

Yes, BPMN process models created for Camunda 7 run in EximeeBPMS without any modifications because the platform preserves full compatibility with BPMN 2.0 semantics and Camunda 7 execution mechanics.

Only the application code layer changes (packages org.camunda → org.eximeebpms), and this is fully automated by the provided migration scripts. Process logic does not require changes.

EximeeBPMS is fully compatible with the Camunda 7.23 database schema – the version on which the platform is based. Migration does not require conversion or transfer of process data: the existing database works unchanged.

Up to version 1.3.0, EximeeBPMS introduced no modifications to the schema. From 1.3.0 onward, the only changes are new tables (e.g., for Script Guard), which do not alter or affect existing structures. Projects on older Camunda 7 versions must be upgraded to 7.23.0 using standard Camunda update mechanisms.

Migration from Camunda 7 to EximeeBPMS is supported by automated tools based on OpenRewrite and dedicated migration scripts provided by EximeeBPMS. The rewrite-maven-plugin applies migration rules automatically, updating dependencies, packages, imports, and project configuration without manual refactoring.

Key migration tools include:

• OpenRewrite – a code-refactoring engine executing YAML-based transformation rules,
• rewrite-maven-plugin – a Maven plugin running migration recipes,
• EximeeBPMS migration scripts – ready-to-use OpenRewrite recipes for Camunda 7 → EximeeBPMS conversion,
• replace-camunda-with-eximeebpms.yml – a configuration file defining dependency, package, import, and type transformations.

Automation reduces risk, shortens migration time, and preserves full BPMN 2.0 compatibility. 

The complete migration guide is available in the documentation.

Yes, EximeeBPMS officially supports process design in Camunda Modeler thanks to BPMN 2.0 compatibility and adherence to Camunda 7 semantics.

EximeeBPMS eliminates technical debt by modernizing key platform components so they run on a contemporary, supported, and secure technology stack. This includes full backend migration to Spring Boot 4.x / Spring Framework 7 with optimization of the BPMN engine for Java 21 LTS.

This removes limitations inherited from Camunda 7 and enables long-term, secure maintenance. Support for future Java LTS versions is provided according to the published environment support policy.

EximeeBPMS requires Spring Boot 4.x because the platform has been modernized to run on the latest supported and secure technology stack, eliminating technical debt inherited from Camunda 7.

The transition to Spring Boot 4.x (and Spring Framework 7), introduced in version 1.2.0, ensures compatibility with modern security standards and full optimization of the BPMN engine on Java 21. This enables long-term, secure platform maintenance without risks from outdated libraries.

EximeeBPMS supports Java 11, 17, and 21. Compatibility is verified in the project’s QA infrastructure on Eclipse Temurin JDK.

The platform is optimized for Java 21 LTS, ensuring long-term support, audit predictability, and access to JVM improvements in concurrency, memory, and security.

New Java LTS versions (including Java 25) are added in subsequent minor releases according to the environment support policy.

EximeeBPMS supports modern, production-grade databases compatible with the Camunda 7 ecosystem, allowing projects to migrate without changing database engines or transactional configurations.

Supported databases include:

• MySQL 8.0 – fully supported in production environments,
• Oracle 19c / 23ai – compliant with the requirements of large financial institutions,
• IBM DB2 11.5 – excluding IBM z/OS,
• PostgreSQL 14 / 15 / 16 / 17 – recommended for cloud environments,
• Amazon Aurora PostgreSQL – compatible with PostgreSQL 14-16,
• Microsoft SQL Server 2017 / 2019 / 2022 – with dedicated configuration notes,
• Azure SQL – aligned with supported SQL Server compatibility levels,
• H2 2.3 – development only; not recommended for clustered mode.

Additional details are available in the EximeeBPMS documentation.

Yes, EximeeBPMS is delivered as lightweight container images and can run in Docker, Kubernetes, and OpenShift. Official deployment artifacts – Helm charts and Kustomize – are available in the eximeebpms-k8s repository, enabling quick startup of the Community Edition and production-grade configurations.

The default deployment runs a single replica with an embedded H2 database for demo purposes. Production deployments include ready-made high-availability configurations with PostgreSQL, autoscaling, PodDisruptionBudget, anti-affinity rules, and tuned probes.

All manifests comply with Pod Security Standards: Restricted and CIS Kubernetes Benchmark controls. Images are scanned (Trivy), signed with short-lived keys (cosign), and published with an SBOM.

The same container image can also be run locally via Docker using a simple docker run command.

The cloud-ready architecture of EximeeBPMS is based on lightweight container images and official deployment artifacts for Kubernetes and OpenShift, enabling operation on-premises, in containerized environments, and in the cloud.

Modernization to Spring Boot 4.x and Java 21, along with official high-availability configurations, enables deployments with autoscaling (HPA), health checks, rolling updates, and resilience policies (PodDisruptionBudget, anti-affinity).

The same image can run locally in Docker and in production on Kubernetes, simplifying the path from development to enterprise-grade deployment.

EximeeBPMS is a secure alternative to Camunda 7 thanks to active platform maintenance: regular releases, systematic vulnerability elimination (documented with CVE identifiers), and a dedicated security roadmap.

For organizations requiring contractual guarantees, a Commercial Support model is available, including SLA and Long-Term Support releases.

The platform is developed by Consdata according to banking-sector practices, eliminating risks associated with abandoned components – a common issue in the no-longer-maintained Camunda 7 CE.

EximeeBPMS reduces deployment risk on three levels:

• Technological continuity: the platform preserves Camunda 7 semantics proven in thousands of deployments, so migration does not change process behavior.
• Active maintenance: regular releases, CVE-documented vulnerability elimination, and mechanisms increasing resilience to overload (External Task backpressure) and malicious code (Script Guard).
• Transparent supply chain: signed images, SBOM, and scanning of every release.

Consdata – a provider of process systems for major Polish banks for over 10 years – ensures development aligned with the needs of critical environments.

EximeeBPMS offers two support models:

• Community Support (free) includes open documentation, GitHub issue reporting, and regular platform releases.
• Commercial Support, provided by Consdata, offers SLA for critical and blocking issues, priority ticket handling, critical security fixes, and Long-Term Support (LTS) releases.

This gives banks and financial institutions guaranteed response times and predictable, regular deliveries aligned with the practices of the financial sector.

Banking and financial institutions choose EximeeBPMS because Camunda 7 CE is no longer supported or updated, which creates real security and audit risks.

EximeeBPMS provides an actively maintained platform aligned with banking standards: continuous vulnerability elimination documented with CVE identifiers, predictable updates, no technical debt thanks to a modernized technology stack (Spring Boot 4.x, Java 21), and a responsible vendor with long-standing experience in the financial sector.

As a result, institutions receive a process environment that is secure, continuously developed, and compliant with regulatory requirements.

EximeeBPMS supports audits and regulatory compliance through artifacts that can be directly presented to auditors:

• changelog documenting security fixes with CVE identifiers,
• CycloneDX SBOM published with every image,
• digitally signed container images (cosign/Sigstore),
• deployment manifests meeting Pod Security Standards “Restricted” and CIS Kubernetes Benchmark controls.

The platform is actively maintained and regularly updated, significantly simplifying internal and external compliance requirements.

Yes, EximeeBPMS is completely free for both commercial and non-commercial use under the Apache 2.0 license, with no licensing fees and no functional limitations.

Optionally, paid Commercial Support from Consdata is available, including SLA, priority security fixes, and Long-Term Support releases.

EximeeBPMS is licensed as an open-source project under the Apache License 2.0, which provides full freedom to use, modify, integrate, and distribute the software, including in commercial projects.

Yes, EximeeBPMS is fully open source and distributed under the Apache 2.0 license, allowing unrestricted use, modification, and distribution – even in commercial environments. The source code is publicly available in the official GitHub repository, and both documentation and accompanying tools are openly accessible to users.

The EximeeBPMS roadmap is based on regular releases focused on eliminating vulnerabilities and delivering stable, predictable updates aligned with banking requirements.

Versions 1.2.0 (stack modernization: Spring Boot 4.x) and 1.3.0 (Script Guard, backpressure, UUID v7) form the foundation of backend modernization.

Upcoming releases expand event-driven architecture and observability (1.4.0, planned for September 2026) and introduce a modern user interface (2.0, planned for Q4 2026).

Detailed information about all releases is available in the Release Notes section of the documentation.

Bug reports and feature requests should be submitted through the official GitHub Issue Tracker. Questions, discussions, and knowledge exchange take place in GitHub Discussions.

Customers using Commercial Support additionally have access to dedicated SLA-backed communication channels.

EximeeBPMS supports critical banking processes through several key capabilities:

• Stability under extreme load – the Backpressure mechanism maintains continuity even during sudden traffic spikes,
• Architecture for mission-critical systems – a modular, cloud-ready backend supports workload isolation, scaling, and both on-premises and cloud deployments,
• Execution security – Script Guard blocks RCE in process definitions, which is essential in regulated environments,
• Modern technology stack – Java 21 and Spring Boot 4.x ensure long-term support, high performance, and alignment with banking best practices,
• Layer separation – an independent REST API module and a decoupled web layer (Cockpit, Tasklist, Admin) enhance the architecture’s resilience and deployment flexibility,
• Container readiness – the BPMN engine is natively prepared for JVM, Docker, and Kubernetes.

Together, these features ensure operational continuity, resilience to load spikes, predictable performance, and compliance with banking and audit requirements.

High-availability (HA) deployments of EximeeBPMS follow banking-grade practices:

• Component separation – each module runs independently, improving resilience and flexibility,
• Multi-instance architecture – the BPMN engine, REST API, and UI can run in multiple parallel replicas,
• Container readiness – native operation in JVM, Docker, and Kubernetes,
• HA practices – full alignment with banking standards for continuity.

The persistence layer uses supported transactional databases, and the overall architecture enables HA/DR deployments consistent with the requirements of the financial sector.

EximeeBPMS is designed for regulated environments, supporting audit predictability, continuous vulnerability mitigation, and alignment with financial sector practices (including active updates, elimination of critical CVEs, modernization of the technology stack, and script execution control). This significantly simplifies compliance with external supervisory audits.

EximeeBPMS handles extreme transactional load through a scalable execution architecture proven in production as well as full optimization for Java 21. These versions provide modern concurrency mechanisms, efficient JVM performance, and LTS stability.

A key component is the intelligent Backpressure mechanism, which prevents worker overload and eliminates blocking errors, ensuring continuous BPMN engine operation even during sudden traffic surges. This results in high throughput, predictable performance, and resilience required for critical banking processes.

EximeeBPMS includes several features supporting technical aspects of operational resilience required by DORA:

• High availability within a single cluster – scaling, health probes, database replication,
• Modularity and containerization – enabling component isolation and environment manageability,
• Execution security, validated through:
  • CodeQL (Java + JavaScript scanning),
  • Trivy (Docker image scanning),
  • Dependabot (dependency monitoring for Maven, npm, GitHub Actions).
• SBOM – automatically generated in CycloneDX format and available in the repository,
• Incident reporting – technical mechanisms available for integration,
• Resilience testing – built-in mechanisms supporting load and failure-scenario testing,
• ICT vendor governance – a transparent software supply chain supporting supervisory requirements.

EximeeBPMS is an open-source business process orchestration platform based on BPMN 2.0, developed as a fork of the last stable version of Camunda 7. It provides a native BPMN engine running on the JVM, a REST API, and the Cockpit, Tasklist, and Admin applications.

The platform is developed by Consdata with critical-systems environments in mind – primarily banking and finance – and is distributed under the Apache 2.0 license.

Organizations using Camunda 7 can migrate to EximeeBPMS without changing their process models and without migrating the database.

Camunda 8 is a platform with a completely new architecture (the Zeebe engine), incompatible with Camunda 7 – migrating to it requires rebuilding processes, integrations, and infrastructure.

EximeeBPMS preserves the architecture, execution semantics, and database schema of Camunda 7, allowing organizations to continue developing their systems without costly migration – on a modernized technology stack (Spring Boot 4.x, Java 21) and with active vulnerability elimination.

EximeeBPMS is fully developed and maintained by Consdata S.A., a Polish technology company with over 10 years of experience building process systems for the banking sector, including solutions used by the largest banks in Poland.

Consdata is responsible for the roadmap, releases, and security of the platform, and the source code is publicly available on GitHub.