Self-hosted Make alternative for on-premises networks

Why a Make alternative for on-premises networks starts with the network, not the features

Teams that need scenarios to reach on-prem systems, or to run in a restricted or air-gapped network, should start by mapping their network, not by comparing feature lists. Make has no self-hosted edition and runs on AWS, so the realistic short answer for these requirements is self-hosted n8n or Activepieces. The harder question is which of them fits the network design you already have, and whether your operations team can run it there. The network constraint sets the requirements before any tool is chosen. Ask where each source and target system sits, which segments may accept inbound connections, whether workers can reach the public internet to pull packages or images, and who approves anything that crosses the boundary. Regulated operators with industrial or energy systems often also face supply chain rules. NERC CIP-013-2, for example, requires procurement processes that address verification of software integrity and authenticity, which applies directly to every package and container image you carry across an isolated boundary.

Fit depends on design choices such as whether the runtime sits in the same zone as the target systems, whether it needs a relay or agent for outbound-only connectivity, and how credentials are stored and shared between main and worker nodes. Confirm with each vendor how their queue or worker model handles encryption keys and high availability in your topology, and confirm which features your edition includes. Those answers decide the architecture long before a scenario is rebuilt. This page covers the requirements, the open-source options and their licensing, the deployment and offline installation steps, and the evidence an auditor or assessor will ask for. Read it in that order: first decide what the network allows, then choose the platform, then plan the operations work that follows.

What an on-premises or air-gapped network requires from automation

Once a scenario has to reach systems inside a restricted network, the automation runtime becomes part of that network's security boundary. The cards below set out the requirements that apply before any Make scenario is rebuilt in a self-hosted tool, and each one is a question to settle with the network and compliance owners.

No inbound path from the cloud

A cloud-hosted automation service needs a route into the network to reach internal systems, which many restricted zones do not allow. The usual pattern is a runtime placed inside the network that initiates every connection itself. Confirm with the network team whether any inbound rule, public endpoint or reverse proxy is acceptable, and treat a webhook that must be reached from outside as a separate, reviewed exception.

Outbound-only or brokered connections

Workato's on-prem agent is a useful reference point: it sits inside the customer network and makes only outbound connections to the cloud service over a TLS WebSocket tunnel, with no inbound firewall ports. A self-hosted n8n or Activepieces instance can follow the same principle by running its workers inside the boundary. Ask the platform team to document every destination the runtime must reach and to block everything else.

Credential and encryption key handling

Scenarios depend on stored credentials, and Make does not export connections, so each one must be recreated in the new runtime. In n8n queue mode 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, how it is rotated and how a lost key is recovered from backup.

Integrity of packages carried across the boundary

Anything moved into an isolated network, including container images, node packages, connector code and update media, needs a verified origin before it runs. NERC CIP-013-2 addresses supply chain risk management for vendor software and patches in the electric sector. Outside that scope, the same idea applies: record checksums, keep a signed inventory of what was imported and review every community-contributed integration before it is enabled.

Remote access to the automation runtime

Vendor and administrator access to the automation platform is a path into the same network it serves. NERC CIP-005-7 covers interactive remote access to high and medium impact BES Cyber Systems through an intermediate system with encryption, multi-factor authentication and the ability to disable active vendor sessions. If your environment falls under that standard or a similar one, confirm the required controls with your compliance owner before any support session is opened.

Edition and feature gaps for restricted use

Several vendors place air-gapped deployment and some access controls behind paid editions, so a free install may not meet the whole requirement. For n8n, the Business and Enterprise plans include SSO and LDAP, and multi-main high availability is limited to Enterprise self-hosted deployments. Activepieces lists SSO from its Team plan and audit logs and SCIM only on Ultimate. Confirm each required control against the current edition before the design is approved.

Where Make meets the constraint and where it does not

