Self-hosted Tray.ai alternative for on-premises systems

Why a self-hosted Tray.ai alternative must sit inside the on-premises network

If your automations must reach a database, file share or SOAP service that stays inside your network, the replacement has to run inside that network too. n8n or Windmill, deployed inside the network, can reach those systems directly, because the workflow engine opens the connection to the target itself. Tray.ai reaches private systems through an on-prem agent that works from a fixed list of supported connectors, so anything outside that list needs a custom path or is not reachable at all. Before you choose, confirm with Tray.ai exactly which of your internal systems its agent and connectors cover in your contract, and list the rest.

The on-prem agent model is the constraint to understand. Tray.ai's agent sits in your network and connects out to the cloud platform, so the workflow still depends on the vendor's connector catalog and on its hosting region. A self-hosted engine removes that dependency: the engine, its credentials and its network path all sit in your environment. Compare with how Workato's on-prem documentation describes its own agent, which also makes only outbound connections, so the real question is which connectors you need, not only where the agent runs.

This page covers the options and the gaps honestly. n8n's Community edition is free to self-host, but its license limits use to internal business purposes, and the SSO, Git environments and log streaming features sit in its Business and Enterprise plans. Windmill's Community Edition also allows internal use, but its Enterprise features, including SAML, external secret backends and full Git sync, are paid. Neither product ships a connector for every legacy system, so for a SOAP service you may write an HTTP or script step, and you should test it against a non-production copy first. Plan for the staff who will own the engine, the credential store and the database behind it.

What on-premises connectivity requires from the platform

Reaching internal systems without an agent for each one depends on where the runtime sits, which direction connections travel, where credentials are stored and what the license allows. The cards below set out those requirements, using Workato's on-prem agent as a reference point for how a cloud-controlled product handles the network boundary.

Outbound-only reach from the network

Workato's on-prem agent sits inside the customer's network and makes only outbound connections to Workato over a TLS WebSocket tunnel, so no inbound firewall ports are needed. That is a useful reference point, but it still means one agent component per network zone. A self-hosted n8n or Windmill instance placed inside the network can reach internal databases, file shares and SOAP services directly, so the question is which network paths the runtime must cross. Ask your security team to map every target system to an allowed path and firewall rule before the design is approved.

Runtime hosted inside the network

The workflow engine itself must run in your own data center, cloud account or air-gapped segment for internal systems to be reached without a relay. Both n8n and Windmill document Docker Compose installs, and Windmill also documents Kubernetes Helm charts. Confirm which deployment method your platform team can operate, how the containers pull images in an isolated network, and who patches the host operating system and runtime.

Credentials encrypted in the database

In n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read credentials stored in PostgreSQL. Any database, file share or SOAP service login therefore lives in the same database as the workflows, protected by that key. Plan how the key is generated, stored, rotated and restored after a failure, and confirm which secret backends your edition supports for keeping passwords out of the workflow database.

Licensing that covers internal use

n8n's Sustainable Use License permits use for your own internal business purposes, but files with .ee in their name need a valid n8n Enterprise License. Windmill's prebuilt Community images include proprietary code that is free for internal use, while managed services or resale need a commercial license. Check the license text against how you plan to use the platform, especially if you intend to offer workflows to partners or customers outside the company.

High availability and edition limits

Queue mode separates triggers and webhooks from a pool of workers, which lets an internal runtime scale with its workload. Multi-main setups for high availability are restricted to Enterprise self-hosted deployments in n8n. Ask which features a given edition includes before you commit to a design that depends on failover, and confirm how the main instance recovers if its database connection drops.

Verified packages carried across boundaries

Isolated networks cannot pull updates on demand, so every container image, package and connector update is carried in from outside. NERC CIP-013-2 addresses verifying the integrity and authenticity of vendor software and patches in supply chain procurement, and that applies here if your environment falls under it. Document how each artifact is checked before it crosses the boundary, and confirm with your compliance lead which requirements apply to your sector.

Which open-source platforms fit an on-premises deployment

This table compares n8n, Windmill, Node-RED and Activepieces on how each reaches systems inside your network, the license terms that govern internal use, and the trade-offs that matter for an on-premises deployment. Read the connector and license rows first, because they decide whether a platform reaches your SOAP services and file shares without an agent.

