Zapier alternative for automating systems behind a firewall

Why a Zapier alternative for systems behind a firewall starts with the network

Consider a team whose customer databases, internal file shares and private APIs sit in a network that no outside party can reach. Zapier's hosted model needs endpoints it can call from the internet, so those systems either have to be exposed, proxied through a public gateway or left out of automation altogether. Self-hosted n8n or Windmill can run inside the same network, connect to internal systems directly and never require inbound access from Zapier's cloud. That network placement, not the feature list, is the first thing to decide.

Both options can meet that requirement, but the choice depends on two things you must check before you shortlist. The first is license terms. n8n's Sustainable Use License permits internal business use, yet files with .ee in their name need a valid n8n Enterprise License, and Windmill's prebuilt Community Edition images include proprietary code that is free for internal use only. Confirm with each vendor how these terms apply to your deployment and whether your use counts as internal. The second is team skill. n8n leans toward a visual canvas with code steps, while Windmill centers on scripts in several languages, so your engineers' habits should guide the pick.

Whichever platform you choose, the work starts with a network inventory. List each internal database, file share and API the workflows need, the protocol and port each uses, and which direction traffic must flow. Then confirm that the automation host can reach those targets from inside your network without any inbound rule from the internet. Ask your security team to review credential storage and the encryption key handling for the chosen tool before any workflow touches production data, since the planning choices made here shape every later step.

What the firewall constraint requires from an automation runtime

A hosted automation service only reaches systems that accept connections from the internet, so the firewall constraint shifts work onto whoever runs the runtime. The four requirements below describe what the runtime must do inside your network, and what you need to check before you commit to a platform.

No inbound ports for internal systems

A hosted service such as Zapier can only trigger on or call a system that is reachable from the internet, so internal databases and APIs often need inbound rules opened. A runtime placed inside the network avoids that exposure. Confirm which direction each connection runs, whether triggers use polling or webhooks, and whether any webhook endpoint must face the internet. Workato's on-prem agent is a useful comparison: it makes only outbound connections over a TLS WebSocket tunnel and needs no inbound firewall ports.

Direct reach to private databases

The runtime must open its own connections to databases, file shares and private APIs on your network. Check which drivers and protocols each platform supports, how it handles network segmentation, and whether service accounts can be limited to the specific tables, shares or endpoints a workflow needs. Test each connection from the runtime host itself, since a workflow that works from a laptop may fail from the server.

Credentials stored inside the network

Workflow credentials for internal systems must be encrypted at rest in a database you control, not held by a vendor. Confirm where the encryption key lives, who can read it, and how it is rotated. 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, which makes key distribution part of your design. Windmill Enterprise adds external secret backends such as Vault and AWS Secrets Manager.

An upgrade and patch path you own

A hosted service patches its own platform, but a self-hosted runtime is patched by your team on your schedule. Decide who watches release notes, how staging tests run before production, and how you roll back a failed upgrade. Windmill has shipped frequent releases, so the cadence matters. Ask each vendor for its support window and security advisory process, and confirm whether your license permits you to run the version you choose.

Where hosted Zapier meets this constraint and where it does not

Zapier runs only as a hosted service, so every system a Zap touches must be reachable from the internet. A database, file share or private API inside your network is outside that path unless you open inbound access to it, which is the exposure most security teams are trying to avoid. Before you plan a move, confirm with your Zapier account team which of your current Zaps depend on endpoints that are not publicly reachable, and whether any of them rely on IP allowlisting or inbound webhooks into internal services. Those dependencies, not the Zap count, define the scope of the firewall problem.

Zapier's JSON export of Zaps, available on Team and Enterprise plans according to its help center article on importing and exporting Zaps, is useful as an inventory of triggers, actions and field mappings. It is not a runtime. The file does not move execution, and after any import the Zaps must be turned on and app connections checked again. Account owners and super admins can export all Zap workflows across users, but delivery is by email, so treat that file as sensitive design documentation and store it under your own retention rules. Make's blueprints behave differently in one important way: a scenario export contains modules, settings and mapped values but excludes connections, so every credential must be recreated on any new runtime. Plan that credential inventory as a separate work item from the workflow rebuild, and record which service account each connection used so access on the new platform follows least privilege.

