Self-Hosted vs Cloud Automation: Who Actually Owns Your Workflows

Self-hosted and cloud automation platforms solve the same problem in different places. One runs inside your infrastructure, on hardware you control. The other runs inside someone else's, on hardware they bill you for. The label matters less than three questions: what happens to your workflows when the provider changes pricing, what happens to them when your server crashes at 3 a.m., and what happens to them when you want to leave.

Most builders default to whichever tool they learned first, then discover the trade-offs in production. The honest comparison is not about which platform is better in the abstract. It is about which set of failure modes you would rather inherit, and which ones your team can actually handle.

What "self-hosted" actually means in 2026

Self-hosted automation used to mean running a single VM with a Docker container and a Postgres database. That is still the core, but the category has split into two distinct shapes, and they have very different operational profiles.

The first shape is the traditional workflow engine: n8n, Node-RED, Airflow, Temporal self-hosted. You write or buy workflows, the engine executes them, and you own the database, the credentials, the logs, and the upgrade cycle. You are responsible for backups, scaling, monitoring, and the day a CVE drops. The second shape is a newer breed of platform-engineering tools that wrap an approval and execution layer around scripts and containers. Flowctl, for example, ships as a single binary with PostgreSQL behind it, exposes OIDC and RBAC, and runs Docker or script executors on remote nodes over SSH. The framing is operations rather than integrations: provisioning, scheduled maintenance, and human-approved actions, with a secrets store built in.

Both shapes qualify as self-hosted. Both require you to run infrastructure. The difference is what kind of work you are automating, and how much of the surrounding ceremony (approvals, namespaces, audit logs) the tool handles for you.

What "cloud" means, and what it really costs

Cloud automation platforms, Zapier, Make, Workato, the hosted tiers of most vendors, abstract away the server, the database, and the upgrade window. You get a UI, a connector library, a billing meter, and an SLA. For teams that do not want to run infrastructure, that is a fair trade.

The costs show up in three places. First, per-task or per-operation pricing that compounds as workflows multiply. Second, feature gating: SSO, RBAC, audit logs, and durable execution often live behind higher tiers, and the cheapest path to those capabilities is sometimes paying for a year upfront. Third, exit cost. Workflows built in a hosted platform live inside that platform's data model. Export formats vary in quality. Credentials are usually scoped to the platform's vault, not yours.

None of these are deal-breakers on their own. Together they are why builders start asking about ownership after their second or third re-platforming.

Durability is not the same as hosting

One of the more useful shifts in the last year is the rise of lightweight durable workflow libraries that sit on top of Postgres. DBOS, for instance, checkpoints workflow state directly in the database, so a crashed worker resumes from the last completed step rather than restarting the whole pipeline. The library is open source and runs in your application, with no separate orchestrator service to operate.

This matters because durability used to be a feature of heavy schedulers: Temporal, Airflow with Celery, large Airflow deployments with external databases. The new pattern is "annotate a function, get checkpoints." For builders evaluating self-hosted vs cloud, the practical question is no longer "can I get durability?" but "where does the state live, and who can read it?" A cloud-hosted durable workflow is still a workflow whose state lives in someone else's database.

A practical decision framework

Before choosing a platform, write down the answers to these five questions. They will save a re-platforming later.

• Where do credentials live? If secrets live only in the platform's vault, you cannot move them when you leave. Self-hosted tools with an encrypted secrets store let you rotate, export, and audit independently.

• Can a non-engineer approve a sensitive step? Operational workflows (database migrations, infra changes, customer-data exports) almost always need a human gate. Platforms built for integration automation may not have approvals at all.

• What is the failure story? If the platform goes down, what runs and what waits? Cloud platforms give you their SLA; self-hosted gives you whatever monitoring you set up. Neither is free.

• What does export look like? A JSON workflow definition you can re-import elsewhere is meaningfully different from a proprietary graph format with no public schema.

• Who patches the runtime? Self-hosted means you patch it. Cloud means the vendor patches it, and you hope the patch does not break a connector you depend on.

When self-hosted wins

Self-hosted is the right call when the work touches infrastructure, regulated data, or secrets you would not hand to a third party. It is also the right call when you already have a platform or DevOps team, when volume makes per-task pricing painful, or when the workflow needs to outlive the vendor relationship. A niche agency that runs the same ten workflows for five years benefits less from a hosted platform's connector breadth than from owning the runtime outright.

The newer operational platforms fit especially well here. They assume you will run them on your own hardware or in your own cloud account, and they treat approvals, RBAC, and audit trails as first-class features rather than paid add-ons. That is the right shape for back-office automations that need a human in the loop.

When cloud wins

Cloud is the right call when the team is small, the workflows are mostly glue between SaaS apps, and the cost of a part-time engineer exceeds the platform bill. Hosted platforms compress the time from "I want a workflow" to "the workflow runs" more than any self-hosted stack, and that compression is worth paying for when nobody on the team wants to operate Postgres at 2 a.m.

Cloud is also the right call when the workflows are experimental. If you do not yet know whether the automation will stick, paying monthly for hosted execution is cheaper than provisioning infrastructure you may rip out in six months.

The hybrid pattern that most teams end up with

Almost no serious automation stack is purely one or the other. The pattern that holds up in practice: cloud-hosted for the long tail of SaaS-to-SaaS glue, self-hosted for the workflows that touch money, identity, or infrastructure. Customer onboarding might live in a hosted platform because it touches eight marketing tools. Payment reconciliation runs self-hosted because it touches the database and the bank. Support triage might be a cloud workflow today and migrate to a self-hosted orchestrator once it becomes load-bearing.

Treat the boundary as a deliberate one. Decide per workflow, not per platform. The market has matured enough that the question is no longer "self-hosted or cloud" but "which workflows belong where, and what is our exit plan if we change our minds."