Make lets you export a scenario as a blueprint .json file. According to the Make help center article on blueprints, the file contains the scenario's modules, module settings and mapped values, so the logic can be read, reviewed and planned outside the Make interface. Connections are not included. They must be recreated after import, so account authorizations stay with the original systems and are set up again in the target runtime. For an on-premises team, the blueprint works as an inventory for the rebuild and does not carry credentials with it.

Scenario logic: Modules, settings and mapped values are in the file, so field mappings can be reviewed one by one.
Connections excluded: Each app authorization has to be set up again by hand in the new platform.
Target mapping: Each module needs a matching node or piece in n8n or Activepieces, and the team confirms that mapped values still resolve.
Scope of each file: One blueprint covers one scenario, so every scenario that touches an internal system needs its own export.
Secret handling: Credentials move into your own vault or the new platform's credential store during the rebuild.

Before the first test run, check which connection types each exported scenario uses and list every secret that must be entered again.

Which self-hosted platforms fit an on-premises scenario

This table compares n8n, Activepieces, Node-RED and Windmill against the constraints that push Make scenarios on-premises: licensing, reach into private networks and the edition needed for SSO and governance. Read each row against your own licensing rules and the systems your scenarios must reach, because connector coverage varies by platform.

Option	Licensing	How it meets the constraint	Trade-offs
n8n	Sustainable Use License, source-available and not OSI open source; .ee files need an Enterprise key	Community edition runs self-hosted in your network with Docker Compose; queue mode uses Redis and PostgreSQL for workers inside your boundary	SSO, Git environments and log streaming need Business or Enterprise; multi-main high availability is Enterprise only; confirm internal-use terms with counsel
Activepieces	MIT (Expat) Community edition; packages/ee and parts of the server API under a commercial license	Community edition is the self-hosted automation core and runs with PostgreSQL and Redis; Docker Compose and Helm options exist	280+ pieces, about 60 percent community-contributed; SSO starts at Team; audit logs, SCIM and external secret managers are Ultimate only
Node-RED	Apache-2.0, OpenJS Foundation project	Flow-based tool that runs on a local host with no cloud dependency, suited to event-driven edge or plant-floor data	Built for event flows rather than SaaS connectors; governance, RBAC and audit features depend on your own additions
Windmill	AGPLv3 and Apache-2.0 for source built without the enterprise feature flag	Self-hosts with Docker Compose or Kubernetes, with external PostgreSQL support for databases in your network	Prebuilt Community images include proprietary code free for internal use only; managed services or resale need a commercial license
Air-gapped image and package handling	Depends on each platform's license and build	Pull container images and packages in advance and verify them before they cross the isolated boundary, the software integrity concern in NERC CIP-013-2	Each connector and dependency must be checked for offline use; confirm the offline install path for your chosen platform

Which licence terms change the decision for an internal network

For an internal network, the licence question is mostly about who uses the software and what you do with it. n8n is licensed under the Sustainable Use License, which allows use and modification for your own internal business purposes and for non-commercial or personal use. A company that runs n8n inside its own network to reach on-premises systems is generally within that grant. The same license restricts distribution, and it permits distribution only free of charge for non-commercial purposes, so copying the runtime into products or handing it to other organizations is outside the grant. Files with .ee in their name or directory are not covered and require a valid n8n Enterprise License, so check which features your rebuild depends on before you assume the free code path covers them.

Activepieces takes a different split. Its community edition is MIT licensed, but the content under packages/ee/ and packages/server/api/src/app/ee sits under a separate commercial license. Features such as SSO, audit logs, Git sync or SCIM may depend on those directories, so confirm which of your required controls are in the MIT core and which need a paid tier. Node-RED (Apache-2.0) and Windmill (AGPLv3 and Apache-2.0 when compiled without the enterprise feature flag, with prebuilt images under a free internal-use license) add their own conditions, and Windmill's prebuilt images in particular need a separate read.

