Deploy keys, SSH and tokens on GitHub: which credential to use for deployment
Published on 2026-10-26 by frfrand
Secure server access to GitHub repositories without sharing accounts
For a VPS to download a private repository, you shouldn't copy your personal password to the server. GitHub offers different access mechanisms: a deploy key, a token, or a GitHub App. The best option depends on the scope and automation.
The idea is to use it to solve a real problem, not to memorize commands because they look good in a screenshot. Let's go with the essentials, a work example, and the errors it's best to avoid.
What deploy keys, SSH, and tokens do and when they are useful
An SSH deploy key is usually associated with a specific repository and can be configured as read-only. Personal tokens have configurable permissions and expirations, but it's best to avoid unnecessary scopes. GitHub Apps can issue short-lived credentials with granularity more suitable for large integrations.
If you're learning, try it first in a test repository or environment. If you manage production, document the state before executing anything that alters files, history, or data. This allows you to understand what changed and recover if you make a mistake.
Example to copy and understand
# En el VPS, crear una clave específica de despliegue
ssh-keygen -t ed25519 -f ~/.ssh/deploy_proyecto -C 'deploy-proyecto'
# Ver sólo la CLAVE PUBLICA
cat ~/.ssh/deploy_proyecto.pub
# Verificar GitHub al conectar
ssh -T git@github.comDon't copy the final command without checking the previous state. Branch names, host, user, or paths are examples; replace them with those of your project. Some commands modify files or make requests that can write data.
How I would use it step by step
- Step 1. Create a separate identity for deployment, do not reuse your personal SSH key.
- Step 2. Add only the public key to the repository as a read-only deploy key, when the flow allows it.
- Step 3. Verify GitHub's host fingerprint with official information before accepting the first access.
- Step 4. Store the private key with strict permissions and do not copy it inside Git.
- Step 5. Document how to revoke access when the team or server changes.
Stop after each step and check the result. If something fails, note the exact message before changing strategy. Jumping between five random solutions usually makes it harder to find the real cause.
A case that could happen to you working with clients
An agency manages private repositories for different clients. With credentials separated by project, a compromised server does not need to have read access to all the agency's repositories.
The goal is not for it to "work once," but for you to be able to explain how you repeat it without compromising another application. If there are client data or credentials, work with separate tests and minimal accesses.
The mistake I see most often
Never paste a private key into an incident or pass it to an AI or collaborator without controls. Credentials can also be exposed in CI logs; avoid commands that print secrets.
A simple rule: if you can't explain what the command will do to your code or server, check its official help first. That way you avoid confusing a quick fix with a new problem.
Where does ArduMaker fit in?
At ArduMaker, Git integrations for deployment must use minimal permissions per project and Company. Choose separate keys to prevent one client's VPS from accessing another client's code.
For example, you can deploy from a Git repository to a VPS, associate an HTTPS domain, and manage services and databases from the same environment. The panel reduces repetitive infrastructure tasks, but does not replace Git, testing, or project permission review.
Quick questions before applying it
Does this change production? It depends on where you run the action. Test locally first, identify the affected commit or service, and prepare a recovery plan.
How do I verify it went well? Don't settle for the absence of error messages: check the status, run a functional test, and review the corresponding logs or history.
Is it worth automating? If it's repeatable and has verifiable results, yes. But automation should fail clearly and not hide errors or credentials.
To expand
Summary: the useful tool is not the one with the most options, but the one that allows you to understand what changed, verify it, and keep working without surprises.