Why workflow automation in air-gapped networks needs a different plan
If you run n8n, Node-RED or Temporal in a network with no internet route, the platform itself can run fully on local infrastructure, but much of what makes these tools convenient does not. Most SaaS connectors, cloud-hosted credential stores and vendor-hosted license checks assume outbound access, so they fail silently or loudly once the gap is closed. Before installing anything, design three things: which integrations must work on the isolated side, where credentials and encryption keys live, and how software, community nodes and updates cross the boundary. The short answer is to choose platforms that run on local infrastructure only, then plan the transfer path as a controlled process rather than an afterthought. Confirm each connector against its vendor documentation, because a connector that works through a local API gateway or a self-hosted system is a different case from one that calls a cloud endpoint.
Edition and licensing decisions come first. Air-gapped support is often a paid-edition feature across the open-core market, so confirm in writing whether the features you need for an isolated deployment sit in a free tier. For n8n, the Community edition is free to self-host, but SSO and LDAP, environments with Git, and log streaming are listed as Business and Enterprise plan features, and multi-main high availability is restricted to Enterprise self-hosted deployments. Also confirm the license terms: n8n's Sustainable Use License permits use only for your own internal business purposes or non-commercial use, and files marked .ee need an Enterprise License. Node-RED is Apache-2.0 and Temporal's server is MIT-licensed, so their terms are simpler, but your legal team should still confirm the terms that apply to each component you deploy.
Plan the transfer path for updates, community nodes and queue-mode workers before the first flow is built. In n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor, so the key distribution method must work inside the enclave. Node-RED's editor is not secured by default, so HTTPS and authentication must be configured before any isolated deployment goes live. Ask your partner how each package is verified after it crosses the boundary, and which controls your sector expects, such as the software integrity checks described in NERC CIP-013-2 for utilities. Every item you carry across the gap is a supply chain decision, so record who approves it and how it is tested.
Which isolation requirements shape the build
This table maps common isolation requirements to what they mean for an air-gapped n8n, Node-RED or Temporal build. Read each row as a question to answer in design: what the requirement asks, and which build element must exist to satisfy it. The main takeaway is that most isolation requirements translate into a local package registry, a controlled transfer process with verification, and a documented access path for vendors.
| Requirement | What it means for the build | Evidence to prepare |
|---|---|---|
| No outbound internet from workflow workers | Workers, webhook processors and the database cannot reach public registries, so node packages, base images and connector updates must come from inside the boundary | Network diagrams showing egress blocked, plus a test showing workers fail closed on external calls |
| Controlled import of packages and community nodes | Build a local package mirror or private registry and an approved list of community nodes; confirm each node's license and maintenance status before import | Approved node inventory with versions, license review notes and the owner of each node |
| Software integrity and authenticity on every transferred item | Verify checksums or signatures of images, packages and workflow exports before they cross the boundary, and again on arrival; keep the verification step in the transfer procedure | Signed transfer log recording item, hash, approver, date and verification result |
| Encrypted, multi-factor vendor remote access | Route any vendor session through an intermediate system with encryption and MFA, and disable access between sessions; for n8n, the encryption key must be handled under the same rules | Access logs for each vendor session, MFA configuration records and a documented disable procedure |
| Utility cyber security perimeter duties (NERC CIP-005-7, where applicable) | If flows touch high or medium impact BES Cyber Systems, the automation sits inside the electronic security perimeter and vendor access must pass the intermediate system; confirm scope with compliance staff | Perimeter boundary diagram and remote access inventory mapped to the standard's requirements |
| Supply chain controls for vendor software and patches (NERC CIP-013-2, where applicable) | Procurement must cover verifying integrity and authenticity of vendor software and patches, which applies directly to every package carried across the gap | Vendor risk records and verification evidence for each release imported |
| Automatic event logging for high-risk AI (EU AI Act Articles 12 and 19) | Only when a flow feeds a high-risk AI system: logs must be recorded automatically and retained for at least six months unless other law sets a longer period; plan log storage inside the isolated network | Log retention configuration, retention period decision and a mapping of which flows feed the AI system |
| Offline restore and upgrade path | Keep backups and a reproducible install bundle inside the boundary so workflows and credentials can be restored without internet access | Restore test results and a versioned bundle manifest for each upgrade cycle |
Which automation platforms fit an isolated network and why
Three platforms cover most air-gapped automation needs, and each carries different licensing, deployment and security duties. The cards below compare them on the points that matter once no SaaS connector can reach the internet and every package crosses a controlled boundary.
n8n Community edition in queue mode
n8n's free self-hosted Community edition is the usual starting point for visual integrations. Queue mode splits the main instance from workers that run executions through Redis and read and write workflow data in PostgreSQL, so you must size Redis and PostgreSQL inside the enclosure. Every worker and webhook processor needs the main instance's encryption key to decrypt stored credentials, which makes key distribution a first-week design decision. Multi-main high availability is limited to Enterprise self-hosted, so confirm your uptime needs before promising it. Confirm the Sustainable Use License fits your internal use.
n8n paid features and licence limits
SSO and LDAP, environments with Git, and log streaming sit in the Business and Enterprise plans, and SAML single sign-on is documented for those tiers. Files with .ee in their name or directory require an n8n Enterprise License. The Sustainable Use License permits internal business use and non-commercial use, so an air-gapped team serving its own staff is usually within scope, while offering flows to customers is not. Ask the vendor for written confirmation before you depend on any paid feature for audit logging.
Node-RED on an isolated network
Node-RED is Apache-2.0 licensed, stores flows as JSON, and runs on Node.js 22.9.0 or later, with Node.js 24 recommended. Its flow library holds over 5,000 community nodes, and each one must be reviewed and copied across the gap as a versioned package before import, because the editor can install from the public registry if it is allowed to reach one. The editor is not secured by default, so enable HTTPS and authentication before any device on the plant or office segment can reach it. Confirm which Node.js and npm sources your mirror will serve.
Node-RED maintenance and editor access
Flows are JSON, so they can be exported, diffed and stored in version control inside the enclosure, which helps change review. The risk is that the editor allows anyone with access to deploy changes, so role separation, a named owner for each flow and a documented handover are needed. Node-RED 5.0 dropped support for Raspberry Pi 3B and older models, which matters for edge hardware bought before the upgrade. Confirm who approves edits and who holds the admin password.
Temporal for durable code-first workflows
Temporal suits long-running, code-first processes that must survive restarts and retries, such as multi-step approvals or reconciliations that wait days for a human. It is a different model from visual flow tools, so it needs developers who maintain workflow code and a supported cluster. Its licensing and offline deployment steps must be confirmed directly with the vendor before you name a version or commit to a build. Plan for its persistence store and the internal network paths its services need.
Verifying packages across the gap
Every n8n image, npm package, Node-RED node and Temporal artifact that crosses the boundary should be checked for integrity and recorded with its source and approver. NERC CIP-013-2 addresses verification of software integrity and authenticity for vendor software and patches, which is a useful reference even outside the electric sector. Build a repeatable transfer procedure, keep a manifest, and test the offline install before the first real import. Ask your partner how the transfer log will be kept.
Which integrations still work offline and which fail
Connectors that reach systems inside the isolated zone keep working, provided the flow host, the credentials and the network path all sit within that zone. Flows that query an on-premises PostgreSQL or Oracle database, publish to a local RabbitMQ or Kafka broker, read from a file share, bind to Active Directory or LDAP, or call an ERP or MES API on the same network need no internet access at runtime. The work is in confirming that each one resolves names internally, uses certificates the isolated trust store already trusts, and does not quietly call a vendor license or telemetry endpoint at startup. Confirm the TLS chain and the DNS path for every internal target during design, not during the first failed production run.
SaaS connectors, cloud webhooks, public package registries and vendor-hosted AI APIs fail or must be replaced. A Slack, Salesforce or Google Workspace node cannot authenticate to its vendor, and an inbound webhook from a cloud service has no route into the zone. Community nodes installed from public npm packages and workflow templates fetched from the internet fail the same way. Each one needs a decision: replace it with a local equivalent such as an internal mail relay or an on-premises LLM endpoint, move the trigger to a mirrored internal event source, or remove it from scope. Treat the replacement as a new integration with its own review, not a configuration change. Illustrative example: a flow pulls new claim records from an internal case system's REST API every five minutes, maps the fields, and inserts them into a local PostgreSQL reporting database. Every hop stays inside the zone, so the flow works offline. If the same flow also posted a summary to a hosted chat tool, that final node would be the one to replace or drop. Before design, inventory every connector in a spreadsheet with four columns: the source, the destination, the protocol and whether the destination is inside the zone. Any row marked outside the zone is a blocker to resolve before the build begins.
How the rollout moves packages and updates across the gap
The sequence turns a connected build zone into a controlled supply line, so every workflow, node, package and update that enters the isolated network is inventoried, verified and approved before it runs. Each phase ends with a named artifact that the next phase depends on.
Inventory integrations and map destinations
The team lists every workflow, trigger, external system and credential the automation needs, then maps where each one must reach inside the isolated network and which calls must stay within it. Platform owners, integration owners and the security team sign off on the list. The output is an integration inventory with a destination map, and a workflow marked as offline-capable or dependent on an external service is not carried forward until someone has decided how it will run.
Build the staging environment in a connected zone
Engineers reproduce the target platform version, database, queue and authentication setup in a staging environment inside a connected build zone that mirrors the isolated network's configuration as closely as practical. They test workflows against stand-in endpoints and record every external dependency they find, including community nodes, base images and libraries that pull from the internet at startup. The output is a staging build with a dependency list that matches the inventory, and any dependency that cannot be satisfied offline is flagged for a decision.
Create the private package mirror and node bundle
The team assembles a private registry or package mirror that holds the container images, operating system packages, language packages and any community or custom nodes the workflows use, pinned to the versions tested in staging. Each item is recorded with its version and checksum, and the bundle is packaged for transfer. The output is a versioned node bundle and mirror index that can be reproduced from the same inputs, which matters when a later audit asks what was running and where it came from.
Verify and approve each transfer
Before anything crosses the boundary, the security team checks the bundle's integrity and authenticity against the recorded checksums, scans it for known vulnerabilities and reviews the license terms of each component, including whether a fair-code or commercial license limits use in the isolated environment. Engineers confirm that no workflow file holds plaintext credentials. The output is a signed transfer manifest with an approval record naming who checked what, and a bundle without that record does not enter the network.
Install offline and build queue-mode workers
Operators install the platform on isolated hosts from the mirror with no outbound access, then configure the main instance, the database, the Redis queue and the worker pool. Where the platform runs in queue mode, the encryption key is distributed securely to every worker and webhook processor so they can read stored credentials, and the workers are tested for their ability to reach the database and queue without leaving the network. The output is a running isolated stack with a documented configuration and a health check result for each component.
Test cutover and the transfer runbook
The team rehearses the full transfer on a copy of the isolated environment, from importing the bundle through starting workflows, restarting workers and rolling back. Operators follow the written runbook without help from the engineers who wrote it, and they record any step that needed interpretation. Failed workflows are checked for alerting and error handling. The output is a tested runbook and a restore test that shows the environment can return to its previous state, and cutover does not proceed until both have passed.
Run the repeatable update cycle
For each new platform release, security patch or node update, the same sequence repeats: staging in the connected zone, a new bundle, verification and approval, then a scheduled transfer and rollout. Change records link each update to the approved manifest and to the workflows it affects. The output is a dated change log and an updated manifest for each cycle, and the team reviews whether the cycle matched the runbook so the process improves rather than drifts. Ask the implementation partner how long each cycle takes in your environment before committing to a schedule.
Deployment patterns for queue-mode workers on isolated infrastructure
Queue mode splits one n8n deployment into a main instance, webhook processors and workers that share Redis, PostgreSQL and an encryption key. On an isolated network, each of those components also depends on images, certificates, DNS and vendor access that must be provided from inside the boundary.
Main instance and webhook processors
The main instance handles triggers and webhooks, then passes executions through Redis to workers that read and write workflow data in PostgreSQL. Decide which hosts receive inbound webhook traffic from internal systems, and keep those processors separate from the hosts that run executions. Confirm with your vendor or partner whether your chosen n8n edition supports the high availability setup you need, because multi-main operation is limited to Enterprise self-hosted deployments. Plan the network paths between each component and the data stores before any flow is imported.
Worker pool, Redis and PostgreSQL
Workers pull executions from Redis and read and write workflow data in PostgreSQL, so both stores become the critical path for every run. Decide whether Redis and PostgreSQL are dedicated to automation or shared, how they are backed up inside the enclave, and how many workers each host can carry. Ask the partner how worker capacity is sized and monitored when no external cloud metrics service is reachable.
Shared encryption key custody and rotation
The main instance's encryption key must be available to every worker and webhook processor so they can decrypt credentials stored in the database. Decide who holds the key, where it is stored, and how it is delivered to new hosts without leaving the boundary. Rotation changes every component at once and affects stored credentials, so write the procedure and rehearse it in a non-production copy before the first real change window.
Private image registry and offline artifacts
Every container image, npm package and community node must be mirrored into an internal registry or repository before deployment. For Kubernetes, kubeadm can pull control plane images in advance with the config images list and pull commands, and kubeadm init accepts an image repository flag that points at a private registry. GitLab documents offline self-managed instances, which shows the same pattern applies to supporting tooling. Decide who approves each artifact and how signatures or checksums are verified before import.
Internal DNS and certificate authority
Workers, webhook processors and the editor reach each other by internal names, and encrypted connections need certificates that no public authority can issue inside an isolated network. Decide whether an internal certificate authority will issue and renew certificates for each service, who owns the root key, and how clients trust it. Document every hostname the platform uses, because a missing record stops queue traffic without an obvious error.
Vendor remote access through an intermediate system
Vendor support sessions must not open a direct path into the automation network. NERC CIP-005-7 is a useful reference for energy operators: it requires interactive remote access to high and medium impact systems to pass through an intermediate system with encryption and multi-factor authentication, and to detect and disable active vendor sessions. Even outside the energy sector, use the same pattern: a brokered, MFA-protected jump point that logs and can terminate each session. Confirm with your partner exactly who can open it and how sessions are recorded.
What auditors ask for from an offline automation estate
This table maps the evidence an assessor typically asks for to the component that produces it in an air-gapped n8n, Node-RED or Temporal estate. Read each row as a question to answer before the assessment starts, and confirm with your assessor which items they require, since the list varies by framework and by the regulator or customer asking.
| Evidence | What it shows | Where it is produced |
|---|---|---|
| Transfer manifest with hashes | Each package, image and workflow file that crossed the isolated boundary, with its checksum at export and at import | Transfer log and import staging area, kept outside the isolated network |
| Approval record per package and node | Who reviewed and approved each community node or update before it was carried across, and the software integrity check performed | Change ticket system and the signed-off transfer record, linked to the manifest |
| Workflow version history | Which workflow version was live at a given time, who changed it, and what was promoted from test to production | Git history of the workflow repository, or exported workflow JSON stored with each release |
| Execution logs and retention settings | Which workflows ran, when, with what outcome, and how long execution data is kept before deletion | n8n execution data in PostgreSQL, the configured pruning settings, and the logging stack receiving process logs |
| Credential inventory | Which credentials exist, which systems they reach, who owns them, and when they were last rotated | n8n credential store, with the encryption key custody record kept separately from the database |
| Access reviews for editors and admin consoles | Who can edit flows, manage users and reach the admin API, reviewed on a set schedule with removals recorded | Identity provider or local user directory, and n8n or Node-RED user lists exported at each review |
| Restore test results | That backups of execution data, workflow definitions and encryption keys can be restored into an isolated environment, with the date and result of each test | Backup job logs and signed restore test records held by the operations team |
| Logging for AI components (where applicable) | If an automation calls a model inside a high-risk AI system, records of events over its lifetime (EU AI Act Article 12) and retention of at least six months (Article 19); otherwise confirm this does not apply | The logging stack and model gateway, only where the use case falls in scope |
Questions to ask a partner before the isolated build starts
Start by asking how the partner moves software across the gap and proves what arrived. Ask for the exact transfer procedure for n8n images, Node-RED packages, Temporal components and every community node, including who builds the bundle, how the hash or signature of each artifact is recorded, and who checks it on the isolated side before anything is installed. Ask whether the partner keeps a dependency inventory for each transfer and how that inventory maps to the software integrity and authenticity expectations in NERC CIP-013-2 if the environment is in scope. Then ask how community nodes are reviewed before import, since n8n community nodes and Node-RED flows from the library both run code inside your network. Confirm which of these checks the partner performs and which your own security team must perform.
Next, ask where the n8n encryption key lives and who can read it. In queue mode, the main instance's key must be shared with every worker and webhook processor so they can decrypt stored credentials, so ask how the key is injected into each worker, how it is kept out of workflow exports and Git, and what the rotation procedure looks like across all workers without losing access to existing credentials. Ask how the Node-RED editor is secured, because it is open by default and anyone who can reach it can deploy changes. Request the specific settings the partner will apply for HTTPS, authentication through Passport, and basic authentication for HTTP nodes, and ask who approves changes to the admin API exposure.
Finally, ask which features require a paid edition and get the answer in writing. The n8n pricing page places SSO and LDAP, Git-based environments and log streaming in the Business and Enterprise plans, and multi-main high availability is limited to Enterprise self-hosted. Ask how offline updates are rehearsed in a staging enclave before they reach production, who keeps custom nodes working after handover, and what the partner will explicitly not do. A credible partner should decline to issue attestations or certifications of the isolated environment, since independent auditors perform those assessments. Ask for that exclusion in the statement of work so your compliance team plans its evidence correctly.
Common questions about air-gapped automation
Can n8n run fully offline in an air-gapped network?
Yes, a self-hosted n8n instance can run without internet access, but only the integrations that reach systems inside your network will work. n8n advertises more than 1,500 integrations, and many of them call SaaS APIs that cannot be reached from an isolated network. Before committing, list every integration each workflow uses and confirm with the vendor and your own environment whether the node needs outbound internet access, a license check or a remote update. Nodes that talk to on-premises databases, file shares, message queues and internal APIs are the ones that usually carry over. Community nodes and version updates must be brought across the gap by a controlled transfer process, which is covered in the next answer.
What does a partner's air-gapped automation work cover?
A partner's work covers the design, build, testing and documentation of the workflows and the platform around them inside your infrastructure. The main cost drivers are the number of integrations, how many workflows need offline validation, the transfer tooling used to move packages and images across the boundary, the edition you select, and the testing needed to show that flows behave correctly without outside connectivity. Edition choice matters because some air-gapped deployment and high availability features are restricted to paid tiers. Ask the partner for a written scope listing each integration, environment, transfer method and test case, since most engagements are fixed-scope and priced from that document.
What drives the cost of air-gapped workflow automation?
Cost depends on scope, not on a fixed package. The main components are one-time work (platform setup, integration build, transfer process design, testing and documentation) and recurring work (updates, patch transfers, workflow maintenance and support). Costs rise with the number of integrations, the number of isolated environments, the need for queue-mode workers, and compliance evidence requirements. Licensing is a separate line: the n8n pricing page lists SSO, environments with Git and log streaming as Business and Enterprise features, and Enterprise is priced on request. Ask any quote to separate platform licenses, infrastructure, partner labor and ongoing support so you can see which parts recur.
How long does air-gapped workflow automation take to deploy?
The timeline depends on scope and is agreed in writing before work starts. The main variables are the number of integrations to rebuild or validate offline, whether a clean isolated environment already exists, how long your approval and transfer processes take, and how many workflows need testing against live internal systems. No general duration applies, so treat any single number you hear as a claim to verify. Ask the partner for milestones tied to deliverables, and ask which dependencies sit with your team, such as firewall changes or package approvals, because those often set the pace more than the build itself.
What does the client need to provide for an air-gapped automation project?
The engagement needs access to the target environment, named system owners for each integration, and approvals for the transfer process. Typically you will provide:
- Access to the isolated network, build hosts and an internal container or package registry
- Owners for each source and target system, with credentials issued through your own vault
- A documented approval path for moving packages, workflow exports and encryption-related material across the boundary
- Test accounts and a staging copy of internal systems where possible
Confirm these items with your security and change teams early, because approval cycles often determine the schedule. Confirm with the partner how credentials and encryption keys will be handled in queue mode, since workers need access to the same key as the main instance.
Can our team run air-gapped n8n or Node-RED after handover?
Yes, if the handover is planned for it. Your team can operate the platform after handover when it has documented runbooks, tested transfer procedures, named owners and staff trained on workflow changes. Plan for the skills to be present in-house: container and Kubernetes operations where used, database administration, identity integration and workflow development. Ask the partner which artifacts they will hand over, such as architecture records, runbooks, workflow inventories and test results. Support and upgrades can be retained separately, which is useful if your team does not want to own every update cycle inside an isolated network.
How do we keep community nodes and updates current across an air gap?
Updates and community nodes cross the gap through a controlled, verified transfer process rather than direct downloads. Each package, image and node is staged outside the boundary, checked for integrity and authenticity, approved, and then imported on the isolated side. Verification matters because NERC CIP-013-2 requires supply chain processes to address verifying the integrity and authenticity of vendor software and patches, which is a useful benchmark even outside the energy sector. Confirm with your partner how they track versions, handle n8n release notes, and whether Node-RED community nodes are reviewed before import, since Node-RED's flow library holds over 5,000 community contributions.
Does n8n's license allow air-gapped use inside our organization?
Internal use is generally within the scope of n8n's Sustainable Use License, which permits use or modification for your own internal business purposes. Files marked .ee are not covered and need an n8n Enterprise License, so your partner should confirm which features they will touch. Distributing the platform to others or offering it as a service is restricted, which matters if the automation becomes part of a product. Have your legal team review the license text directly in the n8n LICENSE.md file before finalizing scope, and confirm the edition needed for SSO, environments and queue-mode high availability.
How DeployOpen scopes and supports isolated automation
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For isolated automation, that means the work covers the n8n, Node-RED or Temporal runtime, its database and queue, the internal package mirror or update path, the custom nodes and flows, and the runbooks that keep them running after handover. The work happens in your cloud accounts, data centers or isolated enclaves, so credentials, encryption keys and execution data never need to leave the boundary to be managed. Engagements are fixed-scope. Before work starts, the scope, deliverables, acceptance criteria and timeline are agreed in writing, and that document is the basis for the quote. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope to name each integration that must work offline, each import path that crosses the gap, the environments to be built, and who signs off on each deliverable. Ongoing support, upgrades and continuous testing are offered as a retainer, which is a separate written agreement covering the recurring work after go-live, such as applying updates carried across the boundary and reviewing custom nodes.
DeployOpen prepares systems, controls and evidence for compliance assessments, such as the record of how each package was verified before it crossed the boundary, access reviews for editors and credentials, and change logs for flow edits. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so confirm early which evidence your assessor expects and agree in the scope which artifacts DeployOpen will produce. Ask your partner to show how each artifact is generated and retained inside your environment.
