Self-hosted Boomi alternative for air-gapped networks

Why Boomi does not fit a self-hosted air-gapped integration platform

Boomi's customer-hosted runtimes still initiate HTTPS connections to its North American or European platform and take mandatory updates from it, so they cannot meet a strict isolation rule that allows no internet path. Boomi's Atoms, Molecules and Atom Clouds documentation places the customer-hosted options (basic runtime, runtime cluster and runtime cloud) on premises or in AWS, Azure or Google Cloud, and hosting location does not remove the connection back to Boomi's platform. Apache Camel or Apache NiFi can run fully inside the boundary, with every binary, container image and package admitted through a controlled transfer process. This page covers what to confirm with Boomi before you rule it out, and how to choose between Camel and NiFi for the workloads in scope.

Start with a written request to Boomi for the complete list of endpoints, ports and destinations each runtime type contacts, including status reporting, component retrieval and update checks. Ask whether any of those calls can be disabled or redirected to a mirror inside your network, and whether updates can be staged from media you import and approved through your change process. Ask which version lines support that model and what the support position is if a runtime is kept off the vendor's update track. Also ask how licensing applies to a runtime that is never connected, because a subscription may assume a live link to the platform. Record the answers in the security review file, since they decide whether any Boomi runtime can sit inside the enclave at all. If the answers do not clear your isolation rule, the decision is already made.

Choose Apache Camel when the team builds integrations as code and needs its 350+ connectors, which can be written in Java, YAML or XML and run on Spring Boot, Quarkus or standalone. Choose Apache NiFi when the work is mostly file and data movement that operators want to build and monitor in a visual designer. NiFi 2 requires Java 21 at minimum, and its optional Python processors are a beta feature, so confirm both against your build image. Its administration guide lists LDAP, OpenID Connect, SAML 2.0 and X.509 client certificate authentication, with Kerberos deprecated. Without a security configuration, NiFi binds to 127.0.0.1, so an isolated deployment must set its own listener and identity settings before anyone can reach the UI. Plan for every base image, JAR and package to be pulled into the enclave in advance.

What an air-gapped integration platform must do

An isolated network removes the vendor cloud from the integration path, so every control that a SaaS iPaaS provided must now be met by the platform, the artifacts you carry in, and the people who approve them. The cards below set out the requirements that connect those decisions, each of which should be confirmed against your own boundary before a platform is chosen.

No vendor cloud dependency

Confirm that the platform starts, runs flows, logs and recovers with every outbound route closed. Boomi's customer-hosted runtimes still open HTTPS connections to its platform, so they cannot be treated as isolated by default. With Apache Camel or NiFi, the runtime is the only component that needs to exist inside the boundary, and you should verify that no telemetry, license check or registry call is made at startup. Ask the vendor or project to document every network dependency.

Offline installation and artifact transfer

Every dependency must be assembled outside the boundary, scanned, and carried across by an approved route. For Kubernetes-based deployments, kubeadm can list and pull control plane images in advance and point at a private registry with --image-repository. Plan a mirror for container images, Maven artifacts and connector libraries, and keep a manifest of versions so a rebuild after failure does not depend on the internet.

Software integrity and provenance checks

NERC CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity for vendor software and patches, and the same discipline applies to open-source packages you carry across. Record checksums and signatures for each release, confirm the signing identity against the project's published guidance, and keep the evidence with the change record. This is the step most often missing when teams treat open source as exempt from supply chain review.

Controlled, scheduled upgrades

Air-gapped operators must choose when every runtime changes, which means updates arrive as media you approve rather than as platform pushes. Track each supported line against its end-of-support date: the NiFi project states that 1.x cannot be maintained further and strongly encourages upgrades to NiFi 2, and the NiFi migration guidance requires moving to 1.27.0 before 2.0.0. Camel LTS lines give a longer fix window, so confirm the line you select against your change calendar.

Authentication inside the boundary

