Two commands, and the second is the first plus the binary. They share one implementation, so they can never drift into destroying different things.

Backups are never deleted. Not by reset, not by uninstall, not ever. A registry is a minute of typing and a PostgreSQL is a download; a dump that is gone is gone.

It asks for an administrator at the door

A reset takes the background service off the machine, and changing what a machine runs at boot needs more than an ordinary account. So that is the first thing either command checks — before the survey, before the list, before the name is typed — and a run that cannot do it stops while the machine is still whole rather than deleting the cluster and then discovering it cannot finish.

nothing has been changed

$ sloop reseterror: changing what this machine runs at boot needs more than this account has, and  systemd will refuse  hint: run it again with sudo. Nothing has been changed by this run.

Run it again from sudo and it carries on. Only a machine with a service registered needs this: there is nothing else in a reset that an ordinary account cannot do, because everything else sloop put here went under your own profile in the first place.

What goes, and what stays

sloop reset surveys the machine before it does anything to it, and prints both columns. The last thing you read before a database stops existing should be a list of what is going, not a yes-or-no.

This will remove

sloop_database
The registry, the schedules, the service’s readings and the vault. All of it.
sloop_db_admin
The role that owned it, dropped in the same run.
server.toml
The record that said which PostgreSQL was sloop’s, and on what port.
projects/ and locks/
Where projects were registered, and any lockfile left behind by a run.
The PostgreSQL — sometimes
Only if sloop installed it. The next section is the whole of that question.
The background service
Taken off the machine before anything else goes, because it wakes on a timer and opens the store every round.
Every server sloop installed
Each one stopped first, then its directory — a running server holds its own files open, on Windows especially.
Every password sloop filed
Its own superuser and role, the servers it installed, your registered databases and the SSH passphrases beside them — out of the keyring, out of the encrypted file.

This will keep

Every backup
Not by reset, not by uninstall, not ever. They are the one thing here that cannot be made again.
Every other database
On a PostgreSQL sloop did not install, only sloop’s own two objects go.
Every other role
Two statements run, and both name something sloop created.
Your databases themselves
Registering one never touched it, and forgetting all of them does not either.
Passwords sloop never held
A ${VAR} route or a --password-command points at a secret somebody else keeps. There is no copy here to remove, and it says so rather than pretending.

Which is exactly what it prints, and it prints it before it asks:

said first, not after

$ sloop resetThis will remove:  Database sloop_database and its role, on the PostgreSQL already at port 5452  that server was here before sloop and stays exactly as it is — no other  database on it is touched  Gone /home/you/.sloop/server.toml  Gone /home/you/.sloop/locks  Password postgres, the superuser of sloop's PostgreSQL  Password sloop_db_admin, which owns sloop's own database  Password the password for shop  these are forgotten wherever this machine keeps them, so the next `sloop setup`  starts with nothing left over 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

That run was a scheduled one — no terminal, so nothing to type at, so it stopped at 2 and named the flag. The automation page has the rule it is following.

One question decides how much goes

Who installed the PostgreSQL. sloop wrote the answer down at setup — origin in server.toml — and reset reads it rather than guessing.

origin = sloop

sloop downloaded it and installed it under ~/.sloop, so it is sloop's to take away. The cluster and its binaries go, in one directory. sloop setup downloads and installs again.

sloop brought it

This 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/projects  Gone /home/you/.sloop/locks  Gone /home/you/.sloop/postgres

origin = machine

The PostgreSQL was already here and sloop was a guest on it. Two statements run — DROP DATABASE and DROP ROLE — and both name something sloop created. Not the server, not another database, not another role.

sloop was a guest

This will remove:  Database sloop_database and its role, on the PostgreSQL already at port 5452  that server was here before sloop and stays exactly as it is — no other  database on it is touched  Gone /home/you/.sloop/server.toml  Gone /home/you/.sloop/locks

That second claim is the one worth testing rather than believing, so here it is on a server carrying two other databases and a role that was never sloop's:

before, and after