Self-hosting changes who owns reachability. A self-hosted runtime such as n8n or Windmill can sit inside your network and reach internal systems directly, so no inbound ports need to open toward it for those connections. Workato's on-prem agent uses a different model, making only outbound TLS WebSocket connections, which is a useful reference point when you compare architectures. Whichever platform you choose, confirm that outbound egress rules, the database service accounts and the secrets store are reviewed by your security team, because the runtime itself becomes the system that holds those credentials. Hosted Zapier also does not give you the choice of where the worker that calls your database runs, so that decision moves to your side of the boundary.

Which self-hosted options keep private systems behind the firewall

This table compares how n8n, Windmill and Node-RED run inside your network, their license fit and the trade-offs that matter for internal systems. Read each row against your own databases, file shares and private APIs, and treat Activepieces as a secondary option. The main takeaway is that all three can reach internal systems without inbound internet access, but licensing, SSO and enterprise features differ enough to decide the choice.

Criterion	n8n	Windmill	Node-RED
How it runs inside the network	Self-hosted on your servers or cloud accounts; queue mode adds workers that read and write PostgreSQL	Self-hosted with Docker Compose or Kubernetes Helm charts, with external PostgreSQL supported	Self-hosted Node.js runtime on servers or edge devices inside the network
License fit	Sustainable Use License: internal business use is permitted, but it is source-available, not OSI open source	AGPLv3 and Apache-2.0 for source built without the enterprise flag; prebuilt images include proprietary code free for internal use	Apache-2.0, an OpenJS Foundation project
Single sign-on	SAML SSO is gated to Business and Enterprise plans	SAML and SCIM are part of the paid Enterprise Edition	Depends on the editor and dashboard setup you add; confirm with your identity team
Pricing model to confirm	Community is free; Business is self-hosted only; Enterprise is custom	Enterprise starts at $120 per month, priced at $20 per developer and $10 per operator plus compute units	No vendor license fee; cost is staff time and hosting
Internal system reach	Strong fit for databases and HTTP APIs; confirm connector coverage for your specific internal systems	Scripts in Python, SQL, Bash, PowerShell and more reach internal targets; confirm drivers for your systems	Strong for devices, MQTT and HTTP; SaaS connectors are sparse, so custom nodes are common
Main trade-off	Paid tiers for SSO, Git environments and log streaming	Per-user Enterprise pricing for teams that need SAML, audit logs and external secrets	You own security hardening and access control for the editor
Activepieces (brief)	Not applicable	Not applicable	MIT-licensed core; ee directories fall under a separate commercial license

Choosing n8n or Windmill by team skills and license fit

n8n suits teams whose builders work mainly in a visual editor and add code only where a node falls short. Integration specialists, operations staff and application owners can wire triggers, branches and retries on a canvas, then drop into JavaScript or Python for transformations, custom parsing or calls to an internal API. Most of the work is assembling existing nodes, so the learning curve is shorter for people who previously built Zaps.

Node library: n8n advertises more than 1,500 integrations, and a visual canvas lets analysts follow a run without reading code.
Code steps: Custom JavaScript or Python covers gaps in the node catalog for internal database queries or file share logic.
Shared ownership: Business owners can review flows, while platform staff manage credentials and hosting.
Enterprise features: SSO and LDAP, Git-based environments and log streaming sit in the Business and Enterprise plans, so confirm whether you need them before you choose this path.
Queue mode: Scaling workers that read and write PostgreSQL requires sharing the main instance's encryption key with every worker, a decision your security team should approve.

Before committing, confirm which n8n edition and license key your organization will run, and whether your use fits the internal-business terms covered in this section.

n8n's main codebase is under the Sustainable Use License, which allows use or modification for your own internal business purposes or for non-commercial use. Running n8n inside your network for your own staff generally fits that grant, but it is source-available rather than OSI open source. Files with .ee in their name require an n8n Enterprise License, and the Community edition runs without a license key. Distribution is limited to free, non-commercial use, so you cannot offer n8n as a service to others under this license.

Internal use: Automating your own databases, file shares and private APIs for your own business sits within the stated internal purpose.
Enterprise files: Any .ee code in your build needs a valid Enterprise License, so check your image and repository contents.
Windmill Community: Source compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0, while prebuilt Community images include proprietary code free for internal use.
Managed or resold services: Windmill requires a commercial license for managed services or reselling, so an internal-only deployment is the case the Community terms cover.
Multi-tenant use: Providing automation to outside parties triggers commercial terms under either product.

