If you're leaving GitHub Actions but want to keep your workflows, Depot CI runs GitHub Actions YAML on Depot's own CI engine. You keep your build and test commands, with managed compute, caching, and local workflow runs through the Depot CLI.
Buildkite and CircleCI also have GitHub Actions compatibility features in preview. GitLab CI/CD combines source hosting and CI, though moving to it means converting your workflows to GitLab's configuration format.
If you just need faster machines for your existing GitHub Actions workflows, see our runner alternatives guide.
Migration paths
| Platform | What the move involves |
|---|---|
| Depot CI | Use the migration tool to copy workflows into .depot/workflows/ and apply compatibility changes. Depot handles orchestration and compute. |
| Buildkite | Run supported GitHub Actions workflows through its preview compatibility feature, or convert to native Buildkite pipelines. Choose hosted or self-hosted agents. |
| CircleCI | Use GitHub Actions workflow files through its preview support, or convert to CircleCI configuration. Check its restrictions on private actions and reusable workflows. |
| GitLab CI/CD | Move jobs, stages, and dependencies into .gitlab-ci.yml. Source hosting, merge requests, and CI can live in GitLab together. |
Running your workflows on Depot CI
Depot CI supports jobs, steps, dependencies, expressions, reusable workflows, and merge queue triggers. The compatibility matrix lists supported actions, fields, and events, including the changes needed for features that work differently on Depot.
You can run a workflow against uncommitted changes from your terminal. When a job fails, retrieve its logs or connect to its sandbox to debug it. A coding agent can use the same loop: change the code, run the workflow, inspect the failure, and try again without pushing a commit each time.
Depot Cache is available in CI, and custom snapshot images let you install tools and dependencies ahead of time. The CI overview covers compute sizes and billing.
Depot CI runs Linux jobs. For macOS or Windows, keep those workflows in GitHub Actions on
Depot-managed runners. If you have a matrix spanning all three operating systems,
split it into separate workflows and update the required checks. Jobs connected through needs must run in the
same CI system.
Your source repository and actions can still depend on GitHub after you move CI. If you're moving source hosting too, Depot CI also connects to Origin, currently in early beta, and Entire.
Migrate a workflow
Start with a build-and-test workflow. Install the Depot CLI, sign in with depot login,
and connect the Depot Code Access GitHub App using the quickstart. Then run this from your
repository root:
depot ci migrateSelect the workflow you want to move. The command copies it to .depot/workflows/, copies local actions to
.depot/actions/, and applies compatibility changes. Review the generated runner labels, action paths, and any
comments about steps you need to change.
Import the workflow's secrets and variables into Depot. The quickstart includes the import command. For jobs using GitHub OIDC, update the cloud provider's trust configuration to accept Depot's issuer.
For a workflow named ci.yml, run the migrated version against your local checkout:
depot ci run --workflow .depot/workflows/ci.ymlFor jobs that check out this repository, Depot applies your local changes before running the workflow on its compute. You can edit the code and rerun the command while working through failures.
Once the workflow passes, merge the .depot/ files to your default branch to register automatic triggers. Your original GitHub workflows are
still active, so you can compare runs on the same commits before updating required checks and disabling them. Move
deployment workflows separately so the two systems don't publish or deploy the same change twice.