# before — the server sloop was a guest on$ psql -p 5452 -U postgres -c "select datname from pg_database" analytics payments postgres sloop_database template0 template1 $ sloop reset --confirm sloop_database  Dropped sloop_database and sloop_db_admin # after$ psql -p 5452 -U postgres -c "select datname from pg_database" analytics payments postgres template0 template1 $ psql -p 5452 -U postgres -c "select rolname from pg_roles ..." postgres reporting   ← still there, and it never was sloop’s

And in the store, one directory is left standing:

what is left

$ ls /home/you/.sloopbackups   ← and nothing else $ sloop resetthere is nothing to reset — this machine has no sloop state on it

The name, typed out

This destroys a database. So it is the strongest form of the rule: sloop_database, typed out, or --confirm sloop_database for a run with nobody there. -y will not do it and --force will not do it.

A typo stops the run before a socket is opened:

caught early

$ sloop reset --confirm sloop_databse# …the same announcement, and then:error: --confirm says sloop_databse, and the database sloop keeps its state in is  sloop_database  hint: nothing was contacted and nothing was changed. The two have to match  exactly

The one thing that can still be lost

Backups survive reset. Being able to read them may not, and this is the whole reason the page exists.

An encrypted backup is readable only with its private key. On a machine with a working keyring that key lives in the keyring, which reset does not touch. But on a machine with no keyring — a headless Linux box — the key lives in the Argon2id vault, and the vault is inside sloop_database, which is precisely what reset destroys.

Run this before you run reset

sloop key export — and keep the line it prints somewhere sloop cannot reach. Without it, every encrypted backup this machine took becomes a file nobody can open. There is no recovery, no reset and nobody to ask.

Reset says so itself, in the block above, before the name is typed rather than after. It is the only warning on this page that describes something irreversible that reset does not do — it describes what you will have done by running it unprepared.

uninstall is reset plus the binary

Everything above, and then sloop itself: the directory the installer made and the PATH entry that points at it.

and then it is gone

$ sloop uninstall --confirm sloop_database# …the same announcement, and the same two columns, and then:  Dropped sloop_database and sloop_db_admin  Removed /home/you/.sloop/server.toml  Removed /home/you/.local/bin/sloop  PATH block removed from /home/you/.bashrc  open shells still have the old PATH; the next one will not Done. sloop is off this machine.

The open shell is the one thing it cannot fix. A shell read its environment when it started and keeps it; sloop will still resolve in the window you ran this in until you open a new one. It says so rather than leaving you to notice.

The other way to take the binary off

If the binary is gone, or broken, or was never on PATH, there is a script — the counterpart of the one that installed it:

$ curl -fsSL https://dbsloop.github.io/uninstall.sh | sh

It will not quietly strand sloop's state behind a binary that could still remove it. A script cannot know which PostgreSQL was sloop's, so rather than guessing it stops and names both ways forward — the same shape rule 4 takes in the CLI, in a file with no terminal at all:

it stops

$ curl -fsSL https://dbsloop.github.io/uninstall.sh | sh   sloop uninstall stopped.   sloop still has state on this machine, and /home/you/.local/bin/sloop can  still remove it:     /home/you/.sloop     Run this first -- it removes the PostgreSQL sloop installed, its database,    its role and its registry, then the binary and the PATH entry:         /home/you/.local/bin/sloop uninstall     Or leave that state where it is and take only the binary:         curl -fsSL https://dbsloop.github.io/uninstall.sh | sh -s -- --binary-only     Backups are not deleted by either.

Told which you meant, it takes the binary and leaves the rest:

only the binary

$ curl -fsSL https://dbsloop.github.io/uninstall.sh | sh -s -- --binary-only  removed /home/you/.local/bin/sloop  removed sloop's PATH block from /home/you/.bashrc sloop is off this machine.Open shells still have the old PATH; the next one will not.

The PATH block comes out of every startup file that could be holding one — .bashrc, .bash_profile, .profile, .zshrc, .kshrc and fish's conf.d — not only the current shell's. Somebody who installed under bash and has since moved to zsh has the block in .bashrc, and looking at $SHELL alone would leave it there pointing at a binary that no longer exists.

Coming back

sloop setup, and the machine is ready again. What it cannot restore is what was in the database it destroyed: the registry, the schedules and the service's history are gone, and the databases they described have to be registered again.

The backups are still on disk with their manifests, so restoring one needs the database registered again and — if it was encrypted — the key you exported.