How to share GitHub credentials with an engineering team safely

Quick answer. To share GitHub credentials with an engineering team safely: (1) use GitHub’s built-in team-and-org permissions for individual repo access (each engineer signs in with their own GitHub account), (2) reserve the org-owner account for org-level admin work and store its password + recovery codes in a zero-knowledge shared vault for two founders only, (3) for CI/CD or scripts, create scoped fine-grained Personal Access Tokens (or GitHub Apps) and store them in the vault, (4) on offboarding, remove their GitHub org membership AND revoke any PATs they generated. Vault distributes credentials safely; GitHub’s permission model handles authorization. Free vault at LitePassword.

---

What you should NOT share

• Org-owner GitHub account credentials. This account can delete the org, transfer repos, billing changes. Reserve for two founders. Store password + MFA backup codes in a shared vault for those two, lock it with a hardware key.
• Personal GitHub accounts. Each engineer signs in with their own. You add them to the org by username, not by giving them shared credentials.
• Classic PATs with broad scopes. Classic PATs have repo, workflow, admin:org — far too broad. Use fine-grained PATs (GitHub’s newer model) with per-repo and per-permission scoping.

What you DO share, and how

Org owner credentials (limited circulation)

Only the founders or designated org administrators need org-owner access. The credentials live in a zero-knowledge shared vault — “Production credentials” or “Founders only”.

Pattern:

1. Set up the org-owner account with a hardware MFA key (YubiKey).
2. Store the password + backup recovery codes in the vault as a Login secret.
3. Grant vault access to 2 founders.
4. Don’t use this account for daily work — only for org-admin actions (adding teams, billing, transferring repos).

Fine-grained PATs for automation

For CI/CD pipelines, deploy scripts, or bots:

1. Create a fine-grained PAT (Settings → Developer settings → Personal access tokens → Fine-grained tokens).
2. Scope to specific repositories + specific permissions (e.g., Read code, Write workflow).
3. Set expiration (90 days max).
4. Store in the LitePassword vault as a Password secret. Name: “GitHub PAT — deploy bot (repo: acme/api)”.
5. Grant vault access to engineers who manage that pipeline.

Rotate every 90 days. Cheap, closes the slow-leak window.

Repository-level deploy keys (read or read-write per repo)

Deploy keys are SSH keys scoped to one repo. They’re an alternative to PATs for use cases like Git pulls from a server.

1. Generate an SSH keypair on the server that needs the key.
2. Add the public key to the repo’s Deploy Keys settings.
3. Store the private key in the LitePassword vault as a Secure Note. Label clearly which repo.
4. Grant vault access to engineers who maintain that server.

Deploy keys are per-repo — much tighter scope than an org-wide PAT.

The right way to onboard a new engineer

1. They sign up to GitHub with their personal email.
2. You add them to the org by username + team.
3. You assign them the right team(s) — engineering, devops, etc. — which already have repo-level permissions configured.
4. Their default workflow: clone repos with their personal GitHub credentials, no shared accounts involved.
5. Optionally: if they manage any CI/CD pipelines, grant LitePassword vault access to the PAT/deploy-key vault.

The right way to offboard

Step 1 — Remove from GitHub org. GitHub → org settings → People → Remove from organization. They lose access to org repos immediately.

Step 2 — Revoke vault access. LitePassword Users page → Revoke Access. Their cached PATs and deploy keys become undecryptable.

Step 3 — Rotate every PAT or deploy key they touched. This is the step most teams forget. Even though they can’t pull the key from the vault anymore, they might have copied it to their local laptop a month ago. Rotate every credential they ever pulled.

For PATs: regenerate in GitHub. For deploy keys: rotate the keypair on the server.

A note on SSH keys

Personal SSH keys (the keypair on an engineer’s laptop they use to push to GitHub) are not shared credentials — they’re per-engineer. Don’t try to store these in a shared vault. Each engineer manages their own keypair and adds the public key to their GitHub account.

What you might share via the vault: passphrases for shared deploy keys (if someone needs to import one onto a new server), or backup copies of less-personal keys (e.g., a build-machine SSH key that 3 engineers need).

Summary

1. Org owner account — 2 founders only, vault-stored, hardware MFA, daily-use forbidden.
2. Per-engineer access — via GitHub org + teams, no shared accounts.
3. PATs and deploy keys — fine-grained, vault-stored, rotate 90-day.
4. Offboarding — remove from GitHub org + revoke vault + rotate touched credentials.

Create your free LitePassword vault →