Litestream Backups

Slasha provides native, automated backup and replication for applications utilizing SQLite databases, powered by Litestream.

Continuous SQLite Replication

Litestream works by running as a background process alongside your application. It continuously streams SQLite's Write-Ahead Log (WAL) directly to an S3-compatible cloud storage bucket. This provides sub-second recovery point objectives (RPO)—meaning if your server crashes, you lose almost zero data.

Configuration Fields

Backups are configured on a per-app basis via the Slasha dashboard. You must provide the following fields:

  • db_path: The absolute path to your SQLite database inside the container. This does not have to be /data/app.db; it can be any valid path your app writes to.
  • bucket: The name of your S3 bucket (e.g. my-app-backups).
  • endpoint: The S3 endpoint URL (e.g. s3.us-east-1.amazonaws.com, or a Cloudflare R2 / DigitalOcean Spaces endpoint).
  • access_key_id: Your S3 API access key.
  • secret_access_key: Your S3 API secret key.
  • path_prefix: An optional folder prefix inside the bucket.

Automated Restores

Restores are handled automatically. On every deployment (or container restart), Slasha executes a pre-boot check before starting your application's web or worker processes.

If Litestream detects that the database file at db_path does not exist, it will automatically download the latest replica from your S3 bucket and restore the database state. Once the restore completes, your app boots normally.

If you need to forcefully restore an existing database (overwriting local data), you can use the restore_pending flag in the database, or trigger a manual restore via the dashboard.

Health Checks

Slasha continuously monitors the status of your Litestream replication. In the dashboard, you can view:

  • last_synced_at: The exact timestamp of the last successful WAL upload.
  • healthy: A boolean indicating if replication is functioning normally.
  • health_error: Any error messages if the upload to S3 fails (e.g. bad credentials).

Single-Writer Limitation

Scaling Constraint: SQLite requires a single process to be the writer. Therefore, when Litestream backups are enabled for an app, Slasha locks the web process count to a maximum of 1 instance. Attempting to scale beyond 1 while backups are enabled will be rejected.