Factor	n8n	Windmill	Node-RED and Activepieces
Reaching internal systems	Runs inside your network and calls databases, file shares and HTTP services directly, with no on-prem agent	Scripts run on workers inside your network, so any library-accessible database, file share or SOAP client is reachable	Node-RED flows and Activepieces pieces run inside your network; confirm connector coverage for each system
SOAP and file share support	Confirm SOAP and file share nodes in the current catalog; generic HTTP and custom code are the usual fallback	Confirm the client libraries your language needs; code can call SOAP endpoints and mount shares if the worker image allows it	Confirm whether a SOAP or SMB node exists in your version; otherwise plan custom function code
License for internal use	Sustainable Use License permits internal business use; files with .ee in the name need an Enterprise License	Source compiled without the enterprise flag is AGPLv3 and Apache-2.0; prebuilt Community images include proprietary code free for internal use	Node-RED is Apache-2.0; Activepieces is MIT except packages/ee and its ee app directory, which need a commercial license
Community edition limits	Free self-hosted Community edition; multi-main high availability is not available in Community	Community Edition is unlimited in executions but capped at 3 workspaces, 50 users and 4 groups	Node-RED has no seat or workspace caps; confirm feature parity with your required controls
Paid features relevant to on-prem	SAML SSO and log streaming are in Business and Enterprise; multi-main is Enterprise self-hosted only	Enterprise adds SAML and SCIM, audit logs, Vault and AWS Secrets Manager support, and full Git sync	Activepieces paid features sit in ee directories; Node-RED paid add-ons are not part of the core project
Deployment and scaling	Docker Compose or queue mode with Redis and PostgreSQL; share the encryption key with every worker	Docker Compose or Kubernetes Helm with external PostgreSQL; workers pull jobs from a PostgreSQL queue	Single-process Node-RED is simple to run; Activepieces needs a database and its own sizing review
Best fit	Department automation that calls internal APIs and databases from one network zone	Engineering-led teams that want code-first jobs, version control and sandboxed execution in their own network	Lightweight event flows or teams already standardized on those tools

Choosing n8n or Windmill by team and workflow type

Teams that automate approvals, notifications, data syncs between SaaS tools and internal systems often need a visual canvas that analysts and operations staff can read without writing code. n8n fits this profile well because it combines a node-based builder with a large integration catalog and allows custom JavaScript or Python where a node is missing. Business owners can review flows, and a small platform group can govern credentials and environments centrally.

Canvas-first building: Non-developers can trace each step, inspect data between nodes and hand flows to engineers for hardening.
Integration breadth: n8n advertises more than 1,500 integrations, so check that the specific internal and SaaS systems you need are present or reachable through HTTP and database nodes.
Edition fit: Community is free for internal business use under the Sustainable Use License, while SSO, LDAP, Git environments and log streaming sit in the Business and Enterprise plans according to n8n's pricing page.
Execution model: n8n counts one execution per whole workflow run, which keeps department-scale volume easier to forecast than per-step billing.
Governance load: Expect the platform team to own credentials, folder permissions and workflow review.

Confirm with your identity team whether SAML single sign-on is a requirement before you choose an edition, and ask n8n for written confirmation of what your chosen edition includes.

How to deploy n8n or Windmill inside the network

This sequence takes a network-local automation platform from scoping the zones and internal systems it must reach to a running, backed-up instance that can call databases and SOAP services without an on-prem agent. Each step ends with a check you can verify before moving on.

