Why on-premises data pushes teams off Power Automate cloud flows
If your flows read from on-premises databases or file shares, they depend on the on-premises data gateway, yet the flow itself runs in Microsoft's cloud. Every query and file touched by that flow crosses a path that you have to justify to your security and compliance teams, and the cloud execution layer is the part you cannot inspect. The short answer is that self-hosted n8n can run inside your own network, so the data path never leaves it. A workflow engine that executes next to the systems it touches removes the gateway hop to a vendor-hosted runtime, and the credentials, execution data and logs stay under your administrative control.
This does not come for free. The main trade-off is Microsoft 365 connector coverage. Power Automate has deep, first-party connectors for SharePoint, Outlook, Teams, Dataverse and Entra ID, and those are the connectors most organizations rely on for approvals and document flows. n8n covers a wide range of third-party systems and advertises more than 1,500 integrations, but you should not assume every Microsoft 365 action you use has an equivalent node. Build a list of the connectors your flows actually call, then check each one against the current n8n integration catalog before you commit.
Also confirm which flows need the gateway at all, because some on-premises reads may be better served by an API or a message queue exposed by the source system. Plan to test the Microsoft 365 steps in a parallel environment, and record which ones you will keep in Microsoft 365 and which will move. Your data protection and network teams should sign off on where the n8n workers and PostgreSQL database run before any production data moves.
What an on-premises data constraint requires from the workflow runtime
If flows must reach databases and file shares that never leave your network, the runtime itself has to run inside that network. Each requirement below narrows the options, and each one has a specific check you can run before committing to n8n or any other self-hosted platform.
Execution inside the network
The workflow engine, its queue and its workers must run on servers you control, so that data pulled from an internal database is processed where it sits. Confirm that every step that touches on-premises data, including code nodes and file operations, executes on hosts inside your boundary. Ask the vendor whether any telemetry or license check requires an outbound call from the runtime, and test that the flows still run with that path blocked.
Outbound-only connectivity
Workato's on-prem agent is a useful reference: it sits inside the customer network, opens only outbound connections over a TLS WebSocket tunnel and needs no inbound firewall ports. Self-hosted n8n does not work this way by default, so you must decide where the inbound webhooks and the database connections will terminate. Map each required flow direction with your network team before you approve any inbound rule.
Credential storage behind an encryption key
Connection credentials for databases and file servers are stored in the platform's database, and n8n's queue mode requires the main instance's encryption key to be shared with every worker and webhook processor so they can read those credentials. Treat that key as a secret with its own storage, rotation procedure and access list. Losing it or exposing it affects every stored connection, so document where it lives and who can read it.
A license edition your use allows
n8n's main codebase is under the Sustainable Use License, which permits use only for your own internal business purposes or for non-commercial or personal use. Files with .ee in their name or directory need a valid Enterprise License, and multi-main high availability is restricted to Enterprise self-hosted deployments. Confirm with counsel which edition covers your internal flows, and whether your Business or Enterprise license key is required for SSO or Git environments.
Software integrity for every package carried in
In an isolated network, every container image, node package and connector update is carried across the boundary by hand. The control behind this is supply chain verification of vendor software and patches. Build an internal registry, pull and hash each release, and record which version each environment runs, so that you can show what entered the network and when.
Which open-source options keep flows inside your network
This table compares n8n, Activepieces, Node-RED and Windmill against the requirement that flow data stays inside your network. Read each row against your own licensing position, edition choice and Microsoft 365 connector needs, because no option here replaces Power Automate desktop RPA. The main takeaway is that every candidate can run on your infrastructure, but each one needs a checked license, a confirmed connector list and a separate plan for desktop automation.
| Option | License terms to check | Self-hosting method and on-premises fit | Gaps for this use case |
|---|---|---|---|
| n8n Community edition | Sustainable Use License; internal business use permitted, but distribution is limited to free non-commercial use | Runs without a license key; documented installs include Docker Compose and major cloud providers, so it can sit inside your network | No SSO/LDAP, Git environments or log streaming; multi-main high availability is not available |
| n8n Business or Enterprise | Commercial license key required for these editions; files with .ee in the name need a valid Enterprise License | Same deployment paths, with a license key added; queue mode lets workers run on your own servers behind the main instance | Business plan is currently self-hosted only; confirm current pricing and terms on n8n's pricing page before budgeting |
| Activepieces | MIT (Expat) for most code; packages/ee and the ee API folder fall under a separate commercial license | Self-hosted deployment inside your network; the core is MIT, so the core runtime needs no vendor agreement | Confirm each Microsoft 365 piece you need exists as a piece and whether it meets your authentication requirements |
| Node-RED | Apache-2.0 under the OpenJS Foundation | Runs as a Node.js application on servers or edge hardware inside isolated networks | Event-driven and industrial flows rather than business SaaS workflows; Microsoft 365 nodes need to be verified and maintained by your team |
| Windmill | AGPLv3 and Apache-2.0 when built without the enterprise feature flag; prebuilt Community images include proprietary code free for internal use | Docker Compose or Kubernetes Helm charts, with external PostgreSQL such as AWS RDS, GCP Cloud SQL or Azure | Script-first builder suited to developers; prebuilt images carry proprietary code, so confirm the build your auditors accept |
| Microsoft 365 connector depth (all options) | Not a license question; depends on each connector's API and your tenant settings | Requires Graph API or service credentials reachable from your network, plus outbound access to Microsoft endpoints | Confirm connector coverage for each Microsoft 365 service you use, such as Exchange, SharePoint, Teams and Entra ID, before choosing |
| Desktop RPA (all options) | Not applicable | Not replaced by any option above; desktop flows that drive legacy Windows apps need a separate tool | Plan a separate desktop automation path, such as Robot Framework, for flows that cannot be reached through an API |
How to deploy n8n inside your network step by step
This sequence takes n8n from a license decision to a self-hosted instance inside your network that runs flows against on-premises systems, with each step checked before the next one begins. Your existing Power Automate flows keep running until the new ones match them.
Confirm the n8n edition and license position
Your security lead and legal or procurement contact decide which edition fits the use. n8n's main codebase is under the Sustainable Use License, which covers internal business use, and files with .ee in their name need a valid Enterprise License. Without a license key, n8n runs as the free Community edition, and a Business or Enterprise key enables those editions. Multi-main high availability, which runs several main instances, is limited to Enterprise self-hosted deployments, so confirm that requirement now if you need it. Done when the edition, the license key owner and the list of .ee features you will use are written down.
Choose Docker Compose or Kubernetes
Your platform team picks the runtime based on the clusters they already operate. n8n's hosting documentation covers Docker Compose and major cloud providers, so a single host with Compose is the simplest starting point for a pilot. If you already run Kubernetes inside the network, use it for the same reasons you run other internal services. In a disconnected network, pull every container image into your private registry before installation. For Kubernetes control plane images, follow the kubeadm guidance on listing and pulling images in advance and pointing kubeadm init at the private registry with its image repository flag. Done when a test deployment starts from images your registry holds, with no outbound pulls.
Stand up PostgreSQL and Redis for queue mode
Your database team provisions PostgreSQL inside the network, with backups and access limited to the n8n service account. If you need more than one worker, queue mode also needs Redis. In queue mode the main instance handles triggers and webhooks, passes executions through Redis to a pool of workers, and the workers read and write workflow data in PostgreSQL. Ask your database team to confirm backup and restore for both services before any production flow is connected. Done when n8n connects to both services and a test execution is written to PostgreSQL.
Place workers close to on-premises systems
Your integration engineers decide where each worker runs. A worker can only reach the systems on the network segment where it sits, so put workers on the segment that hosts the database servers and file shares your flows use. Keep the main instance and webhook entry point where your security team has approved inbound traffic. Confirm with your network team which outbound and inbound paths each worker needs, and record them. Done when a test worker on the target segment reads a sample table or share, and the main instance can still reach it through Redis and PostgreSQL.
Share the encryption key with workers
Your platform engineer copies the main instance's encryption key into the configuration of every worker and webhook processor. Workers need it to decrypt the credentials stored in the database. Store the key in your secrets manager, restrict who can read it, and record the change in your configuration management system. Losing or rotating the key without a plan makes stored credentials unreadable, so test the restore procedure before go-live. Done when every worker decrypts a test credential and a restore from backup has been rehearsed on a separate host.
Rebuild connections and credentials
Your integration engineers recreate each connection inside n8n, using service accounts that have the least access the flow needs. Power Automate connections and on-premises data gateway bindings do not move with the flows, so each database and file share connection is rebuilt with its own credential and tested. Keep a register that maps each old connection to its new one and to the owner who approved it. Done when every connection in the register passes a test call from the worker that will run it.
Run flows in parallel and compare results
Your process owners run the rebuilt flows alongside the Power Automate originals for a period they agree in advance. For each flow, compare the outputs, error handling and timing against the original, using the same test inputs where possible. Do not switch triggers over until the outputs match and the owner signs off. Confirm that your monitoring captures n8n execution failures and sends alerts to the team that supports the flow. Done when each flow has a signed comparison record and its original trigger has been disabled in a controlled change.
Document, back up and hand over
Your platform team writes the runbook: edition and license holder, deployment files, worker placement, encryption key location, backup schedule and upgrade procedure. Check the n8n release notes before each upgrade and rehearse it in a non-production copy. DeployOpen can support this work under a fixed scope agreed in writing, while your team keeps ownership of the environment. Done when a team member who did not build the system can restore it from the runbook in a test environment.
What you give up when Microsoft 365 connectors leave Power Automate
Native Microsoft 365 connectors do not carry over to n8n. Outlook, SharePoint and Teams are reached inside Power Automate through connectors that Microsoft maintains, with sign-in handled by the Power Platform. In n8n you reach the same services through their Microsoft Graph APIs or through community and built-in nodes, which means each flow that touches mail, document libraries or channel posts needs its triggers, actions and authentication rebuilt and tested. Approvals, adaptive cards and Teams message formatting are the areas most likely to need the longest rework. Ask your Microsoft 365 administrator which app registrations, consent grants and Graph permissions the rebuilt flows will need, and confirm them before any build starts.
A hybrid pattern often limits the rework. Many teams keep the Microsoft 365 steps in Power Automate and move only the steps that must reach on-premises systems into n8n, connected through a webhook or a queue that both platforms can call. The inside-network part then handles database queries and file shares, while the cloud part stays where its connectors already work. The trade-off is two platforms to monitor, two sets of credentials to govern and a data path that still crosses Microsoft's cloud for the Microsoft 365 steps. Document which data crosses the boundary in each direction, because a hybrid design only satisfies a residency requirement if the cloud leg carries no regulated records.
Confirm every connector against the edition you plan to run. Connector availability and feature depth differ between n8n's Community and paid editions, and some capabilities such as SSO and LDAP, Git-based environments and log streaming are listed only for the Business and Enterprise plans on n8n's pricing page. Before you commit, build one representative flow for each Microsoft 365 service you use, run it under the same identity model your security team will approve, and record which steps need a paid edition or a custom node. This check is cheap compared with discovering a missing capability after half the flows are migrated.
Evidence that the on-premises design holds up under review
An on-premises design is only as credible as the records behind it. The cards below list the artifacts an assessor or internal reviewer will usually ask to see, and what each one should show for an n8n deployment inside your network. DeployOpen prepares this evidence, but independent auditors and certification bodies are the ones who issue any opinion.
Network diagrams with restricted paths
Diagrams should show where n8n main, worker and webhook processes sit, which systems they reach inside the network, and which outbound destinations are allowed. Reviewers will look for the absence of inbound paths from the internet and for every allowed route being named. Confirm the diagram matches the live firewall rules, not the design intent, and date it so later changes can be traced.
License records for the n8n edition
Record which n8n edition runs in each environment and why it fits your use. The Sustainable Use License covers internal business use and non-commercial use, but files with .ee in their name need a valid Enterprise License. Keep the license key assignments, the owner who approved them, and a note on whether any multi-main or SSO features are in use, since those depend on the chosen edition.
Credential and encryption key handling
In queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials. Document where the key is generated, how it is stored, who can read it, how it is rotated, and how each worker receives it. Reviewers will also ask how credentials were recreated after migration, because exported workflows do not carry usable secrets with them.
Flow inventories with named owners
List every Power Automate flow being replaced, with its trigger, the systems it touches, the data classification, the business owner and the maker. Mark which flows read on-premises databases or file shares through the gateway and which use Microsoft 365 connectors that stay in Microsoft's cloud. This inventory is the basis for deciding scope and for showing that no flow was dropped without a decision.
Parallel-run test results
Run the n8n flow alongside the original for a defined period and keep records of inputs, outputs, error counts and mismatches. Record each deviation and its fix, plus sign-off from the flow owner. Reviewers use these records to judge whether the replacement behaves the same way before the old flow is switched off, so keep them with the inventory entry they test.
Change and access records
Keep change tickets for every workflow edit, credential change, key rotation, edition upgrade and firewall rule update, along with who approved each one and who made it. Access reviews for n8n users and the server hosts belong here as well. Confirm that changes made to production were tested first, and that the record shows the approver separately from the implementer.
Questions buyers ask before moving on-premises flows
What drives the cost of running n8n inside our network?
The main cost drivers are the n8n edition you choose, the servers and PostgreSQL database you run, the one-time migration effort, and the ongoing operations work. The free Community edition has no license fee, but the Business and Enterprise editions are paid, and n8n's pricing page lists Business at 667 euros per month billed annually and states it is currently self-hosted only. Enterprise is priced on request. Ask for a quote that separates one-time work (inventory, rebuilding flows, testing, cutover) from recurring work (patching, backups, on-call, upgrades) and lists which n8n edition it assumes. Ask who pays for each server and database line item, since those are your costs regardless of the vendor.
How long does an on-premises flow migration take?
Duration depends on how many flows you have, how many depend on on-premises data gateway connections, how many are owned by people who have left, and how many need approvals or custom logic rebuilt. Network access for the new runtime and security review of the hosting environment also add time, especially in regulated networks. Your scope document should list flows by owner and environment, the gateway connections each one uses, and the parallel-run period before switching off Power Automate. A fixed-scope agreement with written deliverables and timelines lets you compare proposals on the same basis.
Can our internal staff run n8n after the migration?
Yes, many teams run n8n with internal staff, but it requires someone to own the servers, the PostgreSQL database, backups, upgrades and access control. If you use queue mode, the main instance's encryption key must be shared with every worker and webhook processor, so key handling needs to be part of the runbook. Multi-main high availability is limited to Enterprise self-hosted deployments according to n8n's queue mode documentation, so confirm which edition supports the availability you need. Assess your team's skills honestly, and ask whether a retainer for upgrades and support would cover the gaps.
What do we need to provide for the engagement?
You will need to provide access to the target infrastructure, a named technical owner, a list of flows and the systems they touch, and decisions on data classification and network paths. Expect to supply security review contacts, change windows and test accounts for each connected system. You also need to confirm which on-premises databases and file shares the flows read, and who approves credentials. The clearer these inputs are in writing before work starts, the fewer surprises appear during the build and cutover.
Can we keep Microsoft 365 connectors after moving off Power Automate?
n8n advertises more than 1,500 integrations, and its documentation covers Microsoft services, but you should verify each Microsoft 365 action your flows use, such as Outlook, SharePoint, Teams or Excel operations, against the current n8n node list before committing. Some actions may need custom HTTP requests against Microsoft Graph, and authentication, licensing of the Microsoft tenant and admin consent still apply. Flows that depend on Power Automate-only features, such as approvals built into Microsoft 365 or desktop flows, will need a different design or stay in Microsoft's stack. Build a connector map that marks each action as native, custom or not supported.
Does the free Community edition fit our internal use?
The Community edition runs without a license key, and n8n's Sustainable Use License permits use for your own internal business purposes, so many internal automations fit that license. However, the license does not permit distributing the software or offering it as a managed service to others, and files with .ee in their name require a valid Enterprise License. Ask your legal or procurement team to read the n8n LICENSE file with your exact use case, including any contractors who operate it. Confirm whether you need Business or Enterprise features such as SSO, LDAP, environments with Git or log streaming, which n8n's pricing page places in those plans.
What security controls should we expect from the hosting setup?
Expect the design to cover network segmentation, encrypted connections to on-premises sources, least-privilege database accounts, secrets handling for credentials, audit logging and a tested backup and restore process. SSO and LDAP are part of n8n's paid editions, so Community deployments need other access controls. Ask for the hardening baseline in writing and how evidence is produced for your compliance team. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or certification.
Can you use n8n internally under its Sustainable Use License?
The Sustainable Use License lets your organization use and modify n8n for its own internal business purposes, and it also covers non-commercial or personal use. For an on-premises deployment that connects to databases and file shares inside your network for your own staff, that internal grant is the relevant permission. The license is narrower than an open-source license such as MIT or Apache-2.0, so the limits matter as much as the grant. Read the full text in the n8n LICENSE.md before you commit to a design.
Two limits apply to this use case. First, files with .ee in their name or directory are not covered by the Sustainable Use License and require a valid n8n Enterprise License. Any feature you enable from those directories, including features your team may assume are part of the free build, needs a license from n8n. Second, the grant covers internal business use only. Running n8n as a service for customers, partners or other outside parties, or distributing it commercially, falls outside the grant. An internal automation platform that a managed service provider operates for its clients is a common case where this line gets crossed without anyone noticing.
Ask your own legal counsel for written advice before rollout, and give them the specifics: which edition and license key you will use, whether any .ee components are in scope, whether a contractor such as DeployOpen will install or operate the instance, and whether any workflow will serve people outside your organization. Keep the written opinion with your architecture records. If a contractor operates the platform for you, confirm in the statement of work that the arrangement is internal use for your organization and not a service offered to others.
How to decide whether this alternative fits your flows
This sequence sorts your Power Automate cloud flows by owner, data location and connector need, so you can decide flow by flow whether n8n running inside your network fits or whether the flow should stay where it is. The output is a reviewed decision list that the migration plan can work from.
Export a complete flow inventory
Flow owners and the Power Platform administrator list every cloud flow across each environment, including flows owned by people who have left, flows shared with teams and flows that run on a schedule without anyone watching them. Record the owner, environment, trigger type and last run date for each one. Done means every environment has been checked and the inventory has a single owner who signed off on its completeness.
Record where each flow's data lives
For each flow, trace every input and output to its system of record and note whether that system is a Microsoft 365 service, a SaaS application, a database or file share inside your network, or a system reached through an on-premises data gateway. Ask the flow owner to confirm the data classification of the records passed through. Done means every flow has a data location entry that a security reviewer has checked against your data inventory.
Mark flows that touch on-premises systems
Flag each flow that reads from or writes to a database, file share, legacy application or internal API reached through an on-premises data gateway. Check the gateway connection list in the Power Platform admin center so you catch connections that flows reference indirectly. Done means you have a short list of on-premises flows, and for each one you know which network segment and credentials it uses today.
Mark flows that need Microsoft 365 connectors
Identify flows that depend on native Microsoft 365 connectors, such as Outlook, SharePoint, Teams, Excel Online or Dataverse actions, along with any approval or premium connector steps. Confirm in n8n's current integration list, which the vendor describes as more than 1,500 integrations, whether each required action exists and whether it covers the features your flow uses. Done means each flow has a connector coverage note marked as available, partial or missing.
Check licensing and compliance constraints per flow
For each flow, confirm which license terms apply to running it on n8n. n8n's main code is under the Sustainable Use License, which covers internal business use, and files with .ee in their name need an n8n Enterprise License, so check the edition that fits your use with n8n directly. Ask your compliance lead which controls apply to flows handling regulated data. Done means each flow lists its edition requirement and any compliance owner who must approve it.
Decide each flow's destination
Sort every flow into one of three outcomes: rebuild in n8n inside your network, keep in Power Automate, or retire. Flows that touch on-premises systems and have connectors n8n covers are the strongest candidates for n8n, while flows that depend on Microsoft 365 features with no equivalent usually stay put. Illustrative example: a nightly file share sync with no Microsoft 365 step is a candidate, while an approval flow built on Teams and Outlook actions may stay. Done means every flow has one recorded decision and a named owner.
Review the decision list with flow owners
Walk through the decision list with the owners and the security and compliance leads, and resolve any flow where the owner disagrees or the connector check is incomplete. Confirm the edition, hosting location and gateway replacement plan for each n8n candidate, and agree on a written list of what your organization will ask a migration partner or vendor to confirm. Done means the list is signed off and every open question has an owner and a date you choose.
How DeployOpen deploys n8n inside your network
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For on-premises data, that means an n8n deployment that runs in your network, reaches your databases and file shares directly, and keeps workflow data and credentials under your control.
How we scope
- Inventory the Power Automate flows that touch on-premises databases and file shares, by owner and environment.
- Agree in writing which Microsoft 365 connectors stay in Power Automate and which move to n8n.
- Define the license edition, hosting target and network paths before any build work starts.
How we build
- Deploy n8n inside your network using Docker Compose or Kubernetes, with PostgreSQL for workflow data.
- Rebuild priority flows, connect internal systems directly, and replace gateway-based connections.
- Test each rebuilt flow against the original output, and confirm credentials are stored and protected.
How we hand over
- Document the architecture, network paths, flow inventory, credential handling and encryption key management.
- Provide runbooks for backups, upgrades and restores, and walk your operations team through them.
- Deliver control evidence that your auditors can review, while the assessment itself stays with independent auditors.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan n8n upgrades and patch checks, including verifying packages carried across an isolated boundary.
- Confirm with your team the license edition and features your scope needs before you commit.
