Trust
Security you can explain in a review
Flynn isolates apps from each other and from the platform, scopes every person's access to the apps they own, and keeps secrets, data, and keys on your machines.
Apps cannot see each other on the wire
Every application process gets its own network namespace on the cluster overlay, and the platform enforces who may talk to whom. An app cannot open a connection to another app, to a different process type of itself, or to any internal platform service. It reaches other apps only through routes you created, and databases only at the address Flynn injected into its configuration.
Each provisioned Postgres user can connect only to its own database, so a leaked connection string from one app does not open another's data — or the platform's.
Hardened, unprivileged containers
- User namespaces: root inside a container is an unprivileged user on the host.
- Seccomp, AppArmor, dropped capabilities, and no-new-privileges on every application process.
- No host networking, host PID, device access, or bind mounts for application jobs.
- Application and build jobs are blocked from the host's SSH, HTTP, and cluster-control ports.
Flynn is designed for your own team's software. It is not a sandbox for running code you do not trust, and the documentation says so.
Named people, scoped access
Developers sign in through the dashboard and receive a short-lived token that carries exactly the permissions they were granted — the same token works in the CLI. Cluster administrators hold the controller key, which is root for the cluster and never needs to be shared with application teams.
| Role | Can | Cannot |
|---|---|---|
| View | Read overview, logs, metrics, jobs, and team | Change anything |
| Deploy | Deploy, plus everything View can | Scale, edit config, routes, or team |
| Manage | Config, scale, routes, releases, deploys | Manage the team |
| Admin | Everything on the app, including invitations and roles | Touch other apps or the platform |
| Custom | Administrators compose roles from individual permissions — read logs but not env, run jobs but not scale, manage routes but not resources — and they appear in the app's team picker. | |
TLS at the edge and inside
- Public routes get Let's Encrypt certificates automatically, or a certificate you supply.
- The platform API and dashboard present trusted certificates once ACME is enabled; the CLI pins the certificate to prevent interception.
- Datastores speak TLS to your apps: Postgres with a cluster-generated certificate, and MariaDB, MongoDB, Redis, Kafka, and ClickHouse with a private CA the cluster issues.
- Exposed databases leave the cluster on TCP routes that pass TLS through to the database by default, or terminate it with a Let's Encrypt certificate.
You hold the keys
Secrets live in app configuration, set from the CLI or dashboard and never committed to git. Database credentials are generated per app. Backups are files on disks you own. Binaries and images come from GitHub Releases over HTTPS, and the installer verifies what it downloads.
There is no license server and no vendor account. The platform does send an anonymous usage count — version, number of hosts, apps, and jobs — to the maintainers twice a day, and operators can switch that off with a single setting.
Where Flynn stands today
Flynn is a community-maintained fork working toward secure-by-default. Internal cluster ports carry no authentication and must stay behind a firewall — the installer configures one, and the host firewall tooling keeps it in sync. The maintainers recommend reading the security and production documentation before placing sensitive data on a cluster.
Security reports go through private GitHub security advisories, with coordinated disclosure and a fix published as a release.
Next
Try it on one machine
The whole platform, including the dashboard and network isolation, runs on a single Ubuntu host for evaluation.