Sign-in must work without a cloud identity service. NiFi supports single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 client certificate authentication, while its Kerberos provider is deprecated. Choose the option that matches your directory, confirm that the identity provider is reachable from inside the enclave, and test the break-glass account before go-live. Also confirm which Camel or other runtime consoles offer equivalent controls.

Safe default exposure

A platform should not listen on a network interface that exposes its UI to the enclave by accident. When no security configuration is provided, NiFi binds to 127.0.0.1, so its UI is reachable only through the loopback interface until you configure access. Verify the bind address, port exposure and any management endpoints in each environment, and include them in the hardening baseline reviewed before every release.

Where Boomi's hosted connections break the isolation rule

Boomi's deployment model does not offer a runtime that works without its platform. Boomi-hosted runtimes come as Public, Dedicated and Managed Cloud Service options, which Boomi operates for you. Customer-hosted runtimes come as a basic runtime, a runtime cluster and a runtime cloud, and they can be installed on premises or in AWS, Azure or Google Cloud. Boomi's documentation on Atoms, Molecules and Atom Clouds describes these components. Hosting the runtime in your own network changes who owns the infrastructure, but the runtime is still managed through Boomi's platform. For an isolated network, that dependency is the first thing to test.

The dependency runs outbound. Customer-hosted runtimes still initiate HTTPS connections to Boomi's North American or European platform, and they take mandatory runtime and platform updates from it. An outbound connection that a firewall must permit and an update path that depends on a vendor endpoint you cannot reach are the two points that break an air-gapped boundary. A firewall rule or proxy alone does not resolve either one. Ask Boomi, in writing and for your exact runtime version, which hostnames and ports the runtime contacts, what data each connection carries, whether an offline installation or update mode exists, and what happens to a runtime when a mandatory update cannot be retrieved.

Decide which runtimes may stay in the enclave before any procurement or migration work begins. Build an inventory of every Boomi runtime, the connectors and endpoints each process uses, and the network segments each runtime sits in. Any runtime whose outbound connections cannot be documented and approved through a security review should be scheduled for replacement with Apache Camel or Apache NiFi, which you install, patch and monitor inside the isolated network. Keep the evidence: egress rules, the vendor's written answers, and test results from a connection attempt blocked at the boundary. A security assessor or your change board will ask for these records.

Apache Camel, Apache NiFi and other offline-capable options compared

This table compares Apache Camel, Apache NiFi, Apache Hop and Kong Gateway OSS on how each runs without internet access, its license, runtime needs and release lines. Read it by row to see where each option fits an isolated network and what your team must build or staff itself. The main takeaway is that the licensing and install path is the same for all of them, so the choice depends on whether your flows are code-first or data-movement oriented.

Criterion	Apache Camel	Apache NiFi
License	Apache-2.0, maintained by the Apache Software Foundation	Apache-2.0, with no paid edition from the project
Build model	Code-first routes in Java, YAML or XML on Spring Boot, Quarkus or standalone	Visual flow designer; flows are configured in the UI and versioned through registry clients
Offline install path	Build and pull dependencies into an internal artifact repository, then deploy the packaged runtime inside the enclosure	Install the distribution from a mirrored package set; the UI binds to 127.0.0.1 unless you configure it otherwise
Runtime requirement	Java 17, 21 or 25 for current 4.x releases	Java 21 minimum for NiFi 2.x; Python 3.10 to 3.12 only if you use the beta Python processors
Current release line	4.22.1 LTS (end of life August 2027); 4.23.0 non-LTS as latest standard release	2.12.0, released September 13, 2026; NiFi 1.x has reached end of support
Authentication	Depends on the runtime and surrounding services you build; confirm with your security architecture	Single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 client certificates; Kerberos is deprecated
Paid support	Optional: Red Hat sells support for its build of Camel on Spring Boot or Quarkus	Not required; no paid edition from the Apache project
Trade-off	Strongest fit for API-driven and message routing teams that version routes in Git and own their build pipeline	Strongest fit for file and data movement with visual operators; confirm B2B and EDI coverage separately
Apache Hop (for ETL-style batch)	Not a Camel substitute; use alongside Camel only where batch transformation is required	Apache-2.0 data orchestration platform for ETL-style workloads, offline-capable once its dependencies are mirrored

