Self-hosted MuleSoft alternative for air-gapped networks

Running a MuleSoft alternative for air-gapped networks

Only Anypoint Platform Private Cloud Edition runs MuleSoft's control plane without internet access, and it leaves out analytics, monitoring, Anypoint MQ and Secrets Manager. The open-source route that runs fully inside an isolated network is Apache Camel for integration flows, with WSO2 API Manager for API management, both Apache-2.0 licensed. Moving to it means rebuilding the four gaps yourself: a self-hosted observability stack, a self-hosted broker for Anypoint MQ workloads, and a self-hosted secrets store. DeployOpen plans, implements and hardens this as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts.

Start with versions and build inputs, because an enclave cannot fetch them later. Apache Camel 4.22.1 is an LTS release supporting Java 17, 21 and 25, with end of life in August 2027, so confirm which JDK your approved image set carries. WSO2 API Manager 4.7.0 requires JDK 21 to build, and WSO2 supports on-premises installs from extracted packages. If the platform runs on Kubernetes, the kubeadm workflow of listing and pre-pulling images, then pointing kubeadm init at a private registry with --image-repository, is the pattern to confirm. Also plan an internal artifact repository for Maven dependencies, since Camel projects pull connectors at build time and an isolated network has no route to public repositories.

Plan the boundary controls alongside the software. Every package and patch carried across the isolated boundary needs a documented verification step for integrity and authenticity, the kind of supply chain control NERC CIP-013-2 describes for bulk electric system environments. If the network falls under NERC CIP-005-7, remote access must pass through an Intermediate System with multi-factor authentication. Cost splits into recurring items (internal engineering, infrastructure, optional vendor support from WSO2 or Red Hat for Camel) and one-time items (migration, the transfer process, hardening). Ask any quote to itemize update delivery into the enclave, security patch turnaround and who holds the signing keys.

What an air-gapped boundary requires from an integration platform

An isolated network removes the default assumptions of a hosted integration stack: no callbacks to a vendor control plane, no package pulls at install time, and no unmanaged remote access. The cards below set out what the platform, its supply chain and its operators must satisfy before Apache Camel and WSO2 API Manager can run inside the boundary.

No runtime calls outward

Every component the integration stack needs at runtime must be inside the boundary: the gateway, the management plane, the developer portal, the metrics pipeline and the connector endpoints. Test this by blocking outbound traffic and running representative flows, including token refresh, certificate checks and any telemetry or license callbacks the product attempts. Confirm each callback in writing with the vendor before you rely on an offline mode, because a product that works offline in demos can still fail on a timeout during a real flow.

Offline install with verified packages

Building the platform from public registries at install time fails inside an isolated network, so every image, package and dependency must be mirrored and staged ahead of time. Kubernetes shows the pattern: control plane images can be listed and pulled in advance, then pointed at a private registry. Record a checksum or signature for each artifact at the point it enters the enclave, and check it again at deployment. This is the practical form of the software integrity and authenticity control in NERC CIP-013-2, which applies where your regime requires it.

Patch cycles through controlled media

Patches cross the boundary on a schedule you control, not on the day a release appears. Plan a staging environment that receives each update, a regression run of your Camel routes and API policies, and a signed record of what was imported. The WSO2 release notes and Camel download page list versions and support windows you can compare against your own change calendar. Ask your vendor, or your own security team, how vulnerability notices reach the isolated network, since the advisory feed itself lives outside it.

Local secrets and logs

Credentials for connectors, OAuth clients and TLS keys must be stored and rotated inside the boundary, with no dependency on a hosted secrets service. The same applies to logs and audit trails, which need local retention and a path into your SIEM. Define who can read API keys, where gateway access logs go and how long they are kept. Hosted monitoring that MuleSoft bundles has no direct equivalent here, so confirm which collector, store and dashboard your team will operate.

Controlled interactive remote access

Vendor and administrator sessions into the isolated network should pass through a single intermediate system with encryption and multi-factor authentication. The control described in NERC CIP-005-7 also expects you to detect active remote sessions and disable them, which is a monitoring task as much as a network one. Apply the same pattern to contractor access for patching and troubleshooting. This requirement applies where your organization is subject to NERC CIP, so confirm its scope with your compliance lead.

Vendor support across the boundary

Commercial support for an air-gapped gateway usually means a subscription that covers patches and expert help, and the support route must work without the vendor reaching into the network. Ask whether support staff can work through a jump host, whether they need remote sessions, and how they receive diagnostic bundles. Keep a written list of who holds administrative credentials for each component, so that an incident does not depend on one person.

Where MuleSoft Private Cloud Edition meets the constraint and where it stops

