Which fits an engineering-led team weighing a Tray.ai switch
Tray.ai fits teams whose automation is built by business analysts and integration specialists in a visual builder, who rely on a vendor-managed cloud and want to use its existing connector catalog without writing much code. Windmill fits engineering-led teams that want workflows as code: scripts in Python or TypeScript, versioned in Git, and run on infrastructure the organization controls. A renewal, a hosting or residency requirement, or a wish to review automation the way software is reviewed usually points toward Windmill, but only after the team confirms it will own the build and the operation. The first question is who builds and maintains the workflows. Windmill scripts can be written in Python, TypeScript, Go, Bash, SQL and several other languages, then composed into flows or low-code apps, so the work suits developers who are comfortable with pull requests and tests. If the people who change workflows most often are not engineers, a visual builder will still matter, and the migration will carry a training cost. Ask which roles will edit workflows in month one and in year two, and whether Git sync and code review are acceptable to them. The second question is where the systems sit and how much custom logic each workflow contains. Windmill's self-hosting options include Docker Compose and Kubernetes Helm charts, with external PostgreSQL support for services such as AWS RDS, GCP Cloud SQL and Azure, so the runtime can sit next to internal databases and APIs. Confirm which Windmill edition provides full Git sync, SAML and SCIM, and external secret backends, because those features are listed on the Enterprise tier, and check them against your identity and secrets requirements before you commit.
Which workflows suit each platform
This table maps common workflow types to the platform that fits better and the condition that decides it, comparing Tray.ai's low-code builder with self-hosted Windmill. Read each row against your own team's skills and network constraints, since the deciding condition matters more than general preference.
| Workflow type | Better fit | Deciding condition |
|---|---|---|
| Developer-built internal tools | Windmill | Engineers want to write logic in Python or TypeScript, keep it in Git and review it like application code |
| Scheduled data jobs | Windmill | Jobs need custom code, SQL or Bash, run on a schedule and must execute inside your own network |
| Low-code apps for operators | Windmill | Operations staff need forms and dashboards over scripts, and an engineer can maintain the underlying code |
| Business-user builds of simple connector flows | Tray.ai | Non-engineers build and maintain point-to-point flows through a visual builder and the connectors they need are already supported |
| Access to on-prem databases and file shares | Windmill | Your Windmill workers can reach the systems directly from your network, so no on-prem agent or fixed connector list is required |
| Regulated change control | Windmill | Scripts can go through pull requests, review and version history in your own Git, which suits change approval evidence |
| Long-tail or proprietary SaaS integrations | Windmill | No prebuilt connector exists, so the team writes and tests an API call in code it controls |
| Connector-heavy cross-SaaS workflows with vendor support | Tray.ai | You depend on the vendor's maintained connectors and support contract rather than on in-house upkeep |
How Windmill's code-first model differs from Tray.ai's visual builder
In Windmill, the unit of automation is a script, and scripts can be written in Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust and more. Those scripts are then composed into flows or low-code apps. This means the logic of a workflow lives as source code that engineers can read, diff and review, instead of as a canvas of connected boxes. Tray.ai's low-code builder keeps the logic in its own visual model, so the question for your team is where reviewers will look for the truth about what a workflow does, and how they will test it before it touches production data.
The practical effect shows up in review, testing and reuse. A script in a Git repository can go through the same pull request, linting and unit test steps your engineers already use for application code, and a shared helper function can be imported by many flows instead of copied into each one. Confirm with Windmill's documentation how its Git sync and deployment flow map onto your branching model before you commit to it, because the answer determines who can approve a change. Tray.ai's visual builder is faster for a business analyst to read and assemble, and that matters for a department-wide automation program. Plan for a split: business users may keep a visual builder for simple, low-risk routing, while engineering owns the scripts behind sensitive integrations.
Choose code-first for workflows that handle money, personal data or access decisions, and for logic that several teams will reuse. Choose a visual builder for short, owner-maintained processes where the person who changes the workflow is not an engineer. Before a pilot, ask an engineer and a business owner each to explain one existing Tray.ai project in their own words, then rebuild it in Windmill and compare how quickly each can review the result. That exercise shows which group will maintain the workflow after the migration and what training that group needs.
Capabilities side by side
This table compares how Tray.ai and self-hosted Windmill differ in builder model, languages, deployment and control. Read the Windmill column as facts from its public documentation and the Tray.ai column as the category baseline, then confirm connector coverage and governance features against your own Tray.ai tenant.
| Capability | Tray.ai | Windmill (self-hosted) |
|---|---|---|
| Builder model | Visual low-code workflow builder aimed at business and integration users | Scripts composed into flows or low-code apps; code is the primary unit of work |
| Languages | Visual builder with expression logic; confirm any custom code options in your plan | Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust and more |
| Connectors and integrations | Large prebuilt connector catalog; confirm coverage for each system you need in your tenant | Scripts call any API or database you can reach; prebuilt integrations depend on what your team writes or shares |
| Version control | Project export as JSON; confirm what the export keeps and what it leaves out | Scripts and flows are code; full Git sync is listed as an Enterprise feature |
| Scheduling and triggers | Schedules, webhooks and event triggers through the builder; confirm trigger types per connector | Schedules, webhooks and job triggers configured on scripts and flows; confirm the set you need in your version |
| App building | Workflow-led; confirm whether any front-end app layer is included in your plan | Low-code apps built on top of scripts and flows |
| Secrets handling | Vault-style credential storage managed inside the vendor's service; confirm governance options in your tenant | Built-in secret storage; external Vault and AWS Secrets Manager backends are an Enterprise feature |
| On-prem reach | Reaches internal systems through an on-prem agent and supported connectors | Runs inside your network, so internal databases and services are reachable without an agent |
| Deployment targets | Vendor-hosted in supported regions; on-premises options depend on plan | Docker Compose or Kubernetes Helm charts, with external PostgreSQL such as AWS RDS, GCP Cloud SQL or Azure |
Where data and runtime live under each option
Tray.ai runs in the vendor's cloud regions, with an on-prem agent for internal systems, while Windmill runs wherever you deploy it. The cards below cover where workflow code and data sit, how jobs execute, what identity and audit controls depend on edition, and what you must document yourself.
Tray.ai hosting and the on-prem agent
Tray.ai runs its platform in vendor-operated cloud regions, and its on-prem connectivity relies on an agent that you install in your network. Ask Tray.ai in writing which region hosts your tenant, where execution logs and stored data reside, and which agent features and connectors your plan includes. Confirm whether regional hosting or on-premises options are Enterprise-only, since that determines how far your data and runtime can be pinned to a location.
Windmill on your own infrastructure
Windmill is deployed with Docker Compose or Kubernetes Helm charts, so the runtime, workflow definitions and run history sit in your environment. Its API servers are stateless, and workers pull jobs from a PostgreSQL queue, which lets you place the database on managed services such as AWS RDS, GCP Cloud SQL or Azure. Decide whether your team will run the PostgreSQL instance, the workers and the upgrade cycle yourself.
Job isolation with nsjail sandboxing
Windmill sandboxes job execution with nsjail, which limits what a script can access on the host while it runs. This matters when workflows execute user-supplied or third-party code, or when several teams share one workspace. Test the sandbox against the scripts you actually run, and confirm which worker hosts can reach internal networks and secrets, since those network paths define the blast radius of a compromised job.
Identity and audit controls by edition
Windmill's Community Edition is free for internal use with a limit of 50 users, but SAML, SCIM and audit logs are part of its Enterprise Edition. Tray.ai's identity and audit features depend on your contracted plan as well. Map each required control, such as single sign-on, automated user deprovisioning and an audit trail of workflow changes, to the edition or plan that provides it before you choose a platform.
Compliance evidence you must produce
Whichever platform you choose, the evidence that your controls work belongs to your organization and your auditor. Collect where each workflow runs, which network paths and credentials it can reach, who can change or approve workflows, and how access reviews and log retention are performed. DeployOpen can prepare systems, controls and evidence for an assessment, but audit reports and certifications are issued only by independent auditors and certification bodies.
What Windmill's license allows inside a regulated organization
The first question for a regulated buyer is which Windmill license applies to the copy you run. Source code compiled without the enterprise feature flag is available under AGPLv3 and Apache-2.0. Prebuilt Community Edition images are different: they include proprietary code that is free for internal use, while managed services or reselling require a commercial license. Your legal team should confirm that running Windmill for your own internal workflows, possibly for many business units, fits the Community Edition terms, and that any plan to offer automations to customers or partners as a hosted service triggers a separate license. Keep the exact image you deploy and the license text that governs it in your change records.
The Community Edition pricing page, as of October 2026, lists unlimited executions with limits of 3 workspaces, 50 users and 4 groups. If your Tray.ai estate spans more departments, more people or more separated teams, those limits decide whether you need the Enterprise Edition. The self-hosted Enterprise Edition starts at $120 per month, priced by developers at $20 per month each, operators at $10 per month each and compute units, according to the same pricing page. Ask Windmill for a written quote that states how developers, operators and compute units are counted for your environment, and whether the figure includes support.
Enterprise adds SAML and SCIM, audit logs, external secret backends such as Vault and AWS Secrets Manager, full Git sync, autoscaling, and Prometheus and OpenTelemetry support. For a regulated organization, the identity, audit and secrets items usually matter most, because they connect Windmill to the controls you already evidence. Ask whether the Community Edition's access and logging meet your own access review and log retention requirements before you choose a tier. DeployOpen can help prepare that evidence, but whether the license fits your obligations is a decision for your counsel and your compliance function.
What each option costs to own
This table lists the cost components on the Tray.ai side and the Windmill side, marking which are one-time or recurring and what moves each one. Tray.ai pricing comes from a sales quote, so the reader should ask for every component in writing. Windmill's Community Edition has no license fee, and its Enterprise pricing is published, but the infrastructure and staff time are the largest costs on both sides.
| Cost component | Tray.ai (cloud or on-prem agent) | Windmill (self-hosted) |
|---|---|---|
| Software license or subscription | Quoted by sales, based on tasks and features; recurring annual or contract term | Community Edition has no license fee; Enterprise starts at $120 per month plus $20 per developer and $10 per operator per month, plus compute units (Windmill pricing page, October 2026); recurring |
| Hosting and regional options | Hosting region and on-prem capability are plan-dependent add-ons; confirm in the quote | Runs on your own cloud accounts or data centers, so region is your choice; recurring infrastructure cost |
| Infrastructure for runtime | Included in the vendor's cloud; on-prem agent runs on your hosts | Compute for API servers and workers; the README suggests one worker per vCPU with 1 to 2 GB of RAM as a starting point; recurring |
| PostgreSQL database | Not applicable to you | Required; managed options such as AWS RDS, GCP Cloud SQL or Azure are supported, and each carries a recurring service fee |
| Staff time to operate | Low for day-to-day builds; vendor handles the runtime | Platform owner, plus time for backups, monitoring and on-call; recurring and the largest variable cost |
| Upgrades and patching | Handled by the vendor on its release schedule | You schedule upgrades; Windmill's latest release is frequent, so budget recurring test time |
| Migration and rebuild | One-time, if leaving Tray.ai: export projects as JSON, then rebuild and re-create connections | One-time for building flows and scripts in Windmill, plus setup of Git sync and secret backends if needed |
| Cost drivers to watch | Task volume, feature tier and regional or on-prem add-ons | Developer and operator seat count, compute size, database tier and the time spent on operations |
How a move from Tray.ai to Windmill usually runs
The sequence turns Tray.ai projects into a reviewed inventory of Windmill scripts and flows running inside your network, with each workflow cut over only after it has been checked against the original.
Inventory every Tray.ai project and workflow
The platform team and workflow owners list every project, workflow, trigger, schedule and downstream system, then record which business owner depends on each one. Export each project as JSON using Tray.ai's export options, and confirm with your Tray.ai account team what the export contains. Expect it to leave behind stored data, access control and authentication secrets, so note those gaps in the inventory. The step is done when every workflow has an owner, a trigger type and a named target system in a single list.
Sort workflows into code and low-code candidates
Engineers and workflow owners decide which workflows become Windmill scripts in Python, TypeScript or another supported language, which become flows that chain scripts, and which should stay as simple internal apps. Workflows with heavy branching, data transformation or calls to internal APIs usually suit code, while simple notification or sync jobs may suit flows. Retire workflows nobody uses. The output is a decision register that names the target form, owner and reviewer for each workflow.
Recreate authentications and secrets in Windmill
The security team and integration owners recreate each connection in Windmill as a resource or variable, rather than copying values from exports, which do not carry credentials. Where your policy requires a central vault, confirm with Windmill which secret backends your edition supports, since its pricing page lists external secret backends such as Vault and AWS Secrets Manager for Enterprise Edition. Restrict access by workspace and group. The step closes when each credential has an owner, a rotation plan and a test call that succeeds from the new environment.
Deploy Windmill inside the customer network
The infrastructure team deploys Windmill into your own cloud account, data center or private network using Docker Compose for a single-host install or Kubernetes with the Helm chart for a cluster. Connect an external PostgreSQL database, such as AWS RDS, GCP Cloud SQL or Azure, if your standards require managed databases. Size workers using the README's rule of one worker per vCPU with 1 to 2 GB of RAM as a starting point, then validate with real load. The step is done when the instance is reachable only by approved users and backups of the database are tested.
Rebuild and test workflows in parallel
Developers rebuild each selected workflow as a Windmill script or flow, store the code in Git, and run it against non-production systems next to the live Tray.ai version. Compare outputs, error handling, retries and timing for the same inputs, and have the business owner sign off on results. Use Windmill's Git sync features according to your edition, and confirm which Git integration your plan includes. The step is complete when each workflow has recorded test runs and a signed-off comparison against Tray.ai.
Cut over one workflow at a time
The team switches triggers workflow by workflow, starting with low-risk jobs, and keeps the Tray.ai version disabled but available for rollback during an agreed window. Monitor job queues, failures and alerts in Windmill, and confirm that scheduled jobs and webhooks fire once and only once. Remove Tray.ai connections after each cutover, not before. The step is done when every workflow in the register runs on Windmill, the Tray.ai copies are disabled, and the owners have accepted the handover.
Decommission Tray.ai and document the estate
Once all workflows are running on Windmill, the owners close the Tray.ai subscription through the terms in the contract, delete stored credentials there, and keep the exports as archived records. The team updates runbooks, access reviews and the on-call list with the Windmill operating model, including upgrade routines for the release cadence. Ask your Tray.ai contact to confirm the exact exit and data deletion steps in writing. The step is complete when the decommissioning record is signed and the documentation is stored with the platform team.
Questions buyers ask before choosing Windmill over Tray.ai
What does it cost to run Windmill in-house compared with Tray.ai?
Running Windmill yourself means paying for infrastructure, a PostgreSQL database, staff time to operate and upgrade it, and any edition fees you choose. The Community Edition is free to self-host with unlimited executions, within limits of 3 workspaces, 50 users and 4 groups, according to Windmill's pricing page as of October 2026. The self-hosted Enterprise Edition starts at $120 per month, priced by developers at $20 per month each, operators at $10 per month each and compute units, according to the same page. Tray.ai is quoted through sales by tasks and features, so the comparison turns on your execution volume, headcount and which Enterprise features you need. Ask Tray.ai for a written quote tied to your volumes, and build a Windmill model with your own infrastructure and staff hours.
How much engineering skill does Windmill need?
Windmill assumes engineers can write and review code, because scripts are written in languages such as Python, TypeScript, Go, Bash, SQL and Rust. Someone on your team also needs to operate the platform, which runs on Docker Compose or Kubernetes Helm charts with an external PostgreSQL database. Tray.ai's visual builder lets a broader group of staff assemble simple workflows without code, so the skill gap is real but it is a different kind of skill. Teams usually pair a few engineers who own shared scripts with analysts who call them from flows or apps. Check the hiring and training plan before you commit.
Can business users build flows in Windmill?
Business users can build simple apps and flows in Windmill, but the platform is built around scripts first. Windmill composes scripts into flows and low-code apps, so the people who write the underlying logic remain central. If your team depends on drag-and-drop builders for most workflows, Tray.ai or n8n may fit those users better. A practical split is to let engineers publish reusable scripts and let non-developers run or configure the apps built on them. Test this with a few of your real workflows before you decide.
How long does a migration from Tray.ai to Windmill take?
No supplied figure gives a duration for this migration, so treat any number from a vendor or partner as a claim to verify. The main drivers are the number of projects, how many connectors each one uses, how much logic is embedded in builder steps versus code you can reuse, how many authentications must be recreated, and how many workflows depend on the on-prem agent. Windmill scripts can replace logic that Tray.ai handles with visual steps, which often takes more design work than a direct copy. Start with an inventory of projects and dependencies, then migrate in waves by project.
What does a Windmill migration need from our team?
Your team needs to supply access to the source Tray.ai projects, the people who own each business process, and the credentials and approval paths for every connected system. Engineers must decide where shared logic should live, how secrets are stored and how workflows are tested before cutover. If workflows reach internal systems, your network team must confirm how Windmill workers will reach them, since Windmill runs inside your network rather than through an on-prem agent. Expect to name an owner for each migrated workflow after go-live. Confirm these responsibilities in the written scope.
Can we migrate Windmill ourselves without an implementation partner?
Yes, if your engineers have the skills and time, since Windmill's self-hosting paths are documented in its repository and the Community Edition is free to self-host within its limits. The harder parts are rebuilding authentications, which Tray.ai exports do not carry over in full, and validating outputs against the live process. Internal capacity is often the constraint, not the software. A partner such as DeployOpen can plan, implement, integrate and document the platform in your infrastructure under a fixed-scope agreement, with the scope, deliverables and timelines agreed in writing before work starts. Compare the cost of your own staff time with a written quote.
How does Windmill handle upgrades given its release cadence?
Windmill publishes releases frequently. As of October 2026, its latest release on GitHub was v1.840.0, released on October 17, 2026, which reflects that cadence. Plan a regular upgrade routine in a staging environment, test your scripts and flows against each target version, and read release notes before upgrading production. Keep the PostgreSQL database backed up before each change. Ask whether your chosen edition and any external secret backend you use need extra steps at each upgrade. Upgrades can be covered by an ongoing retainer, which DeployOpen offers.
When keeping Tray.ai is the better choice
Keeping Tray.ai is the better choice when a migration would cost more in risk than it returns in savings. The clearest signal is a visual builder that business users rely on daily. If operations or sales staff build and change their own workflows in Tray.ai's low-code canvas, moving those flows to Windmill shifts the authoring work to engineers who write Python or TypeScript scripts and compose them into flows. That shift is a change in who owns automation, and it should be a deliberate decision with the business owners involved, not a side effect of a platform move.
Connector coverage is the second condition. Before deciding, list every connector your workflows call and check whether each one is either available as a Windmill script or can be written in code by your team with a maintained client library. Count the ones that depend on vendor-specific triggers, webhooks or authentication flows that a developer would have to rebuild and test. Where the gap is large, or where a connector is used by a critical process, the cost of writing and maintaining custom code can outweigh the savings from a cheaper runtime. Ask your engineering lead to estimate that effort per connector, and confirm the current Windmill integration options directly in its documentation rather than assuming parity.
A contracted vendor support model and a migration timeline with real risk also justify staying. If your organization has a support agreement with Tray.ai that covers incident response, or if internal audit has already mapped Tray.ai controls for an upcoming assessment, a platform change will require new evidence, new runbooks and new approvals. Note that Windmill's self-hosted Community Edition and Enterprise Edition carry different feature sets, so check which capabilities your controls depend on, such as SSO, audit logs or external secret backends, before you compare. In many cases a staged plan, where stable low-risk flows move first and business-critical ones stay until the new platform is proven, is a better answer than an all-or-nothing decision.
How DeployOpen helps evaluate and implement Windmill
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Tray.ai vs Windmill, we start by agreeing on which workflows move, where Windmill runs and what the team must be able to operate after handover.
How we scope
- We inventory existing Tray.ai projects and sort them by business owner, data sensitivity and on-prem dependency.
- We decide which workflows become Windmill scripts, flows or apps and which stay in Tray.ai during a transition.
- We confirm the hosting target, Docker Compose or Kubernetes, and whether an external PostgreSQL service is required.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We deploy Windmill inside your cloud account, data center or air-gapped network, with workers sized to your job volume.
- We connect Git sync, secrets backends and identity settings to your existing repositories and access controls.
- We rebuild priority workflows as versioned scripts, then test inputs, outputs and failure handling against Tray.ai results.
- We run security testing on the workflows and their connections, covering credentials, sandboxing and network paths.
How we hand over
- We document the deployment, workflow inventory, connection setup and the license terms that apply to your edition.
- We walk your engineers through writing, reviewing, deploying and rolling back Windmill scripts in your own repositories.
- We prepare backup and restore procedures for the PostgreSQL database and the configuration your team needs to keep.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover Windmill version upgrades, worker scaling reviews and periodic testing of critical workflows.
- Ask any provider to confirm which Windmill edition and license terms apply to your planned use before a quote is signed.