Choosing Camel or NiFi by workload

Apache Camel fits Boomi processes that route messages between applications, transform payloads and call REST, JDBC, Kafka or cloud service endpoints. Routes are written in Java, YAML or XML and implement enterprise integration patterns, so a team with developers can express branching, retries and content-based routing in code that lives in your own version control. Camel runs on Spring Boot with connector starters, on Quarkus with fast startup and native compilation, from the Camel CLI, on Kubernetes through Camel K, or standalone.

Runtime choice: Spring Boot suits teams already standardized on Spring, while Quarkus suits services where startup time and native images matter.
Camel K on Kubernetes: Camel K is built from Apache Camel for serverless and microservice deployments on Kubernetes, which fits an air-gapped cluster you already operate.
Visual design: Kaoto is an Apache-2.0 visual designer for Camel routes, available as a VS Code extension, so developers can draw flows and still keep YAML or XML as the source.
What it does not replace: Boomi API Management, its gateway and developer portal are separate products, so plan a gateway such as Apache APISIX or Gravitee alongside Camel.
B2B and EDI: Camel has no built-in trading partner management or EDI onboarding, so confirm how those flows will be rebuilt or sourced.

Before committing, confirm which Camel release line and Java version your security team has approved, and whether your team can own routes as code.

Deploying Camel or NiFi fully inside an isolated network

This sequence moves a self-hosted Camel or NiFi stack, with its Kubernetes base and private registry, into a network with no internet path and leaves it able to receive reviewed updates only.

Build the offline artifact bundle outside the boundary
Someone on the connected side, usually the platform team with the integration owner, collects every artifact the isolated network will need: Camel or NiFi distributions, Java 21, Python 3.10 to 3.12 if optional Python processors are used, Kubernetes control plane images, container images for each component, Helm charts or manifests, and any connector libraries. Record the exact versions in a bill of materials. The step is done when the bundle and its manifest list every item by name and version, and the team can explain why each one is there.
Verify checksums and provenance before transfer
Before anything crosses the boundary, the security team checks each artifact against the checksum and signature published by its project and confirms the source of the download. Keep the verification output with the bundle. Ask your procurement or supply chain owner how this check maps to your controls for verifying software integrity and authenticity of vendor software and patches, which NERC CIP-013-2 addresses for its in-scope entities. The step is done when every file has a recorded hash match and a signed transfer record.
Stand up a private image registry
The platform team deploys a registry reachable only from inside the isolated network, then loads the verified container images into it and tags them with the versions in the bill of materials. Nodes are configured to pull only from this registry. The step is done when a test node pulls each image from the internal registry with no outbound route, and an image pull from any external host fails.
Pull Kubernetes control plane images for kubeadm
On the connected side, run kubeadm config images list to get the control plane image names for the target Kubernetes version, then kubeadm config images pull to fetch them into the bundle. Push those images to the private registry. Run kubeadm init with the --image-repository flag pointing at that registry so the control plane starts without reaching public registries. The step is done when kubeadm init completes and the nodes report Ready with no external image pulls in the logs.
Install NiFi 2 with Java 21 and secured configuration
Install NiFi 2 on Java 21 from the verified bundle. If you are moving from NiFi 1.x, first upgrade to 1.27.0, then migrate to 2.x, and convert the flow configuration from flow.xml.gz to flow.json.gz as the migration guidance requires. Replace the ENVIRONMENT scope for any variable registry references and rename distributed map cache components. Configure authentication with LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates, avoiding the deprecated Kerberos provider. Confirm that the UI binds to the intended interface rather than the default loopback address. The step is done when an authorized user signs in through the chosen provider and the flow loads from the migrated configuration.
Cluster with ZooKeeper or Kubernetes Leases
Choose either embedded or external ZooKeeper for coordination, or Kubernetes ConfigMaps and Leases for state and leader election if NiFi runs on the cluster. Test the cluster by stopping one node and confirming that flows continue and that the primary role moves. Confirm the cluster configuration against the NiFi administration guide for your release. The step is done when a node failure test completes and the cluster shows all remaining nodes connected.
Set a schedule for reviewed upgrades
Agree on who approves each update, where it is tested and how long a version stays in service before its next review. Because no internet path exists, every update repeats the bundle process: build, verify, transfer and load. Track each project's support dates, since NiFi 1.x can no longer be maintained, and Camel LTS lines carry defined end-of-life dates. Ask your vendor or project for their release and security advisory channels. The step is done when a written upgrade calendar and approval record exist, and the team has run one full update cycle in a test enclave.