Only Anypoint Platform Private Cloud Edition runs MuleSoft's control plane on premises without internet access, which makes it the one MuleSoft option that can sit inside an isolated network. The other documented paths do not fit. CloudHub and CloudHub 2.0 are managed by MuleSoft, hybrid deployments connect customer-managed Mule servers to the Anypoint control plane, and Runtime Fabric runs on customer infrastructure but still depends on that hosted control plane. Before you plan around Private Cloud Edition, confirm with MuleSoft which components it includes in your contract, because the packaged scope is what decides whether your team operates the control plane itself or only the runtimes.

The gaps matter as much as the fit. Analytics, monitoring, Anypoint MQ and Secrets Manager are not part of Private Cloud Edition, so an isolated deployment needs its own answers for observability, messaging and secret storage. Ask MuleSoft in writing which of these work offline, which need a connection to Anypoint services, and how license keys, entitlement checks and component updates reach a network with no outbound path. Treat the answers as part of the scope, not as details to resolve during cutover.

The runtime choice also changes what you can run inside the boundary. Anypoint Studio documentation states that the Mule Community runtime does not support all Enterprise features and that switching from Enterprise to Community may leave some configurations unsupported. Run an inventory of every flow, connector and policy against the edition you plan to use, and list any dependency that exists only in Enterprise. That inventory is the input for the comparison with Apache Camel and WSO2 API Manager, which run without a vendor-hosted control plane.

Which open-source options run inside an isolated network

Apache Camel is the integration engine most teams would put in place of Mule flows. It is licensed under Apache-2.0 and maintained by the Apache Software Foundation, and its repository lists more than 350 connectors, including Kafka, REST, JDBC, AWS, Azure, GCP and Salesforce. Routes can be written in Java, YAML or XML, and the same routes can run on Spring Boot, on Quarkus, from the Camel CLI, on Kubernetes through Camel K, or standalone. Because the engine is a library and a runtime you deploy yourself, it has no internet dependency of its own once artifacts are in your internal repository.

Release choice: Apache Camel 4.22.1 is an LTS release supporting Java 17, 21 and 25, with end of life in August 2027. Camel 4.18.5 LTS ends in February 2027.
Support window: LTS releases receive bug and security fixes for up to one year, according to the Camel download page. Non-LTS releases such as 4.23.0 have a shorter life.
What Camel does not include: there is no hosted control plane, no monitoring console and no equivalent of Anypoint Exchange. You assemble those from your own observability and catalog tools.
Visual design: Kaoto is an Apache-2.0 visual designer for Camel, distributed as a VS Code extension. Treat it as a separate component to assess for offline use and supply-chain review.

Confirm which Camel LTS line your internal Java baseline supports and whether your build pipeline can mirror every Maven dependency.

How to deploy and operate the stack with no internet access

This sequence moves Apache Camel, WSO2 API Manager and their Kubernetes foundation into an isolated network from artifacts verified outside it, and leaves a repeatable process for keeping them current without reopening the boundary.

Build and verify the transfer bundle outside the boundary
On a connected staging host, your platform team collects the container images, Maven dependencies, Kubernetes binaries, operating system packages, WSO2 API Manager distribution and Camel artifacts you need, pinned to specific versions. Record a checksum for every file, sign the manifest where your process allows it, and scan the bundle with the tools your security team approves. Your supply chain risk procedure should define who approves each item before it crosses. The step is complete when a second person has independently verified the manifest and the bundle is logged in your change system. Confirm the supplied build requirements for each component, including the JDK version that WSO2 API Manager 4.7.0 requires, before you assemble the bundle.
Stand up a private registry and load images
Inside the boundary, your team deploys a private container registry, such as Harbor, and imports the verified images from the transfer bundle. Access is restricted to your build and cluster service accounts, and TLS is configured with certificates from your internal authority. The registry becomes the only image source for every node. Test by pulling each image from a node with no outbound route. The step is complete when every image in the manifest pulls by digest and the image list matches the approved manifest exactly.
Pre-pull Kubernetes control plane images
On the staging host, run the kubeadm command that lists the control plane images for your target version, then pull them, so the set is known before anything is installed. Mirror them into the private registry and confirm that the image tags match the list. Keep the list and the pulled images in the transfer bundle so the same versions are used for every node. The step is complete when the image list from kubeadm and the registry contents agree, with no tag resolved from a public source.
Initialize the cluster against the private registry
On the first control plane node, run kubeadm init with the image repository flag pointed at your private registry, so the control plane pulls only from inside the boundary. Join the remaining control plane and worker nodes with the same registry setting. Install the cluster network add-on and any ingress controller from verified artifacts stored in your registry or artifact store. The step is complete when all nodes report Ready and a test workload schedules and starts using only images from your registry.
Deploy Camel routes and WSO2 API Manager from verified artifacts
Build Camel applications on a connected host or in an approved build environment, then package them as container images or Maven artifacts and push them to the internal registry or repository. Deploy them to the cluster through manifests stored in your Git server, which is also self-hosted inside the boundary. For WSO2 API Manager, extract the distribution package on premises and follow WSO2's offline installation steps for the components you run. Confirm those steps with WSO2 and the Apache projects before you execute them. The step is complete when the gateway serves a test API, the publisher and developer portal load, and a Camel route processes a test message end to end.
Configure local identity, logging and secrets
Point WSO2 API Manager and the Camel services at identity sources hosted inside the boundary, such as an internal directory or a self-hosted identity provider, rather than any external service. Send gateway, cluster and application logs to a log store on the internal network, and confirm that no exporter is configured to reach a public endpoint. Store credentials and certificates in a secrets store running inside the boundary, and rotate the initial bootstrap credentials. The step is complete when a documented login succeeds with a local account, a log entry appears in the internal store, and a network test from the cluster shows no outbound route.
Set a repeatable offline update cycle
Define a recurring process in which the staging host gathers new releases and security fixes, the transfer bundle is rebuilt, verified and approved, and the registry and cluster are updated from it. Track each component's support status from its project or vendor documentation, and keep a rollback path by retaining the previous bundle. Ask your vendors and project maintainers which security notices they publish and how they reach air-gapped customers. The process is complete when one full cycle has run in a test enclave and produced an updated, verified bundle with a recorded change ticket.

