sloop keeps its state in a database rather than a file, and the reason is the background service: two processes writing the same registry at the same time is a problem a file format solves badly and a database solved decades ago. Schedules, run history and per-day activity are all things you want to query, which settles the rest of the argument.

Showing Linux. Every path on this page follows it.

Opening it yourself

Nothing about it is hidden. It is an ordinary PostgreSQL on an ordinary port, and sloop will tell you exactly how to reach it:

the whole connection

$ sloop server connection sloop's own database answering  Host      127.0.0.1  Port      5433  Database  sloop_database  User      sloop_db_admin  Password  kept in the OS keyring  URL       postgres://sloop_db_admin@127.0.0.1:5433/sloop_database   Open it with psql, DataGrip, or anything else that speaks PostgreSQL.  `sloop server connection --show-password` prints the password on this terminal.

psql, DataGrip, TablePlus, anything that speaks the protocol. --show-password adds the password, and it only works on a terminal — there is no way to get it into a pipe, which is the point.

And it still holds no passwords. Not for your databases — the registry stores which of the four routes to take and the value is fetched when it is needed. Opening this database tells you everything about what sloop knows and nothing you could use to connect to anything else.

What is in it

Twelve tables at schema version 9, read from the database rather than from the source:

registered_database: Every database you have registered — and its password route, never a password.
project: The project registries, by directory, so -C acme-api can find one by name.
engine: Which engine each registration speaks.
backup_key: The public half of the age keypair, per registry. The private half is in the keyring.
backup_run: Every backup taken: when, how big, how long, and whether it verified.
restore_run: The same for every restore.
monitored_database: What the background service is attached to, and what it is scheduled to do.
service: The service itself — when it last read the list, and when it last ran.
activity_hour: Rows in and rows out per database per UTC day.
bandwidth_day: Bytes sloop itself moved. Not bytes on the wire — no engine reports those.
sealed_vault: The encrypted password file, for a machine with no keyring running.
schema_migration: Which version of its own schema sloop has applied. Nine, at 0.1.5.

sloop setup

One command, run once. It finds a PostgreSQL 18 on the machine or offers to get one, makes sloop's database and role, and applies the schema. On a machine where all of that is already true it says so and changes nothing:

already set up

$ sloop setup  Already there sloop_databaseUsing: sloop's own cluster  postgres://postgres@127.0.0.1:5433/postgres  binaries at /home/you/.sloop/postgres/18/bin  cluster at /home/you/.sloop/postgres/dataState: postgres://sloop_db_admin@127.0.0.1:5433/sloop_database  owned by sloop_db_admin, whose password is kept in the OS keyring  Schema already at version 9 in sloop_database

Getting started has the other case — a first run on a machine with no PostgreSQL 18, where it describes what it would download and asks before doing it.

For a run with nobody to ask, four flags: --superuser-password-command and --superuser-password-stdin for the password of a PostgreSQL already on the machine, and --db-password-command and --db-password-stdin for the one to give sloop's own user. Leave the second pair out and sloop generates one — which is the better answer, because a generated password is one nobody has ever seen in a shell.

Nothing here needs sudo

Everything sloop installs goes under /home/you/.sloop — the cluster, its data directory, the binaries. Nothing is put in /usr/local, and no part of setup asks to be elevated.

That is also why the port is 5433 rather than 5432: a PostgreSQL already serving on the default port belongs to somebody else, and sloop builds its own cluster beside it rather than touching it.

Servers sloop installed for you

server install is a different job from setup, and the difference is whose databases end up on the server. setup prepares the one sloop keeps its own state in. server install installs one for your databases — a PostgreSQL, MySQL or MariaDB to develop against, under the same store and with the same no-administrator rule.

none here

$ sloop server listNone: sloop has not installed a database server on this machine.  `sloop server install` walks through engine, version and one confirmation.

server list lists those, not sloop's own — which is why the machine above says None while a sloop PostgreSQL is running on it. --version picks one; left out, install lists what is available.

origin, and how much reset destroys

server.toml records one thing that matters more than the rest: whether sloop installed that PostgreSQL or found it.

origin = "sloop"

sloop created the cluster, under its own store, on a port it chose.

What reset does

Removes it. It was sloop's to make, so it is sloop's to take away — and sloop setup builds it again.

origin = "machine"

A PostgreSQL 18 that was already here. sloop is a guest on it.

What reset does

Leaves it alone entirely. sloop never starts, stops or reconfigures somebody else's server.

reset says which of those it is looking at, and then names every file it will remove one at a time rather than sweeping the store:

a rehearsal

$ sloop reset --dry-runThis will remove:  PostgreSQL the whole server sloop installed, on port 5433  sloop installed it, so sloop takes it away. `sloop setup` downloads and installs it again.  Gone /home/you/.sloop/server.toml  Gone /home/you/.sloop/registry.toml  Gone /home/you/.sloop/projects  Gone /home/you/.sloop/locks  Gone /home/you/.sloop/postgres This will keep:  Backups /home/you/.sloop/backups  a backup is the one thing here that cannot be made again, so reset never deletes one  an encrypted backup still needs its key. If the private key was never exported and  this machine keeps secrets in the encrypted file, it goes with the database and those  backups become unreadable. error: resetting sloop needs its name typed, and there is no terminal to type at  hint: pass --confirm sloop_database to say it up front

Backups are never removed. Not by reset, not by uninstall, not ever — a registry is a minute of typing and a PostgreSQL is a download, and a dump that is gone is gone. And note the sentence under it: reset can take the key with the database if the private half was never exported, which would leave backups that exist and cannot be opened. Export the key before you reset anything.

Every flag on this page is on the command reference, generated from --help.