Evidence assessors ask for under an air-gapped control set

An isolated Apache Camel or NiFi deployment is only as credible as the records behind it. The cards below cover the artifacts, configuration, approvals and diagrams that assessors typically request, and they overlap because each one supports the others. DeployOpen prepares this evidence, while auditors and certification bodies decide whether it meets the applicable framework.

Artifact inventory and hash records

Keep a manifest for every transfer across the isolation boundary, listing each package, container image, Camel JAR, NiFi archive and connector with its version, source and cryptographic hash. Record who imported it, when, and which scan or review approved it. Assessors use this to confirm that what runs inside the network is what was reviewed outside it. Ask whether your transfer process produces these records automatically or relies on manual logs.

Access and authentication configuration

Export the configuration that controls who can change flows and routes: NiFi's single-user, LDAP, OpenID Connect, SAML 2.0 or X.509 settings, and the authorization policies attached to them. Include the NiFi bind address and the Kubernetes role bindings if you run on a cluster. Evidence should show that the defaults were reviewed and that privileged accounts are named, not shared. Confirm with your assessor which identity source they expect to see.

Change and upgrade approvals

Retain the approval record for every runtime, flow and dependency change, including the test results that preceded it. Because no vendor pushes updates into an isolated network, this record is the only proof of how the platform reached its current version. Track the Camel and NiFi release lines in use and the end-of-life dates for each, so a version that is no longer supported is caught before the assessment, not during it.

Network diagrams showing no egress path

Provide diagrams of the isolated zone, its boundary devices and the data flows that cross it, with an explicit note that no outbound route to the internet or to any vendor platform exists. Show DNS, time sync and package repositories as internal services. Back the diagram with firewall rule exports and a documented test showing that outbound connections fail. Verify the diagram against the live configuration, because an assessor will compare the two.

Supply chain records under NERC CIP-013-2

For utilities, NERC CIP-013-2 expects procurement processes that address verification of software integrity and authenticity and of vendor patches. Record the source of each open-source component, the signature or hash check performed, and the decision to accept or reject it. If your framework is different, map these records to its supply chain controls instead. Confirm with your compliance team which framework and control identifiers apply to your environment before you build the file.

Questions buyers ask about an air-gapped Boomi replacement

What does an air-gapped Boomi replacement cost, and what drives it up?

The cost is mostly people time and a few recurring infrastructure and support lines, not a license fee for Apache Camel or Apache NiFi, which are both Apache-2.0 licensed. The main components are the team that builds and runs the platform, the infrastructure inside your isolated network, the one-time rebuild of each Boomi process and map, and any support subscription you choose to buy. Cost rises with the number of processes, the number of distinct connectors and protocols, the amount of custom code, and how many environments you need. Ask any quote to break out build, rebuild, offline packaging of dependencies, testing, and recurring operations separately, and to state which items are one-time and which recur. Red Hat sells commercial support for its build of Apache Camel, so a support line is optional and should be priced separately.

How long does a Boomi migration to an isolated network take?

The duration depends on the size of the Boomi estate and on how much of it has to be rebuilt rather than reused. The factors that set it are the number of processes and maps to inventory, how many connectors are unusual or need custom components, how quickly your security team can approve the offline dependency transfer process, and how long your change approval and testing cycles take inside the network. No duration figure applies to every estate, so ask for a timeline in the written, fixed-scope proposal and check that it lists the assumptions behind it, including who performs the approvals and how many test cycles are planned.

