Every second of your database, restorable.

One minute, start to restore.

Real commands and the real console against a demo catalog: list every database, see what changed overnight, restore it into a sandbox.

0:58 · with sound · 2.7 MB

The console

OverviewA databaseA diff

The CLI

$ keeper targets
TARGET              ENGINE    ORG/PROJECT/ENV      LAST FULL             PITR WINDOW                                  STORED    HEALTH
analytics/events    postgres  acme/data/staging    2026-10-07 02:11:47Z  -                                            19.1GiB   ok
auth/users          postgres  acme/platform/prod   2026-10-07 02:11:06Z  2026-09-23 02:11:06Z → 2026-10-07 18:50:52Z  1.5GiB    ok
billing/invoices    mysql     acme/billing/prod    2026-10-07 02:09:03Z  2026-09-23 02:09:03Z → 2026-10-07 18:50:52Z  6.7GiB    ok
billing/ledger      postgres  acme/billing/prod    2026-10-07 02:08:22Z  2026-09-23 02:08:22Z → 2026-10-07 18:50:52Z  14.3GiB   ok
maps/geo            postgres  acme/maps/prod       2026-10-07 02:10:25Z  2026-09-23 02:10:25Z → 2026-10-07 18:50:52Z  23.3GiB   ok
shop-dev/orders-db  postgres  acme/shop/dev        2026-10-07 02:12:28Z  -                                            17.4MiB   ok
shop/catalog-db     postgres  acme/shop/prod       2026-10-07 02:07:41Z  2026-09-23 02:07:41Z → 2026-10-07 18:50:52Z  731.0MiB  ok
shop/orders-db      postgres  acme/shop/prod       2026-10-07 02:07:00Z  2026-09-23 02:07:00Z → 2026-10-07 18:50:52Z  9.6GiB    ok
web/wordpress       mysql     acme/marketing/prod  2026-10-07 02:09:44Z  2026-09-23 02:09:44Z → 2026-10-07 18:50:52Z  607.4MiB  ok

$ keeper diff 20261006T020700Z-bd79 20261007T020700Z-6da5
from  20261006T020700Z-bd79 (2026-10-06 02:07:00Z)
to    20261007T020700Z-6da5 (2026-10-07 02:07:00Z)

20261007 applied (was 20261006)
column orders.gift_note added
table audit_log +158,175 rows (+2%)
table order_items +62,923 rows (+1%)
table orders +15,655 rows (+1%)
table coupons −3,120 rows (−100%)
table customers +531 rows (+1%)

14 segments in between:
  00000001000000A100000000  18:51:32–19:20:32 · 800 commits · audit_log +3348 / ~1116 / −83 · order_items +1327 / ~442 / −33 · orders +330 / ~110 / −8 · customers +11 / ~3 / −0
  00000001000000A100000001  19:21:32–19:50:32 · 813 commits · audit_log +3352 / ~1116 / −83 · order_items +1328 / ~442 / −33 · orders +330 / ~110 / −8 · customers +13 / ~3 / −0
  00000001000000A100000002  19:51:32–20:20:32 · 826 commits · audit_log +3356 / ~1116 / −83 · order_items +1329 / ~442 / −33 · orders +330 / ~110 / −8 · customers +15 / ~3 / −0

$ keeper restore shop/orders-db --at 20261006T020700Z-bd79 --ttl 6h --reason "coupons truncated"
restore orders-db-sandbox-60414a15fc created (sandbox from 20261006T020700Z-bd79, 0 segments)
restore  shop/orders-db-sandbox-60414a15fc

$ keeper sandbox list
NAME      ENGINE    SOURCE            OWNER               PHASE         EXPIRES               IN-CLUSTER
sbx-7f3a  postgres  shop/orders-db    maria@acme.example  Ready         2026-10-08 00:37:32Z  keeper-sbx-sbx-7f3a.keeper-sandboxes.svc:5432
sbx-c210  mysql     billing/invoices  dev@acme.example    Provisioning  -

Output from the demo server in the repository: go run ./hack/demo, then point the CLI or a browser at it.

Restore anywhere, without touching production.

A restore is a Kubernetes resource like any other. Ask for a time or a backup ID and pick where it goes. Keeper plans the base backup and the changes to replay, then runs your checks before it calls the restore a success.

Small enough to forget it is there.

Keeper is one Go binary. The controller and the API only schedule and read; bytes move in short-lived Jobs that exit when they are done, so nothing heavy sits in your cluster between backups.

Working set reported by the kubelet in the k3d test cluster (12 databases) after the end-to-end and chaos suites; CPU at rest is a few millicores. Each database with point-in-time recovery also runs a streamer, about 70 MiB while it streams.

Know what changed between two versions.

Every backup carries an inventory of its tables, rows and sizes. Every change segment carries a summary of what it did. So before restoring anything, you can see which version still had the rows you lost.

• Diffs between any two backups. Schema changes, row counts and size per table.
• Change summaries per WAL or binlog segment. Inserts, updates, deletes and DDL per table, so a TRUNCATE at 22:48 is easy to find.
• Masked previews. Sample rows with the columns you list masked, readable with a catalog key that cannot decrypt the data itself.

Built for the night something goes wrong.

Data moves in Jobs, never in the controller.

The controller only schedules. Movers and streamers carry the bytes through one streaming pipeline straight into your bucket, and the restorer brings them back.

More than a nightly dump in a bucket.

From zero to restorable.

1. Install the chart

   CRDs, the controller, the API and console, RBAC, alerts and the dashboard.

   Copy

   helm install keeper charts/keeper -n keeper-system --create-namespace \
     --set image.repository=registry.example.com/keeper/keeper --set image.tag=v0.1.0 \
     --set 'targetNamespaces={team-a}'

2. Point it at a bucket and your keys

   Any S3-compatible store. Generate an age key with age-keygen and keep an offline copy.

   Copy

   apiVersion: keeper.republic.global/v1alpha1
   kind: BackupStore
   metadata: { name: main }
   spec:
     s3:
       endpoint: https://s3.example.com
       region: us-east-1
       bucket: db-backups
       credentialsSecret: { namespace: keeper-system, name: keeper-s3 }
     encryption:
       ageRecipients: [age1…]   # public key only; the private key stays offline

3. Declare a target next to the database

   Create the read-only users with the SQL in docs/sql/, then commit the target to git.

   Copy

   apiVersion: keeper.republic.global/v1alpha1
   kind: BackupTarget
   metadata: { name: app, namespace: team-a }
   spec:
     engine: postgres
     endpoint: { host: postgres, port: 5432 }
     databases: [app]
     policy: prod             # nightly fulls, 7-day point-in-time window
     credentials:
       secretRef: { name: keeper-backup-postgres }
       replicationSecretRef: { name: keeper-repl-postgres }

4. Restore something, on purpose

   The first full backup starts on its own. Then try the thing you hope you never need.

   Copy

   keeper targets
   keeper restore team-a/app --at 2026-10-07T09:41:27Z --wait
   keeper query <sandbox> -e "select count(*) from orders"

The full guide, every CRD field and the REST API are in the documentation.