Operating controls for a disconnected platform

Once Apache Camel and WSO2 API Manager run inside an isolated network, the controls that vendors normally provide as hosted services become your responsibility. The four areas below cover patching, monitoring, secrets and messaging, and each replacement is built and sized by your team or implementation partner against your own workload.

Patch and version management

Track Camel and WSO2 release lines separately and decide which line each environment follows before anything is installed. Camel LTS releases receive bug and security fixes for up to one year, so pick the LTS line that matches your Java version and end-of-life date. WSO2 API Manager needs JDK 21 to build from source, so confirm the JDK your offline build pipeline can supply. Every patch must be downloaded outside the boundary, scanned, and carried in through your approved transfer process.

Local monitoring and logging

Hosted analytics and monitoring dashboards do not exist inside an air-gapped network, so metrics, logs and gateway traces must be collected and stored locally. Decide where Camel route metrics and WSO2 gateway logs go, how long they are kept, and who reviews them. Confirm that every component you add, such as a metrics store, log shipper or dashboard, has an offline installation method and an offline update path. Plan the retention period with your compliance team before you size storage.

Local secrets handling

Anypoint Secrets Manager does not run inside the isolated network, so credentials for connectors, database users and API keys need a local store with its own access policy. Choose a secrets manager that runs fully offline, and confirm how it is unsealed after a restart and who holds the recovery material. Camel routes and WSO2 configuration files should reference secrets by name rather than storing values. Test rotation end to end, because a rotation that depends on an external service will fail in this environment.

Messaging to replace Anypoint MQ

Anypoint MQ is a hosted queue service, so the isolated network needs a self-hosted broker such as Apache Kafka to carry messages between Camel routes and downstream systems. Size partitions, retention and consumer groups against your real message volumes, and load test the broker before cutover. Operating a streaming platform adds clusters, storage, upgrades and on-call duties that a queue service previously absorbed. See the sibling topic on replacing Anypoint MQ with Kafka for the mapping of queues and acknowledgments.

What do buyers ask before moving an air-gapped integration stack?

What does moving an air-gapped integration stack cost?

The cost is a set of components, each paid to a different party. Anypoint Platform Private Cloud Edition is a MuleSoft subscription, and its price is set in your MuleSoft contract, so check the renewal terms. Apache Camel and WSO2 API Manager are Apache-2.0 licensed, so there is no license fee for the open-source code. Recurring costs include the hardware or virtual capacity in your enclosure, staff time to patch and operate the stack, and any WSO2 subscription you choose. One-time costs include rewriting flows and DataWeave scripts, building the offline package pipeline, and testing. Ask any provider for a quote built from a written scope that lists each component separately.

How long does an air-gapped migration take?

No duration can be stated for your environment without a scope, because the answer depends on the number of flows, connectors, custom code, API policies and the approval steps in your enclosure. The main drivers are how many Mule applications you run, how many DataWeave transformations need rewriting, how often the offline package carry process runs, and how quickly your security reviewers can approve each transfer. Plan the work per application so you can cut over one service at a time. Ask any provider to state its phases, deliverables and dependencies in the written scope before work starts.

What does the work need from our internal team?

Your team needs to own decisions that only your organization can make. Expect to provide access to the isolated network, approval for each package or image carried across the boundary, a list of applications and their owners, and business sign-off on cutover windows. Engineers who know your Mule flows, your identity provider, your database and message platforms, and your logging standards will shorten the discovery phase. You also need staff who will run the stack after handover, including patching, certificate management and backup checks. Confirm these responsibilities in the scope so that no step is left unassigned.

