February 18, 2026 5 min read TSX fork

camel karavan

Abstract

Apache Camel Karavan a Low-code Data Integration Platform

The Problem

Developers who need to build Apache Camel integration routes spend most of their time writing XML/Java DSL, wiring containers, and managing deployment descriptors. The lack of a visual, low‑code front‑end makes onboarding slow and error‑prone, especially when teams must switch between IDEs, Docker, and Kubernetes.

What This Does

apache/camel-karavan supplies a web UI (karavan-app) and a VS Code extension (karavan-vscode) that let users draw routes, configure components, and generate the underlying Camel DSL in YAML or Java. The core model and API live in karavan-core, which defines the canonical CamelDefinition and IntegrationDefinition types used by both the UI and the generator (karavan-generator). Build and deployment helpers are in karavan-app/src/main/docker and the Helm/Kubernetes manifests under docs/install.

Key files:

karavan-app/src/main/webui/src/index.tsx – boots the React SPA.
karavan-core/src/core/model/CamelDefinition.ts – the 3 682‑line type graph that drives the designer.
karavan-generator/src/main/java/.../Generator.java (implicit from the Java sources) – converts the model to runnable Camel projects.

How It Is Wired

Execution starts at karavan-app/src/main/webui/src/index.tsx, which mounts the React root and loads App.tsx. App.tsx creates the DesignerStore (karavan-app/src/main/webui/src/karavan/features/integration/designer/DesignerStore.ts). This store is the most‑connected module (imports 32, exported to 1) and holds the in‑memory CamelDefinition tree.

When a user adds a component, the UI dispatches actions that mutate the CamelDefinition model. The model is persisted via karavan-core/src/core/api/CamelDefinitionYaml.ts, which serialises to YAML for storage in the Git repo (the source‑of‑truth). The same module also deserialises on load, but it contains an empty catch {} block (high‑severity resilience issue).

The VS Code extension mirrors this flow: its webview entry point karavan-vscode/webview/index.tsx creates a parallel DesignerStore (karavan-vscode/webview/integration-designer/DesignerStore). Both stores rely on the same core types, creating a circular import chain among CamelDefinition.ts, IntegrationDefinition.ts, and CamelDefinitionYaml.ts (18 import‑cycle members). The hub module karavan-core/src/core/model/CamelDefinition.ts is referenced by 33 other modules, giving it the largest blast radius for any change.

After a design is saved, karavan-generator reads the YAML files (via CamelDefinitionYaml) and emits a Maven/Quarkus project that can be built with the Dockerfile at karavan-app/src/main/docker/Dockerfile. The generated image is then pushed to the registry defined in docs/install/karavan-docker/docker-compose.yaml or the Helm chart under docs/install/karavan-helm.

How To Use It

# clone the repo
git clone https://github.com/moses-y/camel-karavan
cd camel-karavan

# build the web UI (npm is the package manager)
cd karavan-app/src/main/webui
npm ci            # lockfile install per CI recommendation
npm run build     # Vite produces a static bundle used by the Spring Boot app

# start the Spring Boot container (Dockerfile provided)
cd ../../..
docker compose -f docs/install/karavan-docker/docker-compose.yaml up -d

The UI is reachable at http://localhost:8080. To edit locally, install the VS Code extension from the marketplace and open a folder containing a Karavan integration project (YAML files under src/main/resources/integrations). No additional environment variables are required beyond the Docker compose defaults.

Real‑World Use

A fintech team can model a payment‑routing flow in the designer, export the YAML, and let karavan-generator produce a Quarkus‑based Camel microservice. The generated Docker image is then deployed to the company’s OpenShift cluster via the Helm chart in docs/install/karavan-helm. Because the source repository holds the YAML, version control and CI/CD can treat the integration as code.

Code Health & Issues

