Logs
Every process's output is aggregated per app. Tail it live, filter by process, or read it in the dashboard.
Operate
Day two, planned for
A small operations team can keep a Flynn cluster healthy. The tools for growing, updating, backing up, and watching the platform ship with it.
01 / Size
Availability you can size
- One host to evaluate Flynn and prove the workflow. Not for production.
- Three or more hosts for production. The cluster tolerates the loss of one node with little or no impact, and the built-in databases fail over automatically.
- Grow later. Join additional hosts with a token or a list of peer addresses. Replace a failed consensus member by promoting another host.
Install the discovery plugin and new nodes can fetch their join token from the cluster itself — no separate coordination service to run.
02 / Update
Rolling updates from one command
Flynn and its plugins are published as GitHub Releases; you decide when to move. A cluster-wide update pushes new host binaries to every node, pulls the new component images, and redeploys the platform's own apps in place — with close to zero downtime for applications, and only a brief pause for database clusters.
Before it touches anything, the updater cleans unused images and volumes and confirms each host has enough free disk. If a host is short on space, the update stops before the cluster is left half-upgraded. Plugins update in step with the platform, and one command brings every installed plugin to the matching release.
Back up first. The in-place updater is newer than the rest of Flynn, and the documentation says so plainly. Taking a backup before each update is the recommended path.
03 / Recover
Backups you can restore onto new hardware
One command produces a single archive. Restoring it during bootstrap brings up the same apps, routes, releases, and plugins on a fresh cluster — the cluster size does not need to match. Individual apps can also be exported and imported, with their databases, to the same or a different cluster.
In the backup
- App definitions, releases, routes, and configuration
- Build artifacts and container images
- Every Postgres database, including the platform's own
- MariaDB and MongoDB data, when those plugins are running
- Which plugins were installed, so restore does not re-run installers
Not in the backup
- Redis data — it lives on a volume, so treat it as a cache
- Kafka topics and messages
- ClickHouse tables
- Application volume contents
These engines come back empty after a restore. Plan their backups with their own tooling.
04 / Observe
See what is happening
Flynn keeps logs and metrics inside the cluster and hands them to the tools you already have.
Syslog forwarding
Send one app's logs, all app logs, or the platform's own logs to any syslog endpoint.
OpenTelemetry metrics
The OpenTelemetry plugin exports host CPU, memory, disk, load, and job counts to Grafana, an OTel Collector, or any OTLP endpoint.
Alerts and status
Threshold alerts on app or cluster metrics by email or webhook, plus a health endpoint that reports the state of every platform component.
05 / Toolbox
The rest of the operator toolbox
- Host firewall management keeps only 80, 443, and the TCP ports you choose open to the internet, and syncs peer addresses as the cluster changes.
- Blob storage backends. Keep build artifacts in the built-in Postgres, or move them to S3, Google Cloud Storage, or Azure Storage for larger installations.
- Host tags steer particular process types to particular machines.
- Debug bundles and repair. Collect logs and system state into one archive for support, and run the built-in repair tool when a cluster is unhealthy.
- Plugin lifecycle. Install, update, and uninstall first-party plugins from the host, pinned to releases that match the running platform version.
Next
How Flynn keeps apps and people apart
Network isolation, hardened containers, per-app roles, and what a security review will find.