A managed service, a hosted offering for other business units or subsidiaries, or reselling automation as part of a product changes the answer for every platform above. Those uses can fall outside an internal-use grant even when the same software is fine on your own servers. Ask legal to review each license against the exact deployment model, including whether contractors or an implementation partner will operate the instance on your behalf. Keep the license text, the edition you deploy and the date of your review in the change record so the decision can be re-checked at each upgrade.

How to deploy n8n or Activepieces inside a restricted network

This sequence takes a team from choosing an edition to a self-hosted automation runtime that reaches on-premises systems, with each step producing a check the operations team can sign off on before the next one begins.

Confirm edition and licence before building
The platform owner, with legal or procurement, decides which edition the runtime will use before any image is pulled. For n8n, the main codebase is under the Sustainable Use License, which covers internal business use, and any files with .ee in their name require a valid n8n Enterprise License. Without a license key, n8n runs as the free Community edition, and SSO, Git environments and log streaming are listed as Business and Enterprise features. For Activepieces, the community edition is MIT licensed, while packages under packages/ee are commercially licensed. Done means a written edition decision that names the features the scenarios depend on, such as SSO, audit logs or multi-main high availability, and that the owner has checked the license terms in the vendor's own files.
Mirror images and manifests into a private registry
The platform team, working with the network security group, moves every artifact across the isolated boundary and records what was carried. This includes the n8n or Activepieces container images, the Docker Compose files or Helm chart, and the images for PostgreSQL and Redis. Where the cluster itself is offline, the Kubernetes kubeadm documentation shows the pattern: kubeadm config images list and kubeadm config images pull fetch control plane images in advance, and --image-repository points kubeadm init at a private registry. Confirm the exact image tags, verify checksums, and scan each image before it crosses the boundary. Done means a private registry that holds every image the deployment references, with a manifest listing versions and digests. Ask the vendor which tags to pin for your edition.
Deploy PostgreSQL and Redis on internal infrastructure
The database administrator and platform engineer deploy the data layer inside the restricted network, using the database service your organization already operates or a managed PostgreSQL instance inside your own cloud account. n8n queue mode stores workflow data in PostgreSQL and uses Redis to pass executions to workers. Activepieces recommends PostgreSQL and Redis in its Docker Compose setup. Configure backups, network rules that allow only the automation hosts to connect, and credentials stored in your secrets manager. Done means that both services accept connections from the application tier, that a restore test has succeeded, and that no database port is reachable from outside the enclave.
Configure queue mode and the shared encryption key
The platform engineer sets up the main instance, one or more workers and, where webhooks are needed, webhook processors. In n8n queue mode, the main instance handles triggers and webhooks, passes executions through Redis to workers, and reads and writes data in PostgreSQL. The main instance's encryption key must be shared with every worker and webhook processor so they can decrypt credentials stored in the database. Store that key in your secrets manager, restrict who can read it, and document the rotation procedure before go-live. Multi-main high availability is limited to Enterprise self-hosted deployments, so plan single-main recovery if you run Community. Done means that a test execution runs on a worker, and that a credential saved on the main instance decrypts on the worker.
Set up SSO on the right tier
The identity team connects the automation platform to the corporate directory only after confirming which tier includes SSO. For n8n, SAML single sign-on is available on the Business and Enterprise plans, with setup guides for Okta Workforce Identity and Azure AD. For Activepieces, the pricing page lists SSO from the Team plan, while SCIM and audit logs are listed only for Ultimate. Confirm the identity provider, group mapping and session policy with the vendor before you configure them, and keep a break-glass local administrator account stored offline. Done means that a test user signs in through the identity provider, that a user removed from the directory loses access, and that the admin account procedure is recorded.
Rebuild scenarios from blueprint exports
The automation engineer exports each Make scenario as a blueprint .json file. Make's documentation states that the file holds modules, module settings and mapped values, but connections are not included and must be recreated after import. Use the blueprint to plan the rebuild, then create the equivalent workflows in n8n or Activepieces. Recreate each connection with a service account owned by the team, not a personal account, and record which secrets each one requires. Test every workflow with sample data before enabling it. Done means a rebuild register listing each source scenario, its target workflow, the connections recreated, and the test result for each.
Test reach to on-premises systems
The network engineer and the owners of each internal system test every path the automations depend on. Confirm that the runtime reaches each on-premises API, database and file share through the approved firewall rules, and that it does not require inbound connections from the internet. If you use an outbound-only connector model, such as the one Workato describes for its on-prem agent, apply the same principle to any relay you build. Test failure paths too: a timed-out call, a rejected credential and a host that is down. Done means documented firewall rules, passing test executions on each path, and alert routing that reaches the operations team when a workflow fails.
Cut over and hand over operations
The operations lead runs the cutover in agreed order, disabling each Make scenario only after its replacement has passed tests and a parallel run. Confirm that every scheduled trigger and webhook points to the new runtime, and keep the Make scenario in a paused state for a rollback window set in the cutover plan. Hand over patching, backup restores, key rotation, image updates and log review to named owners, with a runbook for each. Done means that all production workflows run on the self-hosted runtime, that the rollback path has been tested, and that the operations team has signed the runbook.