High – Pin GitHub Actions – .github/workflows/*.yml uses tag versions (@v3, @v5). Replace with commit SHAs.
High – CI never runs tests – Workflows lack a test step despite 93 test files. Add a step invoking npm test or Maven test.
Medium – Least‑privilege GITHUB_TOKEN – .github/workflows/app.yml declares no permissions. Add permissions: contents: read.
Medium – Enable Dependabot – No .github/dependabot.yml despite three manifest files. Add one covering npm, Maven, and GitHub Actions.
Medium – Use lockfile in CI – Workflows run npm install; switch to npm ci.
Medium – Dependency‑vulnerability gate – No scan step. Add dependency-review-action or osv-scanner.
Medium – Checkout persist‑credentials – vscode.yml keeps the token; set persist-credentials: false.
Low – Job timeout – Workflows lack timeout-minutes. Define a reasonable limit (e.g., 30).
Low – Repository conventions – Missing .editorconfig, .gitattributes, formatter config. Add them to enforce consistency.

Additional static findings (381 total) include:

Oversized files – karavan-core/src/core/model/CamelDefinition.ts (3 682 lines) and related API files; split by responsibility.
Import cycles – Core model and API files form 18 circular dependencies; refactor shared types into a separate module.
Deep nesting & high branching – Several API files exceed six indentation levels and contain >150 branch points; simplify with guard clauses or strategy tables.
Hub module – CamelDefinition.ts is depended on by 33 modules; keep it stable and extract volatile logic.

The Bottom Line

camel-karavan delivers a functional low‑code UI and VS Code tooling for Apache Camel, backed by a coherent core model and containerised build pipeline. The codebase works but suffers from large, tightly coupled files, import cycles, and several CI hygiene gaps that should be addressed before extending or deploying in production. Teams comfortable with Java, Maven, and React can adopt it quickly, provided they allocate effort to refactor the core model and tighten the CI configuration.

What the analyser found

Deployment readiness

7/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

943 files

TSX302
TypeScript200
Java139
YAML82
CSS75
JSON17

ReactExpressSpringDockerKubernetes

Module dependencies

The 10 most depended-upon modules of 500, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_c_core_model_CamelDefinition["CamelDefinition"] n1_core_api_CamelDefinitionYaml["CamelDefinitionYaml"] n2_ation_designer_DesignerStore["DesignerStore"] n3_ation_designer_DesignerStore["DesignerStore"] n4__model_IntegrationDefinition["IntegrationDefinition"] n5_ation_designer_utils_CamelUi["CamelUi"] n6_ation_designer_utils_CamelUi["CamelUi"] n7_re_api_CamelDefinitionApiExt["CamelDefinitionApiExt"] n8__core_src_core_api_CamelUtil["CamelUtil"] n9__model_IntegrationDefinition["IntegrationDefinition"] n7_re_api_CamelDefinitionApiExt --> n8__core_src_core_api_CamelUtil n7_re_api_CamelDefinitionApiExt --> n0_c_core_model_CamelDefinition n7_re_api_CamelDefinitionApiExt --> n4__model_IntegrationDefinition n1_core_api_CamelDefinitionYaml --> n4__model_IntegrationDefinition n1_core_api_CamelDefinitionYaml --> n0_c_core_model_CamelDefinition n1_core_api_CamelDefinitionYaml --> n8__core_src_core_api_CamelUtil n8__core_src_core_api_CamelUtil --> n4__model_IntegrationDefinition n8__core_src_core_api_CamelUtil --> n0_c_core_model_CamelDefinition n8__core_src_core_api_CamelUtil --> n7_re_api_CamelDefinitionApiExt n8__core_src_core_api_CamelUtil --> n1_core_api_CamelDefinitionYaml n0_c_core_model_CamelDefinition --> n4__model_IntegrationDefinition n4__model_IntegrationDefinition --> n0_c_core_model_CamelDefinition classDef cyc stroke:#ef4444,stroke-width:2px; class n0_c_core_model_CamelDefinition,n1_core_api_CamelDefinitionYaml,n4__model_IntegrationDefinition,n7_re_api_CamelDefinitionApiExt,n8__core_src_core_api_CamelUtil,n9__model_IntegrationDefinition cyc;

Dependencies

29 of 86 declared dependencies are a major version behind. Resolved 85 of 86 against the registry.

Package	Declared	Latest	Behind
`cross-env`	^7.0.3	10.1.0	3 major
`copy-webpack-plugin`	11.0.0	14.0.0	3 major
`@types/node`	24.2.1	26.2.0	2 major
`@vitejs/plugin-react`	^4.7.0	6.0.5	2 major
`typescript`	5.9.3	7.0.2	2 major
`@types/glob`	^7.1.3	9.0.0	2 major
`eslint-config-prettier`	^8.3.0	10.1.8	2 major
`style-loader`	^2.0.0	4.0.0	2 major

Open in Code Brain → See its neighbourhood →

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high3

medium5

low2

Pin third-party GitHub Actions to a commit SHAhigh4 occurrences

.github/workflows

docker/setup-qemu-action@v3, docker/setup-buildx-action@v3, docker/login-action@v3, docker/build-push-action@v5

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Upgrade the pinned dependency carrying a published advisoryhigh34 occurrences

axios@1.12.2 CVE-2026-44494 (high) +27 more; vite@7.2.6 CVE-2026-53571 (high) +4 more; uuid@13.0.0 CVE-2026-41907 (medium)

The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Make CI invoke the test suite it hashigh93 occurrences

.github/workflows

93 test files, no test command in any workflow

A green check that never executed an assertion is worse than no check, because reviewers trust it.

Fix: Add a test step to the existing workflow rather than a new workflow.

Declare least-privilege permissions for GITHUB_TOKENmedium3 occurrences

.github/workflows/app.yml

3 workflow(s) declare no permissions, 2 of them reference secrets

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

3 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Install from the lockfile in CImedium

.github/workflows

npm install with a committed package-lock.json

A fresh resolution in CI means the tested dependency set is not the locked one, so the failure only appears after merge.

Fix: Use npm ci, yarn install --immutable, or pnpm install --frozen-lockfile.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/vscode.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow3 occurrences

.github/workflows/app.yml

3 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.

View on GitHub All Projects