Map network zones and target systems
Before any install, the network team and the integration owner list which internal systems the platform must reach, such as databases, file shares, SOAP endpoints and REST APIs, and the network zone each one sits in. Record the ports, protocols and direction of every connection, and note which zones may accept inbound traffic from the automation host. Confirm whether the platform will also receive webhooks from outside the network, since that decides where a reverse proxy or inbound rule is needed. Done when the team has a signed-off table of source, destination, port and purpose for every flow, and the security team has approved it.
Choose the platform and edition
Select n8n or Windmill based on the workflow mix the mapping produced. Confirm the license terms with your legal team, because n8n is under the Sustainable Use License and Windmill's Community Edition terms differ by build, and check which features you need, such as SSO, LDAP, Git sync or multi-main high availability, against the edition that includes them. Ask each vendor to confirm current editions and pricing in writing, since quotes and plan limits change. Done when the decision record names the platform, edition, license basis and the features that justify it.
Install from Docker Compose or Kubernetes
Deploy the chosen platform inside the network using its documented method. Both n8n and Windmill document Docker Compose, and Windmill also documents Kubernetes Helm charts. For a Kubernetes cluster with no internet access, pull the control plane images in advance with kubeadm config images list and kubeadm config images pull, mirror them into a private registry, and point kubeadm init at that registry with the --image-repository flag. Pull application images the same way and load them into the internal registry. Done when the containers or pods start, the admin UI loads from an internal address, and no install step needed an outbound connection.
Connect an external PostgreSQL database
If your standard is a managed or central PostgreSQL service, create a dedicated database and role for the platform and point the install at it. Windmill documents support for external PostgreSQL such as AWS RDS, GCP Cloud SQL and Azure, and n8n stores workflow data and credentials in its database, including its queue mode setup. Restrict the role to its own database, enable encryption in transit where your database team requires it, and keep the credentials in your secrets manager. Done when the platform restarts cleanly against the external database and the database team confirms the connection and role permissions.
Share the encryption key for queue mode workers
In n8n queue mode, the main instance hands executions to workers through Redis, and the workers read and write workflow data in PostgreSQL. Workers and webhook processors must have the main instance's encryption key so they can decrypt stored credentials, so store that key in your secrets manager and inject it into every worker and webhook processor at deploy time. Keep a record of who holds the key and rotate it through a planned change, because losing it makes stored credentials unreadable. Done when a test workflow running on a worker reads a stored credential successfully and the key is absent from images and configuration files in version control.
Configure internal database and SOAP access
Create service accounts for each internal target with the least privilege the workflows need, such as read-only access to specific tables or a single SOAP operation. Store the credentials in the platform's credential store or your external secret backend, and restrict which workflows can use each one. For SOAP services, import the WSDL from an internal location, test each operation against a non-production endpoint, and check TLS certificate trust, because an internal certificate authority must be added to the container trust store. Done when each target returns expected test results from the automation host and a denied request from an unauthorized workflow is logged.
Set up backups and restore tests
Back up the platform database on a schedule, store copies in a location outside the automation host, and include the encryption key in your key backup process rather than in the database dump. Save the container configuration and workflow exports in version control. Test a restore into a separate environment and record how long it took, so the figure comes from your own test rather than a vendor claim. Done when a restored copy runs the sample workflows and the restore result is recorded in the runbook.
Plan upgrades and offline patch intake
Define how new releases enter the network. Subscribe to the vendor's release notes, review changes to the database schema and any breaking changes, and test each upgrade in staging before production. For air-gapped sites, verify the integrity and authenticity of each image and package before it crosses the boundary, consistent with the software verification expectations in NERC CIP-013-2 where that standard applies. Done when a dated upgrade runbook exists, the first staged upgrade completes, and the change record shows who approved the image hashes.

Carrying packages and rules across an isolated boundary

On a network with no internet access, nothing gets installed by reaching out to a public registry. Every container image, platform package, and Node.js or Python dependency that n8n or Windmill needs has to be carried across the boundary on approved media, staged in a local registry or package mirror, and checked before anything runs. That makes the transfer a controlled process, not a one-time download. Under NERC CIP-013-2, supply chain procurement processes must address verifying the software integrity and authenticity of vendor software and patches, and the same reasoning applies to the packages you bring in for a workflow platform even if your sector is not electric utilities. Ask your team to record where each artifact came from, its checksum or signature, and who approved it.

Vendors with air-gapped support publish their own offline guidance, and it is worth reading before you plan the transfer. GitLab documents running self-managed instances in offline environments, Security Onion supports full installs without internet access and updates from newer ISO media in airgap mode, and Wazuh publishes an offline installation guide along with an offline vulnerability repository option. The pattern is the same across all three: a complete bundle is prepared on a connected system, moved in, and applied locally. For n8n and Windmill, confirm with each vendor and in your own test environment how the container images, npm packages, and Python dependencies used by scripts are mirrored, which registries and package indexes must be replicated, and whether any feature pulls assets at runtime.

Plan one rehearsal before production. Build a staging copy of the platform with the network egress blocked, install from the mirror only, and run every workflow type you intend to migrate, including Python and TypeScript scripts that import third-party libraries. Any failure that points to an outside address is a dependency you have not yet mirrored. Keep the bundle manifest with the change record so future upgrades repeat the same verified path, and treat each new release as a new transfer that goes through the same checks.

Evidence that regulators and auditors ask for

Auditors and regulators rarely accept a platform choice on its own. They ask where data flows, who can reach what, and how software entered the environment. The cards below list the records a self-hosted n8n or Windmill deployment should produce, and what to check in each one. DeployOpen prepares this evidence for your assessment, but independent auditors and certification bodies issue any audit report or certification.

Trust boundary architecture diagrams