What the operations team takes on after cutover

Once scenarios run on self-hosted n8n or Activepieces, the platform team owns the runtime and the security or compliance team owns how software enters the isolated boundary. Every image or package update has to be pulled outside the enclave, checked for integrity and authenticity, then carried across by approved media. This is the practical side of the supply chain control in NERC CIP-013-2, and the platform team should write the verification steps down before the first update. Confirm with the vendor how each release is distributed (container images, npm packages or source) so the verification method matches what actually crosses the boundary. Track vendor releases through the n8n release notes or the Activepieces GitHub releases page, and assign one named engineer to read them and open a change request for each relevant one.

The PostgreSQL database and the encryption key are the two items that make a backup restorable. In queue mode, the main instance's encryption key must be shared with every worker and webhook processor, so the key has to be stored in a vault the platform team controls, with a documented rotation procedure. Back up the database and the key separately, test a full restore into a staging network at least on a set schedule, and confirm that the restore procedure works without internet access. Secrets stored in the database are unreadable without the key, so a lost key means recreating every connection by hand. Ask the team that owns secrets management to hold the key custody record.

High availability is a limit to plan around, not a default. Multi-main setup is restricted to Enterprise self-hosted deployments of n8n, so a Community install runs a single main instance and worker failure, database failure and main instance failure each need their own recovery plan. Activepieces HA options depend on the edition, so confirm them against its pricing page before committing to a design. Monitoring and log handling also belong to the platform team: collect execution failures, queue backlog and worker health into the existing on-premises monitoring stack, and set retention to match the security team's log policy. Credential rotation is shared: the integration owner rotates each external system credential, while the platform team rotates the encryption key and database passwords on a schedule written into the runbook.

What auditors and regulators ask to see for this setup

A rebuilt Make scenario runs inside a network boundary that someone must describe, justify and keep current. The items below are the records assessors usually request when an automation runtime touches on-premises or restricted systems. DeployOpen prepares this evidence, but auditors and certification bodies draw the conclusions.

Network boundary diagrams

Current diagrams show where the n8n or Activepieces runtime, its database, Redis and workers sit, and which systems each one reaches. For Workato-style on-prem agents, assessors look for outbound-only connections and the ports used. Confirm that the diagram matches firewall rules and that every path into the restricted zone is listed and approved. Update the diagram whenever a scenario adds a new target system.

Licence records for each edition

Keep a record of which n8n or Activepieces edition runs in each environment, the licence key or lack of one, and the license file that governs it. n8n's Sustainable Use License limits use to internal business purposes or non-commercial use, and .ee files need an Enterprise licence. Activepieces enterprise code under packages/ee has its own commercial license. Record who approved each edition and when it was reviewed.

Software and image verification records

Each package or container image carried across the isolated boundary needs a record of its source, version, checksum or signature, and the person who verified it. This is the evidence behind supply chain controls such as NERC CIP-013-2, which asks how vendor software and patches are checked for integrity and authenticity. Keep the transfer log with the media used and the date each item crossed the boundary.

