Deploy keys, GitHub Apps or machine users: which for automation?

For most automation that needs repository access, GitHub recommends a GitHub App over a deploy key or a machine user. Apps give short-lived, repository-scoped tokens that are not tied to a person. Deploy keys remain fine for a single read-only server pull, if you accept their limits.

Deploy keys

A deploy key is an SSH key attached to one repository. GitHub's documentation notes these properties:

• Access is scoped to a single repository, so each repository needs its own key pair.
• Keys are read-only by default, with write access as an option.
• Keys usually have no passphrase, so whoever compromises the server can use them.
• Keys have no expiry date.
• Keys are not tied to organization membership, so they keep working if their creator leaves.

A write-enabled deploy key can do what a collaborator or admin could do in that repository, so treat it as a real credential.

Machine users

A machine user is a separate account used only by automation, with an SSH key, added as a collaborator or team member. GitHub lists two drawbacks: only organizations can limit a machine user to read-only, since personal repositories always grant read and write, and the keys usually have no passphrase.

It also adds an account to manage, with its own password, two-factor setup and offboarding story.

GitHub App installation tokens

Apps produce installation access tokens. GitHub describes them as scoped to chosen repositories with fine-grained permissions and not tied to any user. The costs are setup effort, since you must create the App, and the one hour token lifetime, so your code has to request new tokens.

How to choose

1. One server pulling one repository, read only: a deploy key is acceptable. Record who owns it and when it was created.
2. Several repositories, or any write access: use an App.
3. A tool that only supports user credentials: a machine user with the narrowest role and two-factor on, as a last resort.

SSH agent forwarding is a fourth option GitHub lists, where a deployment borrows a developer's local keys. It cannot support unattended jobs, so it rarely fits automation.

Keep an inventory

Whichever you pick, list every key and automation account in a sheet with an owner and a review date. Keys with no expiry are the ones that get forgotten. Add the review to your quarterly access check.

One more habit helps with all three: give each automation its own identity. When a single shared key serves ten jobs, you cannot tell which job leaked it, and you cannot rotate it without breaking everything at once. Separate credentials per job turn a rotation into a small, boring change. Name each credential after the job it serves, and put the owning team in the description field so that a reviewer six months from now can decide quickly whether to keep it.

Quick check

Safeguard discovers repositories and assets in your estate, which helps when you are building the inventory of what automation can reach.

Sources

• Managing deploy keys, GitHub Docs

Last reviewed: 19 October 2026.