Product companies leaving a hosted PaaS
Keep the deploy loop your developers know while moving to hardware or a VPC you control.
Why Flynn
You should not have to choose between a platform your developers like and infrastructure your operators control. Flynn is built so you get both.
Every part of Flynn — the router, the build system, the scheduler, the databases — runs on hosts you administer. There is no third-party tenant between your team and production, no metered bill, and no account that can be suspended.
That matters for the compliance questionnaire, for the finance conversation, and for the outage that happens in someone else's region.
Self-hosting usually means developers lose the workflow they liked. With Flynn they keep it: create an app, push, get a URL. Attach a database with one command. Scale from the CLI or the dashboard. Stand up a staging app from the same repository with a second remote.
Operators, in turn, get a cluster they can back up, grow, update, and explain to security — without becoming a platform-engineering department.
Flynn is BSD-3-Clause licensed and runs on standard Ubuntu 24.04 LTS. Application images, database dumps, and DNS are yours. Cluster backups restore onto new hardware — with the contents spelled out on the Operate page — and individual apps export and import between clusters with their databases.
The platform components are ordinary apps on the cluster, so the same tools you use for your software inspect and update Flynn itself.
You pay for the servers you run. Traffic growth is a capacity plan — add a host — rather than a pricing-tier conversation. A three-node cluster with modest hardware is enough to start.
Compared
Three common ways to run web applications, and how Flynn stacks up on the questions buyers actually ask.
| Question | Hosted PaaS | Assemble it yourself | Flynn |
|---|---|---|---|
| Where does it run? | The vendor's cloud | Anywhere you build it | Your Ubuntu servers, VMs, or private cloud |
| Developer workflow | git push, dashboard | Whatever you write | git push, Dockerfile, image push, GitHub App, dashboard |
| HTTPS, routing, load balancing | Included | Pick, install, and maintain each piece | Included, with Let's Encrypt automation |
| Databases | Add-ons, billed separately | Operate them yourself | HA Postgres built in; five engines as plugins |
| Team access control | Included | Build or integrate | Per-app roles with fine-grained grants |
| Cost model | Per dyno, per add-on, per seat | Machines plus engineering time | Machines |
| Who is on call? | The vendor | You | You — with backup, update, and repair tooling included |
| Largest workloads | Vendor-dependent | Anything you engineer | Small production today; databases not tuned for very large datasets |
Who it is for
Keep the deploy loop your developers know while moving to hardware or a VPC you control.
Run many small apps for many stakeholders on one cluster, with per-app roles instead of shared credentials.
Application data, logs, and build artifacts stay inside your network, on hosts your own policies already govern.
Next
High availability, adding hosts, rolling updates, and an honest description of what a backup contains.