Can our own team run Apache Camel or NiFi without outside help?

Many teams can, provided they already have Java or NiFi operations skills and enough capacity to own the platform after go-live. A capable team would need to cover the build and deployment pipeline inside the enclave, dependency and image mirroring, upgrades on a schedule they set, monitoring, backup, and incident response. Apache NiFi 2 requires Java 21 as a minimum runtime, and NiFi 1.x can no longer be maintained because of its dependencies, so the skills gap should be checked against the version you choose. Be honest about the team's on-call load and whether the same people also carry the Boomi cutover. An outside partner can cover some of these tasks under a fixed scope, and ongoing support is available as a retainer.

What do we need to provide before a Boomi migration can start?

Before work starts, the client usually needs to provide a few things:

An export or read access to the Boomi components, so processes, maps, connectors and schedules can be inventoried
A list of every system, endpoint and file share each integration touches, with owners
The isolated network design, including where runtimes, registries and the artifact mirror will sit
Named contacts for security approval, change control and the business owners who will test results
Your current runtime and dependency baseline, plus the transfer procedure your security team accepts for bringing packages across the boundary

The quality of this input shapes the scope and the timeline more than almost anything else, so confirm it in writing during scoping.

Is Apache Camel or Apache NiFi the better fit for an air-gapped estate?

It depends on the shape of the workload. Apache Camel fits code-first integration, API-driven message routing, and enterprise integration patterns, with more than 350 connectors and routes written in Java, YAML or XML. Apache NiFi fits visual, data-movement flows between systems and files, with its own clustering, provenance and flow versioning. Many estates use both. Camel LTS releases receive bug and security fixes for up to one year, so the release policy matters when you plan upgrades inside a closed network. Map your processes to these two categories before choosing, and do not assume one tool covers Boomi's API management, B2B/EDI or Flow apps, which need separate design.

What should we confirm with Boomi and our assessor before starting?

Confirm with Boomi, in writing, which runtime model you use today and what connectivity each component needs, because customer-hosted runtimes still initiate HTTPS connections to Boomi's platform and take its updates. Ask for the contractual end date of your subscription and any data export terms. Confirm with your assessor which controls they will test and which evidence they expect from an isolated environment. For a utility or other regulated operator under NERC CIP-005-7 or CIP-013-2, ask how the Electronic Security Perimeter, remote access path and software integrity checks for carried-in packages will be documented. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do.

How do we get a fixed quote for this work?

DeployOpen does not publish a price list. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. To request a quote, send your Boomi inventory or an estimate of process count, connector types, target environments, and the network boundary you operate, along with your compliance drivers. The written scope should list what is included and excluded, the assumptions behind the timeline, and any recurring support or upgrade retainer as a separate line. Compare proposals on the same scope definition rather than on headline totals.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For an isolated Boomi replacement, we start by confirming which integrations must run without any outbound path and then build Apache Camel or Apache NiFi entirely inside that boundary.

How we scope

Inventory every Boomi process, connector and runtime that must move into the isolated network before work starts.
Confirm which target systems are inside the enclosure and which data flows cross the boundary by approved media.
Agree deliverables, timelines and responsibilities in a written fixed-scope document before any build begins.

How we build

Install Apache Camel or Apache NiFi from artifacts staged through your approved transfer process, with no internet dependency at runtime.
Configure authentication, LDAP or OpenID Connect where available, and bind administrative interfaces to approved internal addresses.
Set up an internal container registry and package mirror so builds and upgrades never depend on public repositories.

How we hand over

Document the architecture, flow or route inventory, configuration, credential handling and the offline update procedure.
Provide evidence of hardening and integrity checks for every package carried across the boundary, to support your supply chain review.
Run a handover session with your operators so they can run upgrades, backups and restores without DeployOpen present.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped to your change approval process.
Test each new platform release in a staging copy of the isolated environment before it is approved for production.
Prepare the systems, controls and evidence your independent auditors and certification bodies will assess, without issuing attestations ourselves.