Every automation conversation reaches the same fork: pay per execution on someone else's runtime, or run it yourself. The honest version of that decision is not about ideology, it is about which costs you are willing to see as a line item and which ones you would rather absorb as your own time. Here is what self-hosting a workflow engine actually costs, using the one we build and maintain as the worked example.
One PHP Application and One SQLite File
Workflow Chain Engine is deliberately small. The whole system is one PHP application with a single SQLite file, no framework, no build step, and no dependency install, so it runs on a three dollar shared host as happily as on a VPS or in a container. The visual editor ships inside the project, so nothing loads from anyone else's servers while you work.
That shape decides the operating cost. Backups are a folder copy. Moving hosts is a folder copy. There is no queue service to keep alive, no database server to tune, and no upgrade that needs a migration weekend. The code is MIT licensed and lives on GitHub, so the version you run is the version you can read.
Four Triggers, One Run History
A flow is only useful at the moment it starts, and there are four of those: a webhook another service calls, an authenticated run API for your own code, a schedule, and a button. All four fill the same workflow variables from whatever they carry, and all four land in the same run history.
One webhook detail is worth stealing no matter what you run. The response carries the run's real result, meaning the resolved success or fail message with its variables filled in, the step count, the run ID and the duration. Services that display webhook responses then show something meaningful, and services that retry on failure can react to a genuine Fail instead of guessing from a status code.
Where Self-Hosting Actually Bites
The server is not the hard part. Observability is. A hosted product hands you run history, alerting and retries as table stakes, and the moment you self-host those become things you have to insist on. Every node in our engine logs after the placeholders resolve, so a run detail shows the real URL that was called, the real comparison that was made, and the value each variable ended on. That is the difference between a two minute fix and an afternoon spent reproducing a failure.
The second real cost is credentials. They now live in your database, which is exactly why some teams self-host and exactly why others should not. If nobody owns rotating them, self-hosting moved a risk rather than removing one.
Who Should Not Bother
If your workflows are mostly connectors between large SaaS products, the volume is modest, and nobody on the team wants to own an upgrade path, pay the per-run price and get on with your work. Self-hosting earns its keep when data cannot leave your environment, when execution volume makes per-run pricing look silly, or when you want the workflows themselves as artifacts you version alongside the rest of your infrastructure.
What To Take Away
Self hosting is not cheaper by default. It is cheaper when the things you need most are control over your data, predictable cost at volume, and a run log you can actually read. Judge any engine on that last one, ours included, by looking at what it tells you after a run fails rather than how the editor looks when everything works.
Full documentation, the six node types, and the source.