Have counsel confirm that your internal deployment, including any contractor operation, matches the current LICENSE text and the Windmill terms before rollout.

How to deploy n8n or Windmill inside your network

This sequence takes you from an inventory of internal systems and Zapier exports to a self-hosted n8n or Windmill instance that reaches private systems, with credentials rebuilt, egress tested and an upgrade plan in place.

Inventory internal systems and Zapier exports
Start by listing every internal database, file share and private API that your Zaps touch, along with the owner and network path for each. Export your Zaps from Zapier as JSON if your plan allows it, since the file serves as a rebuilding inventory rather than something n8n or Windmill can import. Confirm with your Zapier account owner whether an admin export of all users' Zaps is available to you. The step is done when you have one list that maps each workflow to the systems it reads or writes and to the network zone those systems sit in.
Choose Docker Compose or Kubernetes Helm charts
Decide the deployment target based on the platform your platform team already runs. Both n8n and Windmill document Docker Compose for single-host installs, and Windmill also documents Kubernetes Helm charts. Confirm which method your change process and backup tooling support before building anything. The step is done when the target is written into your architecture record, with the host or cluster, the network segment it lives in and who operates it.
Attach an external PostgreSQL database
Where your policy requires managed or centrally governed databases, point the platform at an external PostgreSQL instance such as AWS RDS, GCP Cloud SQL or Azure, which Windmill's repository lists as supported. Ask your database team to create the database, role and backup schedule, and to confirm that the instance is reachable only from the platform's network segment. The step is done when the application starts against the external database and the database team confirms backups and access restrictions in writing.
Set up n8n queue mode with a shared encryption key
If n8n must handle heavy or parallel executions, run the main instance for triggers and webhooks and add worker processes that take executions through Redis and read and write workflow data in PostgreSQL. Every worker and webhook processor must hold the same encryption key as the main instance, because they need it to decrypt stored credentials. Store that key in your approved secret store and restrict who can read it. The step is done when a test workflow runs on a worker and a credential decrypts correctly on that worker.
Size Windmill workers as a starting point
For Windmill, begin with the README's rule of thumb of one worker per vCPU with 1 to 2 GB of RAM, then adjust after load testing with your own jobs. Scripts run sandboxed with nsjail, so confirm that your host or cluster allows that isolation model. Ask your platform team to record the chosen worker count and memory limits. The step is done when a representative job set has run through the workers without resource exhaustion and the sizing decision is documented.
Rebuild credentials and test network paths
Recreate each connection on the self-hosted instance rather than copying secrets from another tool, and use a service account with the least privileges each workflow needs. Then test egress from the workers to external SaaS endpoints and internal reachability to each private database, file share and API from the identified network zone, without opening any inbound port from the internet. The step is done when every workflow in the inventory has a passing test run, and the firewall change record lists only the outbound and internal rules you approved.
Plan upgrades against release notes
Subscribe your team to the n8n release notes and to Windmill's GitHub releases, and check each release for breaking changes before applying it to a staging copy of the instance. Keep a tested backup of the database and the encryption key before every upgrade. Confirm with your vendor or internal owner who approves upgrades and how long a rollback takes in your environment. The step is done when a staging upgrade has been completed and the production upgrade procedure, including rollback, is written down and owned by a named team.

What you own once the runtime sits behind your firewall

Running n8n or Windmill inside your network moves the operating work from the vendor to your team. Patching the application and its operating system, backing up the PostgreSQL database, rotating credentials, monitoring worker health and keeping access control current all become your responsibility. Zapier absorbs most of this today because it runs the service, so budget these tasks as recurring staff time or as a retained support contract, and ask any implementation partner to state in writing which of these tasks they run for you and which stay with your team.

High availability needs a specific decision. In n8n, multi-main setup, which runs several main instances for failover, is restricted to Enterprise self-hosted deployments and is not available in the Community edition or n8n Cloud. If a single main instance is an unacceptable failure point for internal workflows, confirm the license tier before design starts, and plan for the queue mode encryption key being shared with every worker and webhook processor. In queue mode, the main instance's encryption key must reach all of them, so treat that key as a tier-one secret and store it in a managed secret store.

