How to use Depot as an alternative to GitHub

Depot Code and Depot CI give you an alternative to GitHub for source control hosting and CI. You keep using Git and GitHub Actions YAML. Depot hosts your repositories, accepts your pushes, and runs your workflows on its own infrastructure.

You can create a standalone repository hosted entirely on Depot, or mirror an existing GitHub repository. Both accept pushes directly to Depot. If GitHub goes down, you can keep pushing to a mirror and Depot syncs those changes back to GitHub in the background once it's available again.

This guide walks through both setups and runs a test workflow from a Depot Code push. It covers moving Git hosting and CI; GitHub issues, pull requests, and review settings need separate consideration when planning a full move.

Set up your repository in Depot Code

You'll need a Depot account with Depot Code enabled. Choose a standalone repository if you want to host your code without a GitHub repository behind it. Choose a mirror if you want to keep your GitHub repository connected while using Depot for pushes, fetches, and CI.

Create a standalone repository

In the Depot dashboard, open Code, then Repositories.
Click Create repository and choose Standalone.
Enter a repository name and your default branch name, such as main, then create the repository.
Open the repository and click Create access token. Copy the token when it's shown.
Copy the repository's HTTPS clone URL.

Keep GitHub as your existing origin remote and add Depot as a second remote. Replace the example URL below with the URL from your dashboard, retaining x-token as the username:

git remote add depot https://x-token@<org-id>.code.depot.dev/<repository>
git remote -v
git push depot main

Git prompts for a password. Paste the Depot access token there rather than embedding it in the URL. Replace main with your branch name if it's different. That push copies the branch and the Git history available in your checkout. It doesn't copy GitHub issues, pull requests, secrets, or branch protection settings.

Push other branches and tags explicitly when you need them:

git push depot release/next
git push depot v1.2.3

Check which commits and branches your local checkout contains before treating it as a complete copy. A shallow clone or an old checkout may be missing history or recent work. Git LFS objects and submodule repositories need their own availability checks too.

Mirror an existing GitHub repository

Set up the mirror while GitHub is available so Depot can import the repository.

Open your organization's Settings and connect GitHub Code Access if you haven't already. Give the connection access to the repository you want to mirror.
Under Code, open Repositories, click Create repository, and choose Mirror.
Select the GitHub repository and create the mirror. Depot uses its owner/repository name and default branch.
Wait for the initial import to finish, then open the repository and click Create access token. Copy the token when it's shown.
Copy the repository's HTTPS clone URL.

In your local checkout, keep the existing GitHub remote and add the mirror's URL as depot:

git remote add depot https://x-token@<org-id>.code.depot.dev/<github-owner>/<repository>
git fetch depot
git push depot main

Use the URL from your dashboard and paste the Depot token when Git asks for a password. Replace main with your branch name if it's different. If you already added a depot remote while trying the standalone setup, use git remote set-url depot <mirror-url> to change it.

Fetches come from Depot's copy of the repository, and pushes to Depot sync back to GitHub. You can keep using the Depot remote during a GitHub outage. Depot accepts the changes and syncs them in the background when GitHub returns.

Other developers can clone either repository type using its Depot URL and their own access token. The Depot Code quickstart covers Git authentication and credential helpers.

Replace GitHub Actions with Depot CI

Depot CI runs workflows using GitHub Actions YAML, with its own orchestration and execution infrastructure. Put your workflow files in .depot/workflows/. If you're moving an existing workflow from .github/workflows/, update its runner to a Depot runner and check the compatibility reference for any other changes.

Depot Code currently triggers workflows on push events. For a standalone repository, contact us to enable CI triggers before pushing your first workflow.

Here's a test workflow for a Node.js project with a package-lock.json file and an npm test script. Use your project's Node.js version and test commands:

name: Run tests

on:
  push:
    branches:
      - main

jobs:
  test:
    runs-on: depot-ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npm test

Save it as .depot/workflows/test.yml, then commit and push it to Depot:

git add .depot/workflows/test.yml
git commit -m "Add Depot CI tests"
git push depot main

If you're using a branch other than main, change both the workflow's branch filter and the push command. Open Depot CI in the dashboard and find the run for your commit. Check that checkout retrieved the right commit from Depot Code and that your tests passed.

Depot Code starts a set of workflows for each new commit included in a push. Finish the initial repository import before adding workflows that deploy or run expensive jobs.

Depot-managed GitHub Actions runners still rely on GitHub to dispatch jobs. To move workflow orchestration to Depot too, use Depot CI. Our post on GitHub Actions without GitHub explains how it runs those workflows.

Finish moving your workflows

Once your tests run on Depot, move the configuration and external dependencies your other jobs need:

Secrets and variables. Add them in Depot CI settings and limit access to the intended repositories and workflows. If you use the GitHub secret import, do it while GitHub is available because the import runs a GitHub Actions workflow.
Actions, tools, and packages. Check your jobs for GitHub API calls, release downloads, private packages, and Git dependencies. An action can run on Depot CI and still call GitHub internally. Test those dependencies before relying on the workflow during an outage.
Reviews and deployment. Decide how your team will review changes and approve deployments. Moving a workflow doesn't move GitHub's pull requests, required checks, branch protections, or GitHub-issued OIDC credentials. Depot Code's push triggers don't recreate a pull request workflow.

Run each workflow on Depot and check its results before retiring the corresponding GitHub Actions workflow. For a mirror, account for both systems receiving changes so you don't accidentally deploy from both. Have the team use the agreed remote and review process once you've made the switch.

Keep working during a GitHub outage

With a standalone repository or an existing mirror, your team can keep fetching and pushing through Depot. Fetch before starting work and check for changes from your teammates:

git fetch depot
git log --oneline main..depot/main

The log command shows commits on Depot's main that aren't on your local main. Integrate those changes before pushing your own work with git push depot main. Follow your CI runs in the Depot dashboard.

For a mirror, Depot syncs your pushes back to GitHub in the background once GitHub is available again. For a standalone repository, there's no automatic sync to GitHub. If you want to copy changes back, fetch both remotes, compare the branch histories, and push the reviewed changes through your team's normal process.

If you haven't set up Depot Code yet, you can create a standalone repository during the outage and push the code you have locally. Creating a new mirror needs access to GitHub for the initial import. A standalone repository lets the team resume Git collaboration, but you'll still need to set up CI and enable its triggers.

Before you need this fallback, test a push and a complete workflow with GitHub dependencies unavailable. Include a run without cached dependencies so you can find downloads or API calls that still need GitHub. Depot can host your code and run your jobs, but it can't recover code or credentials whose only copy is in an unavailable GitHub service.