Your key

Pupitre works with ed25519 keys it generates itself. The private halves never leave your computer. Everything the app and the agent do afterwards rests on that one fact.

Which keys exist

• One key for this computer, made the first time it is needed. Its public half goes up to the platform, which hands it to the agents of the servers your account may open — so a machine your organisation assigns to you needs no key of its own.
• One key per server you add yourself, generated when you add it. You can import a key you already have instead; it is copied into the app’s folder rather than referenced where it sits, so deleting the server really takes the key with it.
• None at all for a host you already declared in your ~/.ssh/config and asked the app to use as it is. The app then writes nothing anywhere.

Where the private halves live

In the app’s own data folder, in mode 0600, next to the SSH configuration it passes to ssh with -F. Your ~/.ssh/config is read — to offer the hosts already declared there — and never written.

System	Folder
macOS	~/Library/Application Support/Pupitre
Windows	%APPDATA%\Pupitre
Linux	~/.config/Pupitre

The keys folder holds device for this computer and one srv-… per server, each with its .pub beside it. The ssh/config file says which is which. If you want your terminal, your editor or a coding agent to use the same key, point it at that path: see your own client.

What goes to the server

The public half, and only the public half, lands in authorized_keys for the dev user. The core.system module copies the unrestricted keys already present on root, so a key opens dev before hardening closes root. That order matters: it is what stops an install from locking you out of your own machine.

What the platform sees

If you sign in, the platform stores the public half so it can hand it to the agents of servers you own. It never sees a private half, and it never connects to your server: the agent pulls what it needs over outbound HTTPS.

One key per device

Each computer you install the app on has its own key. That is what makes revocation useful: removing a device removes one key, and the other machines you work from keep working. A laptop that is lost is a key you revoke, not a password you rotate everywhere. It also means a client you pointed at that key loses the server at the same moment — which is the behaviour you want.

If you lose the key

You lose the app’s way in, not the machine. Connect with whatever other access you kept — your host’s console, another key already in authorized_keys — and add the new public key by hand. The app shows it on the server screen so you can paste it.