DEV Community

Udara Dananjaya
Udara Dananjaya

Posted on

🔐 How to Use Deploy Keys with GitHub for Secure Automation

Whether you're building a CI/CD pipeline, automating deployments, or giving a remote server access to a private repository, Deploy Keys offer a secure, streamlined solution. Instead of sharing personal credentials or access tokens, you can assign a unique SSH key to a specific repository — and GitHub will only allow that key to interact with that one repo.

Let’s walk through how to set it up and why you might want to.

🧠 What is a Deploy Key?

A Deploy Key is an SSH key (public/private key pair) that gives access to a single GitHub repository. It’s not tied to a GitHub user — just the repository.

This makes deploy keys perfect for:

  • Read-only access from build servers or scripts
  • Secure write access for auto-deployment
  • Isolated access that can’t affect other projects

🛠️ Step 1: Generate an SSH Key Pair

Start by creating a new SSH key pair. It’s best to use a new key just for this purpose:

ssh-keygen -t ed25519 -C "deploy-key" -f deploy_key
Enter fullscreen mode Exit fullscreen mode
  • -f deploy_key saves the private key as deploy_key and the public key as deploy_key.pub
  • When prompted for a passphrase, leave it empty (for automation)

Make sure you keep the private key safe and secure — this is the key that will be used by your deployment environment or server.

📤 Step 2: Add the Public Key to GitHub

  1. Go to your GitHub repository
  2. Navigate to Settings → Deploy Keys
  3. Click “Add deploy key”
  4. Give it a name (e.g., CI/CD Server, Deployment Key)
  5. Paste the contents of your deploy_key.pub file
  6. ✅ Check “Allow write access” if the key needs to push code (otherwise leave it unchecked for read-only)

Click Add Key, and you're done with the GitHub side.

🔧 Step 3: Use the Private Key for Git Access

On your server, deployment script, or CI environment, make sure the private key is available and used when interacting with Git.

There are a few ways to do this:

🔹 Option A: One-Time Use with Git 

GIT_SSH_COMMAND='ssh -i /path/to/deploy_key' git clone git@github.com:your-org/your-repo.git
Enter fullscreen mode Exit fullscreen mode

This command tells Git to use your specific SSH key when cloning.

Note: If you're using Git Bash or a Unix-like shell, use forward slashes in paths.

🔹 Option B: Configure a Host Alias with SSH

Create or edit your SSH config file (~/.ssh/config) like this:

Host github-deploy
    HostName github.com
    User git
    IdentityFile /path/to/deploy_key
    IdentitiesOnly yes
Enter fullscreen mode Exit fullscreen mode

Now you can clone using:

git clone github-deploy:your-org/your-repo.git
Enter fullscreen mode Exit fullscreen mode

This keeps your automation scripts cleaner and reusable.

🔹 Option C: Global Git Config (Alternative)

You can also tell Git to always use the key by setting:

git config --global core.sshCommand "ssh -i /path/to/deploy_key"
Enter fullscreen mode Exit fullscreen mode

This sets the SSH key for all Git commands run in that environment.

🔐 Read-Only vs Write Access

By default, deploy keys are read-only, which is ideal for cloning and fetching code. But if your use case involves pushing code — like automated deployments, GitOps workflows, or update bots — you can enable write access when adding the key.

🔒 Only grant write access when absolutely necessary.

💡 Best Practices

  • Use a separate deploy key per repository
  • Never reuse a deploy key across multiple repos
  • Don’t share deploy keys with people — they’re for systems
  • For multiple repositories, consider using a machine user with a Personal Access Token instead

✅ Summary

Deploy keys offer a clean, secure way to grant SSH access to a GitHub repo without giving away personal credentials or full user access. Whether you’re setting up continuous deployment, pulling code onto a server, or triggering builds from a CI system — deploy keys are the right tool for the job.

They’re easy to create, scoped to a single repo, and flexible enough for both read and write access. Just generate a key, upload the public part to GitHub, and start automating with confidence.

Top comments (0)