Windmill's paid tier changes the access picture for internal-only policy. Windmill Enterprise adds SAML and SCIM for identity provisioning, audit logs, and external secret backends such as Vault and AWS Secrets Manager, according to its pricing page. If your policy requires centralized deprovisioning, a record of who ran which script, or secrets that never sit in the application database, these features may decide the tier. Confirm current feature availability and pricing directly with Windmill, since both change, and check whether your internal identity provider supports the protocols each product uses.

Evidence reviewers ask for when automation touches internal data

When an automation runner sits inside your network and reaches internal databases and file shares, reviewers want proof of what is exposed, what runs, and who can change it. The cards below cover the artifacts that answer those questions. DeployOpen prepares this evidence, but independent auditors and certification bodies are the ones who issue any attestation.

Network diagram with no inbound rules

Document the runner's position in the network, the outbound destinations it contacts, and the firewall rules that allow them. For a self-hosted n8n or Windmill deployment, the key claim is that no inbound rule admits traffic from the internet to the automation host, while internal sources reach it only where your policy allows. Ask your network team to confirm this against live firewall configuration, not only the design. Note any webhook endpoints that must be reachable and how they are restricted.

License file and edition in use

Record which n8n edition or Windmill build is running, along with the license terms that apply to it. n8n's main codebase falls under the Sustainable Use License, and files with .ee in their name need a valid Enterprise License, so keep a record of which files and keys are present. Windmill's prebuilt Community Edition images include proprietary code that is free for internal use. Reviewers will ask whether your use is internal, so document that decision with your legal team.

Workflow and credential inventory

Maintain a register of every workflow, the systems it reads or writes, the credential it uses, and a named owner for each. This is the artifact that turns a running automation into something a reviewer can assess. Include who last changed each workflow and when it was last reviewed. Credentials need the same treatment, with the scope each one holds and a rotation record. If you migrated from Zapier, the JSON export is a starting inventory, not a complete one.

Access and SSO configuration

Show how people sign in to the automation platform and what each role can do. SAML single sign-on in n8n is available on the Business and Enterprise plans, and Windmill's Enterprise Edition adds SAML and SCIM. Export the role assignments, the group mappings from your identity provider, and the list of accounts that have admin rights. Confirm that local accounts are limited and that the encryption key for stored credentials is held under restricted control.

PostgreSQL backup and restore records

Both n8n and Windmill keep their state in PostgreSQL, so that database is the core of your recovery plan. Keep dated backup logs, the retention period you set, and the location of stored copies. Most important, keep records of test restores that show the database came back and workflows ran afterward. A backup that has never been restored is not evidence of recovery. Managed services such as AWS RDS, GCP Cloud SQL or Azure can host this database, and their backup settings belong in the same record.

Upgrade change logs

Keep a dated log of every upgrade, with the version before and after, the reason for the change, the test results, and the approver. Windmill publishes frequent releases, so a monitored upgrade schedule matters. For n8n, log which release notes you reviewed and whether any breaking changes applied to your workflows. Retain the rollback plan for each change. Reviewers look for evidence that changes were planned, tested and authorized, not just applied.

Questions buyers ask before hiring help to automate systems behind a firewall

How much effort does rebuilding Zaps as workflows inside our network take?

The effort depends mostly on how many workflows you have, how many internal systems each one touches, and how many of those systems need a custom connector. Zapier's JSON export gives you an inventory of Zaps, but it is not a file another tool imports, so each workflow is rebuilt by hand in n8n or Windmill. Simple trigger-and-action flows move quickly. Flows that call private APIs, query an on-premises database or read from a file share need a credential design, a network path and a test plan before they are rebuilt. Ask the vendor or implementation partner to split the estimate by workflow type and by system, not by total count. Effort also rises when you need to replicate error handling, retries and alerting that Zapier handled for you.

Can our own team run this migration without outside help?

Yes, a capable internal team can do it, provided it has someone who can run n8n or Windmill, manage PostgreSQL, and write code for the steps that connectors do not cover. Windmill scripts can be written in Python, TypeScript, Go, Bash, SQL and several other languages, and n8n supports custom JavaScript or Python steps. The harder parts are usually not the workflow editor. They are secrets handling, network routing to internal systems, change control and ongoing patching. Outside help is most useful for the first deployment, for hardening, and for knowledge transfer. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with the scope agreed in writing before work starts.