Draw the network zones the workflow engine sits in, the internal databases, file shares and SOAP services it reaches, and every inbound and outbound path. Show that the platform makes no connection to a vendor cloud, and that webhook endpoints are published only where a documented need exists. Reviewers for NERC CIP-005-7 style Electronic Security Perimeter questions look first at this diagram, so keep it versioned alongside the deployment code.

Register of reachable internal systems

Keep a per-workflow record of each internal system it calls, the account it uses, the network path, and the data classes it touches. This replaces the connector list that a vendor agent would otherwise define. Review the register whenever a workflow is added or changed, and confirm that each database or service account has the narrowest permissions the workflow needs.

Credential storage and key handling

Document where credentials are stored, how the encryption key is generated, who holds 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, so the key distribution path is itself evidence. Confirm whether Windmill secrets sit in its database or in an external secret backend, and record which option you chose.

Access control and SSO setup

Record how operators and workflow builders sign in, which roles can edit or run workflows, and how access is removed when people leave. n8n SAML single sign-on is available on the Business and Enterprise plans, so plan that cost into the design if your identity provider must enforce sign-in. Keep the identity provider configuration and the role mapping as exportable records for your assessor.

Audit logs for workflow changes

Assessors ask who changed a workflow, what changed, and when it ran. Windmill Enterprise adds audit logs, along with SAML, SCIM and external secret backends such as Vault and AWS Secrets Manager. Community deployments need a separate change record, such as version-controlled exports reviewed through pull requests. Confirm the retention period with your own compliance team, since no default is fixed here.

Package verification records

Anything carried across an isolated boundary, including container images, Python and npm packages, and connector code, needs a record showing where it came from and how its integrity was checked. NERC CIP-013-2 addresses verification of vendor software and patches in supply chain procurement, and the same discipline applies to open-source packages. Keep checksums, the mirror source and the approval record for each import.

Questions buyers ask before choosing an on-premises alternative

What does an on-premises alternative to Tray.ai cost to run?

The cost splits into four components: software licenses, infrastructure, implementation and staff time. Self-hosted n8n Community and Windmill Community carry no license fee, so the recurring spend shifts to servers, PostgreSQL, backups, monitoring and the people who run them. Paid editions add their own fees. Windmill's pricing page lists a self-hosted Enterprise Edition starting at $120 per month, priced at $20 per month per developer and $10 per month per operator plus compute units. n8n's pricing page lists a Business plan at 667 euros per month billed annually, currently self-hosted only. Ask any vendor or partner for a quote that separates one-time implementation from recurring licenses, infrastructure and support, and that states which connectors and internal systems are in scope.

Is n8n Community or Windmill Community enough for production use?

It can be, but it depends on the features and limits your team needs. The Community editions are free to self-host, and Windmill's pricing page lists its Community Edition with unlimited executions, limited to 3 workspaces, 50 users and 4 groups as of October 2026. n8n's pricing page states that all plans include unlimited users, workflows and integrations. Features such as SAML single sign-on, Git environments and log streaming are limited to n8n's Business and Enterprise plans, and n8n multi-main high availability is Enterprise only. Windmill Enterprise adds SAML and SCIM, audit logs, external secret backends such as Vault and AWS Secrets Manager, and autoscaling. Check the licensing terms with your legal team, because n8n's Sustainable Use License limits use to internal business purposes or non-commercial use.

How long does a migration from Tray.ai take?

No migration duration is supplied for this page, so treat any number from a vendor or partner as an estimate to verify. The timeline is driven by the number of workflows, how many are business-critical, how many depend on on-prem agent connections, how many authentications must be recreated, and how much testing the owners require before cutover. Teams usually move one project at a time, starting with low-risk workflows and keeping Tray.ai running until each replacement is verified. Ask for a written plan that lists the workflow inventory, the internal systems each workflow reaches, the cutover order and the rollback steps before agreeing to a fixed-scope timeline.

What must our team provide before an implementation starts?

The engagement needs access and decisions from your side. Expect to provide a list of workflows and their owners, a network map showing which databases, file shares and SOAP services each workflow must reach, and a hosting target such as a virtual machine cluster, Kubernetes or Docker hosts inside your network. You will also need a PostgreSQL database that meets your standards, identity provider details for single sign-on, a secrets store and a named approver for credentials and change windows. For n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor, so decide early how that key will be stored and rotated. Confirm these inputs in the written scope.

Can our own engineers run the alternative without outside help?

