OpenRun builds in Litestream replication for SQLite apps on Docker and Kubernetes

What OpenRun added

OpenRun, an open-source, self-hosted GitOps platform for deploying web apps and internal tools on Docker, Podman or Kubernetes, has added built-in Litestream support for SQLite applications. According to OpenRun's announcement, which surfaced on the Hacker News front page, app databases are continuously replicated to AWS S3 or any S3-compatible object store — Cloudflare R2, MinIO and SeaweedFS are named — and restores happen automatically whenever OpenRun detects an empty or recreated app volume.

The goal is that application developers keep using SQLite exactly as before: they do not install Litestream, configure object storage in the app, modify the container image, or write restore logic. Litestream is configured once in the server configuration, and OpenRun manages replication and restoration outside the app container.

How the setup works

The Litestream backend is defined once in the server's openrun.toml, pointing at a bucket, region and credentials pulled from environment secrets. A SQLite service then references that config, and apps bind to the service:

openrun service create sqlite/main --is-default --config litestream_config=mainbackup openrun app create --bind sqlite --approve github.com/example/notes-app /notes

The same app can be declared in an apply file kept in Git, and openrun apply behaves like Kubernetes apply: it creates new apps, updates apps whose configuration changed, and leaves the rest alone, so the SQLite binding can be managed entirely through GitOps.

Apps with the binding receive a persistent volume mounted at /data and locate their database through injected environment variables (SQLITE_DB_PATH and SQLITE_DIR). Every *.db file the app creates in that directory is replicated, including files created at runtime. With the default settings, changes typically reach object storage within about a second, and the sync interval is configurable.

Single node versus Kubernetes

On Docker and Podman, OpenRun runs Litestream in a per-app companion container that shares the app's data volume. Restore containers run before the app starts on an empty volume, and when an idle app scales down to zero, the Litestream container performs a final sync and stops.

On Kubernetes, the binding's volume becomes a PersistentVolumeClaim and OpenRun adds a restore init container plus a native Litestream sidecar (Kubernetes 1.29 or newer) to the app pod. The sidecar starts before the app container and is terminated after it, allowing a final sync during orderly shutdown. Apps with a SQLite binding run as a single replica with the Recreate update strategy, which prevents two app pods from writing to the same SQLite volume during an update.

Litestream is embedded in the OpenRun binary as a Go library, so the platform's own metadata and audit databases can be replicated the same way through a metadata.litestream_config setting, without running an extra process.

Recovery and monitoring

A lost app volume is handled without operator action: on the next start, OpenRun sees the empty volume, pulls the databases back from the replica, and starts the app against restored data. Replicas are keyed by binding, so attaching the same binding to a new app restores the data into that app's fresh volume as well.

For a full node loss, the documented procedure is to install OpenRun on a new machine and start the server with the same config file; the server restores its metadata from the replica and comes back with apps, bindings, versions and audit history intact, with each app redeploying on first request and restoring its own data. OpenRun says this scenario is exercised end-to-end in CI, where the test hard-kills the server and deletes containers, volumes and the installation directory before verifying that everything is rebuilt from object storage.

Monitoring is available via openrun replication status, which reports the state of every replicated database. States combine the replica listing in object storage with the replication container's state, so a failed replication container is visible even when object storage still holds a recent replica.

Why it matters

SQLite is a strong fit for internal tools and small web apps because there is no database server to operate, but durability on a single node has always been the weak spot. Litestream already solved replication, but until now you had to assemble the plumbing yourself: sidecars, restore-on-start hooks, storage credentials and image changes. By absorbing that work into the platform — with the same app configuration working on a single Docker host and on Kubernetes — OpenRun makes self-hosted SQLite apps viable in production without running a database service. The trade-off is explicit and worth noting: replication is asynchronous, so a sudden crash can lose roughly the most recent second of writes. OpenRun's guidance for apps points to WAL mode, busy timeouts and short write transactions to keep that window small.