Updated · 2026-06-27

Recipe: Postgres with backups

The postgres-18 image boots PostgreSQL 18 with TLS and credentials at /root/.postgres-credentials. Every VM is snapshotted daily, with a rolling retention (5 by default, set by your account entitlements). Take an on-demand backup before a migration; restore in place if it goes wrong.

Self-host PostgreSQL on a VM, with point-in-time recovery built in.

One prompt

spin up a postgres for staging

Your agent chains:

  1. create_vm with image: postgres-18, named e.g. db — PostgreSQL 18 listening on :5432 with TLS. Generated credentials land at /root/.postgres-credentials (read them with exec cat /root/.postgres-credentials).

Connecting

  • From another VM in the same project (the common case): reach it privately by name — postgresql://postgres:<pw>@db:5432/postgres. No public port; same-project VMs share a private network (Project networking).
  • From outside Superjolt: open_port 5432 with protocol: tcp for a stable public endpoint like vm-abc123.superjolt.host:30432. Leave it closed if you don’t need external access.

Backups — automatic + on-demand

  • Automatic: every VM is snapshotted daily, with a rolling retention (5 by default, set by your account entitlements). Nothing to configure. (There is no schedule-attach step — daily DR is on by default for every VM.)
  • On-demand: before a risky migration, have your agent call create_backup for a kind=on_demand snapshot that persists until you delete it.
back up the postgres vm before I run this migration

Restore

If a migration goes wrong:

restore vm-abc123 from the backup taken before the migration

Your agent lists snapshots with list_backups (each row shows kind, takenAt, sizeBytes) and calls restore_vm_from_backup. This replaces the rootfs and reboots the VM — same VM id, IP, and ports; only the disk goes back in time. Anything written since that backup is lost.

Notes