0.1.44 put Git SSH behind the same platform front door. Mechanics already used
SSH for its command surface; this release made git@ sessions flow through
Mechanics and then into Forgejo.
Git traffic takes a separate path
When a session authenticates as the git user, Mechanics bypasses the
command tree. Instead, it validates the offered key against Forgejo's key
database and relays the Git command to Forgejo's serv path. Forgejo remains
the repository authorization authority.
That distinction is important: Mechanics does not invent a second Git permission model. It fronts the connection, but Forgejo still decides whether the key can clone, fetch, or push the requested repository.
The user experience got cleaner
Git clients are sensitive to unexpected output, so git@ sessions receive no
Mechanics command banner. A clone like
git clone ssh://git@forgejo.mechanics.run/<user>/<repo>.git behaves like
a Git operation, not like an interactive control-plane session.
The same release moved the packaged service to port 22 by default. The systemd unit grants the unprivileged service the capability needed to bind the standard SSH port, so users no longer need to remember a nonstandard port in the common case.
Why it matters
Mechanics wants one identity path for the software delivery loop. The same SSH key can run platform commands and move Git data, but the authorization checks stay scoped to the system responsible for each action. Mechanics handles the control plane; Forgejo handles repositories.
Git SSH behind Mechanics makes the platform feel unified without replacing Forgejo's repository authority.