What do we need from our network and security teams?

Your network and security teams need to approve where the automation platform runs, how it reaches each internal system, and how credentials are stored. The platform should sit inside your network so it can reach internal databases, file shares and private APIs without inbound ports from the internet. Workato's on-prem agent illustrates the pattern: it makes only outbound connections over a TLS WebSocket tunnel and needs no inbound firewall ports. Self-hosted n8n and Windmill do not require that exact design, so confirm the outbound and internal paths each workflow needs. Security teams will also want to review service accounts with least-privilege access, the encryption key handling for n8n credentials, logging, and who can edit production workflows.

How long will the work take?

Timing depends on the written scope: the number of workflows, the number of internal systems, the hosting platform, the approval steps inside your organization, and how much testing your change process requires. No duration is set until scope, deliverables and timelines are agreed in writing. Ask for a plan that separates the platform installation, the connector and network work, the workflow rebuild, parallel running and cutover. Parallel running matters because Zapier and the new platform may run the same logic for a period while you compare outputs.

Is n8n or Windmill cheaper to run ourselves, and what does each cost include?

Both have free self-hosted editions, so the license fee is not the main cost. For n8n, the free Community edition is available, and the Business plan at 667 euros per month billed annually is currently self-hosted only, according to n8n's pricing page. SSO, LDAP, Git environments and log streaming sit in the Business and Enterprise plans. For Windmill, the free self-hosted Community Edition has unlimited executions and is limited to 3 workspaces, 50 users and 4 groups, according to its pricing page as of October 2026. Its self-hosted Enterprise Edition starts at $120 per month, according to the same source. Your real costs are the servers, PostgreSQL, backups, monitoring, the migration project, and staff or partner time to maintain the platform. Windmill's README suggests one worker per vCPU with 1 to 2 GB of RAM as a sizing starting point. Ask for a total cost comparison that lists each component and its owner.

What changes if we need a commercial license?

Licensing changes depend on which features you need and how you use the software. n8n's Sustainable Use License allows use for your own internal business purposes, and files with .ee in their name require a valid n8n Enterprise License. Windmill's Community Edition images include proprietary code that is free for internal use, while managed services or reselling require a commercial license. If you need SSO, SCIM, audit logs, external secret backends or multi-main high availability, those features sit in paid tiers, so confirm them against the current pricing pages before you commit. Have legal review the license terms against how your organization will use the platform, including any plan to offer workflows to customers.

What should we ask for in a quote?

Ask for a written scope that lists each workflow, each internal system and its access method, the target platform and version, and the environment where it will run. The quote should separate one-time work from recurring work. One-time items include design, connector build, network configuration, testing, migration and documentation. Recurring items include patching, upgrades, backups, monitoring and support. Ask which deliverables you receive, how acceptance is decided, which assumptions the price depends on, and what changes would trigger a new quote. DeployOpen does not publish a price list, so a quote follows from the written scope.

How DeployOpen deploys automation inside your network

DeployOpen plans, implements, hardens, documents and supports self-hosted automation platforms inside your own cloud accounts, data centers or air-gapped networks. For systems behind a firewall, the work starts with a written scope that names each internal system the workflows must reach and how the runtime will reach it without inbound access.

How we scope

Inventory the internal databases, file shares and private APIs each workflow must reach
Record which Zaps, scenarios or flows are in use, using exports where your plan allows them
Agree in writing which runtime (n8n or Windmill) fits each workload and license edition
Define credential handling, encryption key custody and who approves each new connection

How we build

Deploy the chosen platform with Docker Compose or Kubernetes in your environment, with an external PostgreSQL database if you require one
Configure runners or workers inside the network so every connection is outbound only from your side
Rebuild priority workflows and test them against non-production copies of internal systems
Document network paths, ports, firewall rules and secrets locations as part of the deliverables

How we hand over

Deliver a written runbook covering install, upgrades, backups, restore steps and access reviews
Walk your operations and security staff through each workflow, its owner and its failure alerts
Provide a dependency register that lists every internal system, credential and scheduled job
Confirm acceptance against the agreed scope before the engagement closes

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer
Ask for the retainer terms and what is covered in a quote, since no price list is published
Security testing of the automation endpoints and their connections can be scoped separately