Deploy One GitHub Repo to 2 Vercel Accounts Automatically

🚀 How to Deploy One GitHub Repository to Two Vercel Accounts Automatically

Imagine that you have one private GitHub repository, but you need the same application deployed to two completely separate Vercel Accounts.

Perhaps one belongs to you and another belongs to a client. Or maybe you want the same codebase available in two independent environments.

Doing this manually every time you make a change quickly becomes repetitive.

A better approach is to let GitHub Actions handle the deployment automatically using separate Vercel Tokens.

The workflow then becomes:

Once configured correctly, a normal Git push can trigger both deployments automatically.

🔑 What Is a Vercel Token?

A Vercel Token is an authentication credential that allows tools such as the Vercel CLI to access Vercel on your behalf.

If you have two separate Vercel Accounts, you can create a separate token for each one.

For example:

GitHub Actions can then use these secrets to authenticate each deployment.

⚠️ Important: Never place Vercel Tokens directly inside your source code. Treat them like passwords and store them as GitHub Actions Secrets.

🛠️ Step 1: Create Tokens for Both Vercel Accounts

Log in to Vercel Account A.

Go to:

Account Settings → Tokens → Create Token

You can give it a descriptive name such as:

Generate the token and store it securely.

Then repeat the process with Account B:

You now have separate credentials for both deployment targets.

🔐 Step 2: Store Both Tokens in GitHub Secrets

Open your private GitHub repository.

Go to:

Settings → Secrets and variables → Actions

Select New repository secret.

Create the first secret:

Then create:

GitHub Actions can now access these credentials without exposing the actual token inside your workflow code.

⚙️ Step 3: Create the GitHub Actions Workflow

Inside your project, create:

A basic workflow can look like this:

The first deployment authenticates with Account A's token.

The second uses Account B's token.

🚀 Step 4: Push Your Code

Now make a normal Git push:

The moment GitHub receives the push, the workflow starts automatically.

GitHub Actions runs the deployment steps one after another and sends the application to both Vercel deployment targets.

You no longer need to open both Vercel dashboards and manually trigger deployments.

📊 The Complete Deployment Architecture

This is a simple example of CI/CD automation.

Your Git repository becomes the source of truth, while GitHub Actions handles the deployment workflow.

💡 One Important Detail: Project Scope Matters

There's an important detail that shouldn't be overlooked.

Using two different Vercel Tokens does not automatically guarantee that every deployment will land in the correct existing Vercel Project.

Vercel also has Project and Team/Account Scope concepts.

If Account A and Account B contain separate Vercel Projects, each deployment needs to be associated with the correct project and scope.

The architecture should therefore look something like:

This becomes especially important when the two deployments use different domains, environment variables, or production configurations.

🔒 Keep Your Tokens Secure

Vercel Tokens should be treated as sensitive credentials.

Never:

❌ Hard-code them in source code.

❌ Commit them to .env files in Git.

❌ Put them inside README files.

❌ Share them through screenshots or chat.

Instead:

✅ Store them in GitHub Secrets.

If a token is accidentally exposed, revoke it immediately and generate a replacement.

🎯 Who Can Benefit From This Setup?

This approach can be useful for:

• Developers managing multiple Vercel Accounts
• Agencies working with client projects
• Teams maintaining independent deployments
• Developers using one private repository for multiple environments
• Businesses that need separate production deployments
• Teams building automated CI/CD pipelines

⚡ Quick Summary

✅ Final Thoughts

Deploying one GitHub repository to multiple Vercel Accounts doesn't have to mean managing every deployment manually.

With GitHub Actions and separate Vercel Tokens, the process can become part of your normal Git workflow.

The basic architecture is simple:

GitHub → GitHub Actions → Vercel Account A + Vercel Account B

The important part is keeping credentials secure and making sure each deployment is correctly associated with its intended Vercel Project and Account scope.

Once everything is configured properly, your workflow becomes much cleaner:

Write code → commit → push → deployments happen automatically.

That's the real advantage of CI/CD—not simply faster deployments, but removing repetitive deployment work from the development process.

---ends here---