The wrkr CLI
Backups & restore
Backups on Wrkr aren't a product you configure, they're built into the layers where your data actually lives. There are three, and it's worth knowing which one covers what.
1. Your machine, hourly, automatic, offsite
Your home directory is backed up every hour, encrypted, to offsite storage,
with no setup from you. Your code, your shell history, your dotfiles, and the data
your in-plan services keep under your home directory, your wrkr db
Postgres and your wrkr cache, are covered.
If your machine is ever rebuilt, your home directory is restored from the latest backup. This is included in the plan and always on, there's nothing to enable.
What rides the hourly lane, and what doesn't. The hourly backup captures your home directory. Changes you make at the system level, outside
~, packages installed withapt, cron entries, edits under/etc, or a service that stores its data in a system path, are not in that backup; on a rebuild they are re-imaged from the base machine, not restored. Widening what the backup captures is on the roadmap. Until then, keep anything that must survive a rebuild under your home directory, inwrkr db, or inwrkr storage.
2. Your app's database, on-demand snapshots
For your app's Postgres database, take point-in-time snapshots and restore them whenever you want, before a risky migration, or to roll back a bad change:
wrkr db snapshot [--note <text>] [--json]
wrkr db snapshot list [--json]
wrkr db snapshot rm <snapshot-id> [--json]
wrkr db restore <snapshot-id> [--yes] [--json]
wrkr db restore --file <path> [--yes] [--json]
wrkr db export <path> [--format plain|custom] [--json]
wrkr db snapshot --note "before the v2 schema change"
wrkr db restore <snapshot-id> --yes
You can also take a portable dump anytime with wrkr db export, a standard
pg_dump you can store anywhere or move off Wrkr entirely. Full guide:
Database.
3. Your app's files, durable object storage
Files your app puts in wrkr storage live in durable object storage
that survives a machine rebuild. They're not tied to your machine's disk, so
a rebuild of the box doesn't touch them.
What backups don't do for you
Backups protect your work and your app's data. They are not a feature your
app gives its own users. If your product needs to let its customers export
their own data ("download all my data"), that's a feature your app implements,
using the same primitives (wrkr db export, wrkr storage), not something Wrkr
runs on your behalf.
Recovering
| You want to… | Do this |
|---|---|
| Undo a bad database change | wrkr db restore <snapshot-id> |
| Get a portable copy of your data | wrkr db export ./backup.dump --format custom |
| Recover your home directory after a rebuild | It's restored from the hourly offsite backup |
| Recover app files | They're durable in wrkr storage; nothing to restore |
Offsite snapshots are kept as 24 hourly, 14 daily, and 8 weekly restore points.
If a disk, or an entire host, is ever lost, your machine is rebuilt and your home directory is restored from the latest offsite snapshot: your files, your projects, and the data in your in-plan services come back. System-level changes outside your home directory are re-imaged from the base machine, not restored (see the note in section 1). Today a restore is something Wrkr runs for you, and we don't quote a fixed turnaround.