Yes, many teams do, provided they have people who can operate Linux, containers, PostgreSQL and backups, and who can write and maintain workflows. Windmill's README gives a sizing rule of thumb of one worker per vCPU with 1 to 2 GB of RAM, which helps with capacity planning. Staff time is the cost most often underestimated, because someone must patch the platform, rotate credentials, monitor queues and test upgrades. A partner can cover some or all of this work under a fixed-scope project or an ongoing retainer. Decide which parts stay in-house before you request a quote, so the scope and handover documentation match your team's skills.

How does an on-prem agent differ from a self-hosted platform inside the network?

A cloud platform with an on-prem agent keeps the workflow engine in the vendor's cloud and reaches your network through the agent. Workato's documentation describes its agent as making only outbound connections over a TLS WebSocket tunnel, which avoids inbound firewall rules. A self-hosted n8n or Windmill instance runs the engine inside your network, so it can call any internal database, file share or SOAP service directly, subject to your own firewall and segmentation rules. Confirm with your security team which network paths, service accounts and egress rules the new platform will need, and document each one for review.

How do we read a fixed-scope quote for this work?

A fixed-scope quote should list the deliverables, the systems and workflows in scope, the assumptions about your environment, the acceptance tests and the items excluded. Check that it names who performs each task, what is one-time and what recurs, and which third-party licenses or infrastructure costs you pay directly. Ask how changes to scope are priced, what documentation and training are included, and how backups, upgrades and security testing are handled after go-live. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your infrastructure and provides a price only after the written scope is agreed. It prepares evidence for compliance assessments but does not issue audit reports or certifications.

What DeployOpen plans and delivers for on-premises connectivity

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted n8n or Windmill inside your own network, whether that network sits in your cloud accounts, a data center or an air-gapped segment. For this topic, the first deliverable is a written map of which internal targets the runtime must reach: the database hosts, file shares and SOAP endpoints that Tray.ai currently reaches through its on-prem agent. That map drives the network design, including which segments the workflow runtime can open connections to, which ports are allowed, and where the runtime's connection to PostgreSQL and any queue components must sit. Engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts, and the reader should expect the connector inventory and network paths to be listed as named deliverables.

On the hardening side, the work covers the settings that matter most when a workflow engine can reach sensitive internal systems. For n8n, that includes the encryption key handling in queue mode, the role of SSO and LDAP, and how credentials are stored and scoped per environment. For Windmill, it includes worker isolation, how database and secret backends are configured, and how scripts are version controlled and reviewed before they run against production targets. Documentation covers the architecture, the runbooks for restores and upgrades, and the evidence that a security or compliance team will ask for. DeployOpen prepares these systems and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies do that work.

Ongoing operation is handled through retainers for support, upgrades and continuous testing, which you should price separately from the initial build. Ask any provider to state in the quote which items are one-time (design, build, hardening, initial documentation) and which recur (patching, license management, backup verification, support hours). Confirm with your own security team which edition and license terms your use case requires before the scope is fixed, because licensing conditions for both n8n and Windmill depend on how the software is used. DeployOpen does not publish a price list, so a quote follows from the written scope and the inventory of on-premises targets you provide.

How DeployOpen works on this

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For on-premises Tray.ai replacements, that means placing n8n or Windmill on your side of the network, reaching internal databases, file shares and SOAP services directly, and handing over a runtime your team can operate.

How we scope

We map which internal systems, databases, file shares and SOAP services each Tray.ai project reaches today.
We agree in writing which workflows move, which stay on Tray.ai during overlap, and which are retired.
Engagements are fixed-scope, with deliverables and timelines confirmed before work starts; ongoing support is available as a retainer.

How we build

We deploy n8n or Windmill inside your network, with Docker Compose or Kubernetes Helm charts and an external PostgreSQL database.
We configure network paths, credentials and encryption keys so workers reach internal systems without an on-prem agent.
We test each rebuilt workflow against its current inputs and outputs, and check every package carried across an isolated boundary.

How we hand over

We document architecture, network paths, credential handling, licensing and the exact edition in use.
We deliver runbooks for backup, restore, upgrades and worker scaling, so your staff can operate the platform.
We prepare controls and evidence for your compliance assessments, while independent auditors and certification bodies perform any audit.

How we support

We help confirm license terms and edition features, such as SSO, queue mode and high availability, before design is locked.
Upgrades, backups and continuous security testing of the platform can be covered by a retainer agreed in writing.
We provide security testing of workflows and APIs, so changes to internal integrations are checked before they reach production.