Can our team run an air-gapped Camel and WSO2 stack without outside help?

Yes, a capable internal team can do it, but it needs the skills and time to do it well. Apache Camel runs on Spring Boot, Quarkus, the Camel CLI, Camel K on Kubernetes, or standalone, so your engineers must choose a runtime and build a delivery process. WSO2 API Manager is supported on premises from extracted packages and on Kubernetes through its separate API Platform for Kubernetes. Building the offline image and package repositories, plus the vulnerability and integrity checks that NERC CIP-013-2 describes for other regulated sectors, adds work. Many teams split the job, keeping ownership in-house while buying targeted help for design, hardening or testing.

Do we need a WSO2 subscription to run API Manager in an air-gapped network?

WSO2 API Manager is Apache-2.0 licensed, so you can use the open-source code without a subscription. A WSO2 commercial subscription adds expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use, according to the WSO2 repository. Whether you need those items depends on your risk tolerance, your staff's experience, and whether your regulator expects vendor-backed patch timelines. Confirm the licensed distribution terms with WSO2 before deploying in production, and weigh the subscription against the cost of staffing the same support in-house.

What breaks when an isolated network loses its internet connection?

Several things depend on outside connections, so check each one before cutover. Container images, Maven artifacts, Camel components and operating system packages must be mirrored into the enclosure or carried in as signed bundles. Kubernetes clusters need their control plane images pulled in advance, and kubeadm init can point at a private registry through its image repository flag. Monitoring, certificate authorities, time sources and license checks must also work internally. Test a cold install from the offline bundle before you rely on it, since a missing dependency often surfaces only during an upgrade.

What compliance evidence should we prepare before the move?

Prepare the evidence that your assessors will ask for, and remember that DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those decisions. Document the boundary, the approval record for each package carried across it, the vulnerability and integrity checks, access control for administrators, and the change records for each cutover. If your sector follows NERC CIP-005-7, prepare evidence for the Electronic Security Perimeter and the remote access controls. Ask your assessor which artifacts they accept before the work starts.

How does DeployOpen fit into an air-gapped migration?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope to name each system, the deliverables for each phase, the responsibilities of your team, and the handover checklist.

What auditors and regulators ask to see

Auditors and regulators will expect a trust boundary record before they look at anything else. For an air-gapped Apache Camel and WSO2 API Manager deployment, that means a dated architecture diagram showing every Camel runtime, the WSO2 gateway, Publisher, Developer Portal and traffic manager, the database and message brokers, and every point where data or software crosses the isolation boundary. Name each transfer path, who may use it, and which control approves it. If you operate under NERC CIP-005-7 or a similar rule, confirm with your assessor how they expect Interactive Remote Access and the Electronic Security Perimeter to be documented for this environment.

The second body of evidence is the software inventory and import record. List every Camel release, WSO2 API Manager release (4.7.0 was released on April 29, 2026, and building it requires JDK 21), connector library, container image and operating system package, with versions and cryptographic hashes. Each package carried across the boundary needs a recorded integrity and authenticity check, which is the control NERC CIP-013-2 describes for vendor software and patches. Keep the signed transfer log, the reviewer's name and the decision for each import. Records of offline patching belong here too: dates, the advisories reviewed, and what was deferred and why.

Finally, expect questions about access, remote sessions and logs. Document who holds administrator roles in WSO2 API Manager and in the Camel runtime hosts, how those accounts are reviewed, and how vendor or support sessions are opened, encrypted, authenticated and terminated. Retain authentication, configuration change and gateway access logs in a location the isolated network controls. Confirm retention periods with your compliance lead. DeployOpen prepares systems, controls and evidence for these reviews, but it does not issue audit reports or certifications. Independent auditors and certification bodies decide whether your environment conforms.

How DeployOpen deploys inside an air-gapped network

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including isolated networks. For a move off MuleSoft into Apache Camel and WSO2 API Manager, the work starts with a written scope that defines which integrations and APIs move and how the isolated environment is built.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which Mule applications, APIs, connectors and portals move into the isolated network.
We confirm the offline boundary, package transfer process and which vendor support you will keep.

How we build

We prepare Camel runtimes and WSO2 API Manager on Kubernetes or packages inside your network, with images and dependencies staged in advance.
Every package carried across the boundary is checked for integrity and authenticity before it is installed.
Integrations are rebuilt and tested in the isolated environment, with security testing of APIs and the gateway before cutover.

How we hand over

Deliverables include runbooks for offline installation, upgrades and recovery, plus configuration and architecture documentation.
Evidence for your compliance assessment is prepared, but audit reports and certifications come from independent auditors.
Your team receives walkthroughs and an offline update procedure that they can run without outside access.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover backups, patching through approved media and periodic testing of the isolated stack.
Support scope and response arrangements are confirmed in writing alongside the original engagement.