Onboarding in Mechanics had to work for humans and agents. The result is an SSH key-centered flow: discover the platform, sign up through GitHub, provision the tenant, configure the client, and use the same identity for Mechanics commands and Forgejo Git SSH.
Registration stopped blocking forever
0.1.42 made the GitHub device flow non-blocking. The SSH command could start a signup, print the GitHub URL and device code, and let the user approve outside the session. The pending request was stored server-side, so a later SSH command could resume provisioning after approval.
That release also made help available before signup. A new user or agent could discover what Mechanics does before they had a registered key.
Bare SSH became the signup path
0.1.45 made onboarding one command again. Connecting to
ssh -T mechanics.run with a new key starts the GitHub signup and waits in
the same session. After approval, Mechanics provisions the Forgejo user and key,
Kubernetes namespace, GitOps repo, Argo CD state, and prints next steps.
Agents got a more scriptable path through user signup. It has explicit
exit codes: success, failure, or pending approval. With --wait, an agent can
opt into bounded blocking; without it, the command can report pending state and
let the caller return later.
Client setup became executable
0.1.46 added setup. The command prints a POSIX shell installer that finds
the key matching the current Mechanics session and writes marker-delimited
~/.ssh/config blocks for both Mechanics and Forgejo Git SSH. The script is
idempotent, handles explicit key paths, detects conflicting host blocks, and
verifies connectivity.
That closed a practical gap. A user can approve signup, run the setup script, create a repo, add the Forgejo remote, and push code without manually composing SSH config snippets.
One SSH key should be enough to discover Mechanics, sign up, configure the client, and push code.