Access control and SSO configuration

Assessors ask who can build, edit, run and export scenarios, and how those roles are granted. Document the identity provider integration, the SAML or LDAP settings, and which features depend on a paid tier. In n8n, SSO and LDAP are listed only for Business and Enterprise plans, so the chosen edition directly affects this evidence. Export the role assignments and review them on a set schedule.

Change and backup records

Keep versioned exports of every workflow, the change tickets that approved each edit, and backup logs for the database that holds workflow data and encrypted credentials. Restore tests show whether a backup is usable, not just present. Record the n8n encryption key custody process, because workers need that key to read stored credentials, and show how it is protected and rotated.

Rebuilt scenario inventory and connection logs

Build an inventory that maps each original Make scenario to its rebuilt workflow, its owner, its target systems and its data classification. Because Make blueprints exclude connections, each recreated connection needs a log entry showing who created it, which credential it uses and when it was tested. This inventory also shows which Make scenarios were retired and when their connections were removed.

Questions buyers ask before choosing an on-premises Make alternative

Can Make scenarios be rebuilt for an air-gapped network with n8n or Activepieces?

Yes, both n8n and Activepieces can be installed self-hosted with Docker Compose, so the runtime can sit inside a network that has no internet route. Activepieces recommends Docker Compose with PostgreSQL and Redis and also offers a Helm chart for Kubernetes. n8n documents Docker Compose and major cloud installs. The harder question is the surrounding setup: container images, npm packages and any third-party app APIs must reach the isolated network through an approved transfer path. Confirm with the vendor which connectors need outbound internet access, since many of the integrations you rely on may call SaaS endpoints that the network cannot reach. Scenarios that only touch internal systems are the easiest to move first.

Which edition do we need for SSO and high availability?

In n8n, SAML single sign-on and multi-main high availability are not part of the free Community edition. n8n's pricing page places SSO and LDAP in the Business and Enterprise plans, and its queue mode documentation restricts multi-main setups to Enterprise self-hosted deployments. Activepieces lists SSO starting at its Team plan, while audit logs, SCIM and external secret managers are listed only for Ultimate, which can run on premises. Because these tiers change, confirm the current edition terms in writing before you design the architecture. Ask the vendor which features apply to a self-hosted air-gapped install specifically.

How are Make blueprints used, and what must be recreated?

A Make blueprint is a .json export of a scenario's modules, module settings and mapped values, so it is the starting point for planning the rebuild. It does not carry connections, which must be recreated after import in the target tool, along with their credentials. Zapier's equivalent export follows similar rules, and its help center notes that imported workflows must be turned on and their app connections checked. Plan to recreate every connection by hand, record which account each one used, and rotate credentials that were previously stored in a cloud service. Treat blueprints as design input, not as a file you can simply load into n8n or Activepieces.

What drives the effort, and what does the work need from our team?

Effort is driven mainly by the number of scenarios, how many use routers, iterators and aggregators, how many distinct app connections they hold, and whether any app lacks a native piece or node. Each missing integration may need a custom connector, which adds build and test time. Your team needs to supply network access rules, a PostgreSQL and Redis or equivalent platform, key management for encryption keys, the owners of each business process and staff to test scenarios against real data. Ask the implementation partner to split the work into inventory, rebuild, testing, cutover and operations handover so each cost component is visible.

Can our own team migrate the scenarios without outside help?

A capable platform team can run a small migration alone, especially if the scenarios are simple and use common apps. The work gets harder with many credentials, custom code steps, scheduled jobs that must not run twice during cutover, and air-gapped package transfers that need security review. For regulated networks, the evidence trail matters as much as the build: you need a record of what was imported, which packages crossed the boundary, and who approved them. NERC CIP-013-2 is an example of a supply chain control that asks for verification of software integrity and authenticity, so plan checksums and review steps even if you do the rebuild internally. An outside partner can help with the parts your team has less time or experience for.

