Replicate SQLite to Object Storage with Litestream

SQLite on one VPS is a single disk away from a bad day. Snapshots and nightly copies help, but they leave a window of lost writes. Litestream sits beside the database, tails the WAL, and ships those frames to object storage you already pay for. The application keeps opening a local file. The replica is a sequence of snapshots plus WAL segments in a bucket.

Netbay does not sell object storage. Point Litestream at an S3-compatible API you control: AWS S3, Cloudflare R2, MinIO on another machine, Backblaze B2, or a provider with a compatible endpoint. The VPS in Lucknow DC01 holds the live file. The bucket is the off-site copy. That split is the whole design.

How replication of a file database works

Litestream opens the database in WAL mode, takes a snapshot, then copies new WAL pages as they appear. Object storage sees a snapshot object and a series of compact WAL segments. Restore downloads the snapshot and replays segments up to a point in time. There is no SQL replica, no standby SQLite accepting writes, no logical decoding. You get a delayed, consistent file somewhere else.

That is enough for ransomware, disk failure, and an accidental DROP TABLE, if you test the restore. It is not multi-primary. Do not run two Litestream-restored apps that both write and expect them to merge.

Install the binary, enable WAL, and keep the service user able to read the database directory. Litestream needs to lock like any other reader/writer of the WAL. Run it as a systemd unit next to the app, not as a cron that starts and stops.

A minimal config against S3-compatible storage

Use environment variables for keys. Do not put secrets in the YAML that you will copy into git.

dbs:
  - path: /var/lib/myapp/data/app.db
    replicas:
      - type: s3
        bucket: myapp-sqlite-wal
        path: app
        endpoint: https://s3.example.invalid
        region: auto
        force-path-style: true
        sync-interval: 1s
        retention: 72h

[Service]
User=myapp
Group=myapp
EnvironmentFile=/etc/myapp/litestream.env
ExecStart=/usr/local/bin/litestream replicate -config /etc/myapp/litestream.yml
Restart=on-failure

litestream.env holds LITESTREAM_ACCESS_KEY_ID and LITESTREAM_SECRET_ACCESS_KEY. Restrict that file to mode 600. sync-interval of 1s keeps the replica close to live without a write amplification disaster on a quiet database. Retention of 72 hours is a starting point: enough to recover from a delayed DROP, short enough that you notice storage growth. Snapshots plus segments will exceed the live database size; budget for it.

Before you trust it, restore to a scratch directory on the same host and run PRAGMA integrity_check.

sudo -u myapp litestream restore -config /etc/myapp/litestream.yml -o /tmp/app.restore.db /var/lib/myapp/data/app.db
sqlite3 /tmp/app.restore.db "PRAGMA integrity_check;"

Use a scratch path under /var/lib/myapp/restore in real life, not /tmp, so a private tmp or a reboot cannot confuse you. The command above is the first dry run. After it works, script the restore onto a second directory, boot the app against the copy, and hit a health endpoint. A replica you have never restored is a folder of objects.

What Litestream does not replace

You still want a periodic full file copy (.backup or VACUUM INTO) stored independently of the replica pipeline. If the Litestream config is wrong, both live shipping and restore fail together. A weekly file you copied with a different tool breaks that correlation.

Litestream also does not protect a database that lives on a laptop path, a world-writable directory, or NFS. Fix placement first. It does not give you read replicas for query load; restore is for recovery. If you need a second app server reading fresh data, you have left the SQLite single-host model and should be looking at Postgres.

Watch disk on the VPS. If checkpoints stall, the WAL grows, Litestream ships more, and object storage bills climb. A stuck reader is an ops problem that now has a cloud invoice.

Ship WAL frames off-box, restore onto a scratch file, and keep a second copy that does not share the replica config. You can spin up an Ubuntu 24.04 instance on Netbay in under 60 seconds and follow along — netbayhosts.in.