Does Logic Apps hybrid meet an air-gapped or sovereignty requirement?
If your Logic Apps estate sits behind an air-gapped network or under a data sovereignty rule that forbids outbound traffic, Logic Apps hybrid still needs outbound connectivity to Azure, so it does not meet a strict no-egress requirement. A fully self-hosted stack built on n8n or Apache Camel can run with no route to the internet at all, because the workflow engine, connectors and credentials all live inside your own network. This page compares those two options so you can decide which path fits the controls you must satisfy. The right choice depends less on the deployment model than on two things: which connectors your workflows depend on and what skills your team has. Hybrid keeps Microsoft's managed connectors and designer, but those connectors call services outside your boundary. n8n gives you a visual canvas with a large integration catalog and custom code. Camel gives you code-first routes and components suited to message-heavy integration. Before you commit, inventory every connector and endpoint each workflow touches and mark which ones can be reached from inside the enclave.
Do not assume hybrid is non-compliant, and do not assume a self-hosted stack is compliant by default. Confirm with Microsoft, in writing, exactly which control-plane and metadata calls a hybrid deployment makes, how often, and what happens if they are blocked. Then take that evidence to your assessor and ask how they will test a no-egress boundary against your specific system categories, including whether any NERC CIP-005-7 Interactive Remote Access or CIP-013-2 software integrity obligations apply to the integration layer. Ask the assessor to name the evidence they expect for each one.
What the constraint requires from the integration runtime
A hybrid runtime and a fully self-hosted stack differ mainly in where connections start and who controls them. The requirements below are the ones an isolated or regulated network usually imposes on any integration runtime, whichever product runs on it. Confirm with your compliance team which regime applies to each system before you treat any of them as binding.
No inbound firewall ports
The runtime should accept no connections initiated from outside the network it sits in. Workato's on-prem agent illustrates the pattern: it makes only outbound connections over a TLS WebSocket tunnel and needs no inbound firewall ports. For Logic Apps hybrid, check which outbound endpoints the Azure control plane needs and whether your firewall can allow them. For a self-hosted n8n or Camel stack, confirm that webhooks and triggers reach the runtime through a controlled path rather than an open port.
Controlled outbound paths
Every outbound destination the runtime uses should be listed, approved and logged. In a hybrid model this includes Azure endpoints that the workflow engine needs to stay connected. In a fully self-hosted model the list covers the systems your workflows call, such as ERP, messaging and databases. Ask each vendor or project to document its outbound traffic, then route it through a proxy or egress policy that your security team can audit.
Verified software integrity for carried packages
When packages, container images or connector updates cross an isolated boundary, each one needs a verified origin and checksum before it is installed. NERC CIP-013-2 addresses this through supply chain procurement processes that cover verification of software integrity and authenticity for vendor software and patches. Build an internal mirror, record hashes for each artifact and keep the import log as evidence. Confirm with your auditor how the control applies to your environment.
Vendor remote access controls
Where vendors or integrators need to reach the runtime, NERC CIP-005-7 expects remote access to pass through an Intermediate System with encryption and multi-factor authentication. The standard also expects methods to detect active vendor sessions and disable them. Decide whether vendor support for a hybrid Logic Apps deployment or a self-hosted stack will use a jump host, and confirm that the session controls you need exist in your chosen tooling before the contract is signed.
Credential storage under your control
Connection credentials are the most sensitive data a runtime holds. In a self-hosted n8n queue setup, the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials. Decide where that key lives, who can read it and how it rotates. Compare this with a hybrid model, where connection details for Azure-managed connectors may sit in Azure. Document the answer for each option before deciding.
Where Logic Apps hybrid still reaches Azure
Logic Apps hybrid deployment runs the workflow runtime on your own Kubernetes cluster, but it does not remove Azure from the picture. The service plane, which handles workflow management and the control functions that tie the runtime to Azure, still needs outbound connectivity from your cluster to Azure endpoints. Inbound access from Azure into your network is not the requirement to plan around. The requirement is that the cluster can reach specific Azure destinations over the network path you allow. For an air-gapped or sovereignty-driven design, that means the hybrid option is not a fully disconnected runtime, and the decision has to be made before any architecture work starts.
Do not treat the hybrid dependency as a general statement you can accept or reject from a summary. Ask Microsoft for the current endpoint list, the connectivity model and the required outbound ports for your region and Logic Apps version, and get them in writing. Ask for the licensing terms for hybrid vCPU as well, including how capacity is counted, whether idle capacity is billed and what changes if you scale the cluster. These details change over time and vary by deployment, so none of them should be inferred from older documentation or a blog post. Record the answers in your architecture decision record so the security and compliance reviewers see the same facts you based the design on.
Once you have the endpoint list, have your network and security teams map each destination to a firewall rule, a proxy policy or a DNS entry, and decide whether traffic can leave through an egress gateway that logs and inspects it. Confirm what data, if any, flows to Azure during normal operation and during failure, and whether a loss of that connectivity stops workflows or only blocks management actions. Compare the answers with the standards your auditors use, such as NERC CIP-005-7 for remote access control at high and medium impact systems. Where the answers show a dependency you cannot accept, that is the point to evaluate a fully self-hosted runtime.
Which self-hosted option fits which environment
Air-gapped networks have no path to Azure, so a hybrid Logic Apps runtime that expects outbound connectivity is the first thing to test. A fully self-hosted stack has to be installed, patched and updated from media that crosses the boundary, which makes packaging and offline installation part of the design. Kubernetes can be built without internet access by pulling control plane images in advance and pointing kubeadm at a private registry. Teams also need to confirm that each product they pick has an offline install path, because some vendors reserve air-gapped deployment for paid editions.
- Offline installation: Confirm that the platform, its container images and its plugins can be installed from a private registry and an internal package mirror.
- Licensing for isolated use: Check whether the edition you plan to run allows the deployment model you have, since air-gapped support is often a paid-edition feature.
- Update path: Ask how new releases, connector packs and security fixes arrive across the boundary and how each package is verified before import.
- Connector reach: Map which internal systems each workflow touches, because connectors that call external SaaS endpoints will not work without a proxy or a local equivalent.
Ask the vendor for its written offline installation and update procedure before you commit to a platform.
A sovereign cloud setup often allows outbound connections to approved endpoints while keeping data, compute and keys in a jurisdiction the organization controls. In this environment the question is less about connectivity and more about where workflow data, credentials and execution logs are stored. Logic Apps hybrid still depends on Azure for part of its control plane, so the sovereignty review has to cover that dependency explicitly. A self-hosted n8n or Camel deployment keeps the runtime in the organization's own accounts, but the team owns the uptime, backups and patching that Azure previously carried.
- Data location: Document where executions, credentials and logs are stored, including backups and any managed database used for the platform.
- Outbound allow-list: Limit egress to the specific SaaS and API endpoints each workflow needs and log every outbound call.
- Credential handling: For n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor, so store that key in your secrets system and restrict who can read it.
- Operating ownership: Assign who runs upgrades, backups and incident response, because no vendor cloud will do this for you by default.
Confirm with your legal and security teams which control set your sovereignty requirement maps to before choosing a deployment model.
Teams moving message-heavy, B2B or long-running integrations usually need routing, transformation and delivery semantics that go beyond a visual automation canvas. Apache Camel is licensed under Apache-2.0, lists 350+ connectors including Kafka, JDBC, Azure and Salesforce, and lets teams write routes in Java, YAML or XML. Camel runs on Spring Boot, on Quarkus, from the Camel CLI or on Kubernetes through Camel K. Its LTS releases receive bug and security fixes for up to one year, and Red Hat sells commercial support for the Red Hat build of Apache Camel on Spring Boot and Quarkus runtimes. n8n covers many of the same integrations with a visual canvas, but its multi-main high availability setup is restricted to Enterprise self-hosted deployments.
- Route authoring: Choose Java, YAML or XML based on the skills your integration team already has, and plan code review and CI for routes.
- Release lifecycle: Pin to an LTS release, and check the supported Java version and end-of-life date on the Camel download page before you build.
- Commercial support: Decide whether you need a vendor support contract for production, and confirm which runtime and subscription it covers.
- Kubernetes fit: Camel K suits teams that already run Kubernetes and want integrations deployed as lightweight workloads.
With Camel you take on the skills and code ownership, so confirm your team can staff those roles before you choose it.
Hybrid Logic Apps, n8n and Apache Camel side by side
This table compares hybrid Logic Apps with self-hosted n8n and Apache Camel on egress, licensing, connectors, high availability, deployment and skills. Items marked as confirmation points should be verified with Microsoft or the vendor before you rely on them. The main takeaway is that the two self-hosted options remove the Azure dependency, but each moves licensing, HA and support decisions onto your team.
| Dimension | Logic Apps hybrid | Self-hosted n8n | Apache Camel |
|---|---|---|---|
| Egress dependency | Workflows run on your Kubernetes but need outbound Azure connectivity. Confirm required endpoints with Microsoft. | Runs without Azure once installed. Confirm the outbound endpoints each connector you use requires. | Runs without Azure. Offline clusters need images pulled in advance and a private registry. |
| Licensing | Hybrid runtime terms and billing are set by Microsoft. Confirm current terms for your region and tier. | Sustainable Use License covers internal business use. Files with .ee in the name need an Enterprise license. | Apache-2.0 licensed. No license fee for the framework itself. Commercial support is optional. |
| Connector coverage | Large managed connector catalog. Confirm which connectors run in hybrid mode and which need Azure services. | Advertises more than 1,500 integrations. Verify each connector you depend on before migrating. | Lists 350+ connectors, including Kafka, JDBC, REST and Azure. Check Azure components against your needs. |
| High availability edition limits | Confirm the HA model and any SLA terms with Microsoft for the hybrid runtime. | Multi-main HA is limited to Enterprise self-hosted. Community edition does not include it. | No edition gate in the framework. HA depends on your Kubernetes and broker design. |
| Deployment model | Workflows run on your Kubernetes, with design and management tied to Azure. | Docker Compose or Kubernetes. Queue mode uses Redis and PostgreSQL with worker pools. | Spring Boot, Quarkus, Camel CLI, Camel K on Kubernetes, or standalone. |
| Support and LTS | Support terms come from your Microsoft agreement. Confirm what covers the hybrid runtime. | Enterprise adds dedicated support with an SLA. Confirm what Community users receive. | LTS releases get fixes for up to one year. Red Hat sells commercial support for its Camel build. |
| Skills needed | Azure and Logic Apps designer skills, plus Kubernetes operations for the hybrid runtime. | Visual workflow building, with JavaScript or Python for custom code and PostgreSQL and Redis operations. | Java, YAML or XML route authoring, plus JVM and Kubernetes operations and broker design. |
How to deploy a fully self-hosted stack without internet access
This sequence takes a Logic Apps estate from inventory to a self-hosted n8n or Apache Camel stack that runs inside an isolated network, with each stage checked before the next begins. The result is a cluster, container and package supply chain, and remote access model that your own security and compliance teams can review.
Build the workflow and connector inventory
Your integration team exports every Logic Apps workflow definition and lists the managed connectors and API connections each one uses, so you know which external systems the new stack must reach. Start from the export described in your migration plan and record triggers, schedules, data classifications and the networks each endpoint lives on. Confirm the list with the workflow owners. The step is done when every workflow has an owner, a target platform (n8n or Camel) and a list of required connectors, and the list is stored in your change system.
Prepare the Kubernetes control plane images offline
On a staging machine with internet access, the platform team runs kubeadm config images list to get the control plane image names for the chosen Kubernetes version, then kubeadm config images pull to download them. The images are saved to media that is approved for transfer into the isolated network. Confirm the Kubernetes version against your own support policy before pulling. The step is done when the image list matches the version you intend to run and every image has been verified against the checksums your supply chain process requires.
Point kubeadm at a private registry
The platform team loads the transferred images into a private registry inside the isolated network, then runs kubeadm init with the --image-repository flag set to that registry. The cluster networking, certificate and node join settings come from your own architecture decisions. Work with your security team to confirm which registry, storage and access controls hold the images. The step is done when kubeadm init completes against the private registry, all control plane pods start without pulling from public hosts, and the node join token process works inside the boundary.
Mirror container images and packages through a verified path
Each container image, Helm chart, npm or Python package, and Camel dependency that the stack needs is pulled on the outside, scanned, signed or hashed, and then carried across the boundary as a single approved bundle. Inside the network, the bundle is loaded into the private registry and package mirror, and the platform team blocks direct access to public registries from cluster nodes. Keep a manifest of every artifact and its version. The step is done when a test deployment pulls everything from internal sources only, and the manifest matches what was transferred.
Deploy n8n queue mode or Camel on Kubernetes
For n8n, the platform team deploys a main instance, worker pool and webhook processors, with PostgreSQL for workflow data and Redis to pass executions between processes. The main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials, so store that key in your secrets manager and confirm the handling with your security team. For Apache Camel, teams deploy routes with Camel K on Kubernetes. Choose the path that matches your workflows and licensing review. The step is done when test workflows run end to end, credentials decrypt on every worker, and a restart of a worker does not lose queued executions.
Harden remote access and vendor sessions
The security team limits administrative and vendor access to the cluster and the integration platform through an intermediate point that requires encryption and multi-factor authentication, and records or can end active remote sessions. The model should follow the intent of NERC CIP-005-7 where it applies to your environment, which means confirming with your compliance lead whether that standard governs your systems. Confirm all inbound paths, and remove any route that the isolated design does not need. The step is done when a documented access diagram exists, a tested session can be terminated, and no workflow component accepts connections from outside the boundary.
Set up a patch and integrity review
Before each future transfer of software or patches, the team reviews the source, checks hashes or signatures, and records who approved the change. This follows the supply chain verification idea in NERC CIP-013-2 where it applies. Confirm with your procurement and compliance teams which evidence they require and how often reviews must recur. The step is done when a repeatable procedure exists, a sample patch has passed the full review in a test environment, and the approval record is stored where auditors or assessors can find it. DeployOpen can help prepare these controls and evidence, but independent auditors issue any assessment results.
What changes for operations and integration teams
The main change is that the team takes over the runtime. With Logic Apps hybrid, Microsoft still operates the control plane and the service boundary, while your team runs the Kubernetes hosts. With a fully self-hosted stack, your team also owns patching, upgrades, backups, monitoring, certificate rotation and high availability for the integration engine itself. Before committing, list each of these tasks, name an owner and a backup owner, and confirm the on-call path for a failed workflow run at 2 a.m. The boundary of responsibility moves from a managed service to your own network, so the security and change records you previously got from the vendor now have to be produced by your team.
The two candidate engines ask for different skills. For n8n, high availability is a licensing question as much as an architecture one: multi-main setup, which runs several main instances, is restricted to Enterprise self-hosted deployments and is not available in the Community edition. Queue mode also requires that the main instance's encryption key is shared with every worker and webhook processor, so key handling becomes an operational control you must document and rotate. Confirm with n8n which edition and license your environment needs before you size the cluster. For Apache Camel, the work is code-first: routes are written in Java, YAML or XML, and the team needs Java runtime support, build pipelines and testing skills. Confirm which Camel release line and Java version your standards allow, and plan for a supported runtime such as Spring Boot or Quarkus.
Expect a period in which both platforms run in parallel while the team learns its new duties. Ask any vendor or partner to show a runbook covering upgrades, rollbacks and restores in your environment, not only a reference architecture. Where a vendor documents that a capability is a paid-edition feature, record that in the operating model so the cost of high availability and support is visible to the people who approve the budget.
Evidence assessors ask for under this constraint
Assessors reviewing an isolated or sovereign deployment want proof of what can reach the platform, what entered it, and whether it can be recovered. The six artifacts below connect those questions, and each one should be produced from the environment that will actually run the workflows. DeployOpen prepares this evidence for your assessors, but independent auditors and certification bodies issue any opinion on it.
Network and architecture diagrams
Show every workflow runtime, queue, database and worker, with each network zone and the direction of every flow. For a Logic Apps hybrid design, the diagram must show the outbound connections to Azure and whether any inbound port exists. For a fully self-hosted n8n or Camel stack, the diagram should show no path to a public endpoint at all. Ask the assessor which boundary they treat as the enforcement point, then confirm the diagram matches the firewall rules in place.
Egress allow lists
List each destination the platform may contact, including connector endpoints, package mirrors, license checks and telemetry. Each entry needs an owner, a port, a protocol and a business reason. Review the list against live firewall logs, because an allow list that was written from the design and never tested often misses a dependency. For hybrid Logic Apps, the list should be narrow and tied to the specific Azure regions and services in use.
Offline artifact inventory with integrity checks
Record every container image, package, workflow definition, connector and rule set brought across the isolated boundary, with its version and a cryptographic checksum. Keep the transfer record showing who approved each item and when it crossed. This is the evidence behind software integrity and authenticity claims for vendor code. Confirm that your procurement process requires this check for each update, not only for the first installation.
License records for n8n editions or Camel releases
Keep a record of which n8n edition runs in each environment, and whether any file that carries an .ee name is present or in use. The Sustainable Use License limits use to internal business purposes or non-commercial use, so a production n8n deployment needs an edition and terms that match how the organization uses it. For Apache Camel, record the exact release, its support status and the Java version it runs on, so patch decisions can be traced to a specific version.
Access logs for vendor sessions
Log every session in which a vendor, support engineer or managed service reaches the platform, with the account, time, approval reference and the actions taken. Where a connection is outbound-only, such as the tunnel used by an on-prem agent, log the tunnel's establishment and teardown as well. The assessor will look for a method to detect and end an active vendor session, so test that the operator can cut the connection and record the result.
Tested backup and restore runs
Keep dated records of restore tests, not just backup jobs. For a queue-mode n8n deployment, a restore must recover PostgreSQL data and the encryption key that protects stored credentials, so the key must be backed up separately and handled under the same access controls. Record the time taken, what was verified and any failures. Ask your team to confirm that the restore runs without reaching the internet, since an isolated environment that depends on outside access will fail at the moment it is needed.
Questions buyers ask before choosing a self-hosted integration stack
Does hybrid Logic Apps meet an air-gapped requirement?
Usually not on its own. Hybrid Logic Apps runs workflow hosting on your own Kubernetes, but it still needs outbound connectivity to Azure for the control plane and for managed connectors, so a strict air-gapped rule is generally not met by that design. Confirm the exact requirement with your assessor and ask Microsoft in writing which Azure endpoints the hybrid runtime must reach in your environment. If the rule forbids any outbound path, a fully self-hosted stack such as n8n or Apache Camel, installed from offline image bundles, is the option to evaluate. Kubernetes can be built without internet access by pre-pulling control plane images and pointing kubeadm at a private registry, and each package carried across the boundary should be verified for integrity and authenticity.
What drives the cost of self-hosting an integration stack?
Cost splits into one-time build effort and recurring operations. The one-time part covers workflow inventory, rebuilding connectors, testing, hardening and documentation. The recurring part covers compute, storage, databases, backups, patching, monitoring and the staff who run them. Licensing matters too: n8n's Community edition is free, but use is limited by the Sustainable Use License, and Business or Enterprise features such as SSO, Git environments and multi-main high availability sit in paid editions. Apache Camel is Apache-2.0 licensed, so cost shifts toward engineering skill and support. Ask any provider for a quote that separates build, licensing, infrastructure, support and retainer fees.
How long does a migration from Logic Apps take, and what drives that?
No duration can be stated without a scoped inventory, so treat any early number with caution. The main drivers are the count and complexity of workflows, how many managed connectors and API connections must be replaced, whether integration account artifacts such as schemas and maps need rebuilding, how much retry and idempotence logic exists, and how many systems must be tested before each cutover. Workflows that run in parallel during cutover add effort. Ask for a timeline tied to a written scope, with milestones per workflow group, and confirm which assumptions about your environment it depends on.
What does the work need from our own team?
Expect contributions from several roles throughout. Integration owners must confirm business rules and data contracts for each workflow. Platform engineers must provide the Kubernetes or VM platform, network paths, secrets handling and registry access. Security must approve the data flows, encryption key handling and access model. Application owners must validate test results and sign off cutover. For n8n queue mode, the encryption key must be shared with every worker and webhook processor, so key custody needs a named owner. Ask the provider to list these responsibilities in the written scope so that gaps are visible before work starts.
Can our team run this migration and operations ourselves?
Often yes, if you have engineers who already run Kubernetes or Java services and who can own the platform after handover. The questions to answer honestly are whether you have people to rebuild and test each workflow, to patch and back up the platform, and to respond to incidents. Camel requires Java and routing skills, while n8n is faster for teams comfortable with visual workflows and JavaScript or Python code. A fixed-scope engagement can cover the build and handover, and ongoing support, upgrades and continuous testing are available as retainers. Ask for a skills gap review as part of the scope before deciding.
Which n8n edition is needed for high availability?
Multi-main setup, which runs several main instances for high availability, is restricted to Enterprise self-hosted deployments and is not available in the Community edition or n8n Cloud. Queue mode, which passes executions through Redis to a pool of workers that use PostgreSQL, is a separate scaling pattern, and you should confirm which of its features your intended edition includes. Business licensing enables SSO and LDAP, Git environments and log streaming, while Enterprise adds dedicated support with an SLA. Check current terms on n8n's pricing page and request the edition matrix in writing before designing the architecture.
How does Apache Camel LTS support affect our planning?
Camel LTS releases receive bug and security fixes for a longer period, up to one year, so they suit platforms you cannot upgrade often. The supplied release data lists Camel 4.22.1 as LTS with end of life in August 2027, and Camel 4.18.5 LTS with end of life in February 2027, while Camel 4.23.0 is a non-LTS standard release. Plan upgrade windows around those end-of-life dates, pin to an LTS line for regulated production, and test each upgrade against your routes. Red Hat offers commercial support for its build of Apache Camel if you need a contracted support path. Confirm the current release table on the Camel download page before committing.
How DeployOpen deploys this under your constraint
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For a Logic Apps replacement, that means the n8n or Apache Camel runtime, its database, its container or Kubernetes layer and the update path for each would run in your accounts or data center, with no dependency on an Azure control plane. The engagement covers the parts that the open-source project does not decide for you: the network boundary, how images and packages are brought across it, identity and secrets, backup and restore, and the written runbooks your operations team will use after handover. DeployOpen also prepares systems, controls and evidence for compliance assessments, such as the configuration records and access logs a NERC CIP or other assessor will ask for, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
Engagements are fixed-scope. Before work starts, the written scope names the workflows in or out of the first wave, the target environment, the connectors that must reach internal systems, the deliverables such as architecture documents, deployment code, test records and runbooks, and the acceptance criteria for each. A quote follows from that agreed scope, so your cost reflects the decisions you have made about hosting, high availability, and how many integrations need custom work. Ask for the quote to break out one-time build and hardening work separately from any recurring retainer for upgrades, monitoring and continuous testing. Ask also whether the license tier you need, such as n8n's self-hosted Business or Enterprise options, is priced separately from the implementation and whether it is required for your high availability design. Confirm those license terms with the vendor, because they change the total.
Before the scope is signed, decide three things that shape the design. First, whether the isolated segment can reach any update source at all, or whether every image, package and rule set will be transferred on approved media and verified for integrity, the control behind NERC CIP-013-2's supply chain requirement. Second, whether any remote access into the segment is needed, since NERC CIP-005-7 requires Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication. Third, who owns each credential, because in n8n queue mode the main instance's encryption key must be shared with every worker, so that key needs a documented custody and rotation process. Your regulator, not DeployOpen, decides whether your environment is in scope for any given standard.