What should we ask for in a written scope before starting?

Ask for a written scope that names the scenarios in scope, the target platform and edition, the hosting model (air-gapped, segmented or connected), the list of connectors to build or verify, and the testing and cutover method. Request the deliverables in writing: the scenario inventory, the rebuilt workflows, the credential and connection register, the transfer and verification record for every package, the backup and upgrade procedure, and the operations handover. Ask who maintains the platform after go-live and whether ongoing support is a separate retainer. DeployOpen works from fixed-scope written agreements, so ask for the scope, deliverables and timeline in writing before any work starts, and ask for a quote that follows from that scope.

Does moving to a self-hosted platform keep our data inside our network?

Self-hosting moves processing and storage into infrastructure you control, which is the main reason regulated teams consider it. The data still passes through whatever systems each workflow calls, so the boundary you actually get depends on the connectors and the network paths you allow. Confirm where each connector sends data, where execution logs and encryption keys are stored, and whether the platform's telemetry or update checks are disabled in an isolated network. Ask your compliance lead which control framework applies, since FedRAMP and CMMC scope rules differ and this page does not assess either.

How DeployOpen scopes a restricted-network automation migration

DeployOpen plans, implements, hardens, documents and supports self-hosted automation platforms inside your own network, whether that is your cloud account, a data center or an air-gapped segment. For a Make migration, the work usually covers the runtime itself (n8n or Activepieces), the connection path to on-premises systems, the database and encryption key handling, backups, access controls and the evidence your compliance team will ask for. Most engagements are fixed-scope, so the agreed deliverables, the scenarios in scope and the environments being built are written down before work starts. The first step is an inventory of which scenarios touch restricted systems, which connections need to be recreated and which ones can move to a cloud-free runtime without changes to the network boundary.

The scope decisions that shape cost sit with your team and ours together. Ask whether the target is the Community edition or a licensed edition, since several controls you may need, such as SSO, Git-based environments or log streaming, appear only in paid tiers on the vendors' pricing pages. Ask who will run queue workers and whether high availability is required, because multi-main setups are limited to certain editions. Ask how packages and container images will cross an isolated boundary and how their integrity will be verified. Each of these choices changes the work, so the written scope should name them explicitly.

DeployOpen does not publish a price list. A quote follows from the written scope, and the main cost drivers are the number of scenarios to rebuild, the number of restricted environments, the controls you need evidenced and the level of ongoing support you want. Migration work is typically one-time, while upgrades, monitoring, patch handling and continuous testing recur and are available as a retainer. When you request a quote, ask for the deliverables separated by phase, the assumptions about your environment, what your internal team must provide and the support terms that follow handover.

How DeployOpen deploys automation under a network constraint

DeployOpen plans, implements and supports self-hosted open-source platforms inside the client's own infrastructure, including networks the cloud cannot reach. For on-premises Make alternatives, we start by mapping which scenarios touch internal systems and how the runtime will reach them.

How we scope

Inventory every Make scenario, its triggers, modules and the internal systems it reaches
Record which scenarios need on-premises or air-gapped execution and which can stay in a cloud zone
Agree the target platform, edition and deliverables in writing before any work starts

How we build

Install the chosen runtime in your network with Docker Compose or Kubernetes, using your own PostgreSQL and Redis
Rebuild scenarios as workflows, recreate connections with vaulted credentials and test each path end to end
Check every container image and package carried across the isolation boundary against a verified source list

How we hand over

Document architecture, network paths, encryption key handling, backup and restore procedures
Provide runbooks for upgrades, scaling workers and rotating credentials, with a record of licensing terms
Walk the operations team through monitoring, alerting and access controls before handover

How we support

Offer ongoing support, upgrades and testing as a retainer after handover
Keep an upgrade plan for each release so offline media and images stay current
Prepare control evidence for compliance assessments, while independent auditors issue any formal opinion