Origin | Depot CI | Depot Docs

Depot CI

Early beta

Origin and the Depot integration are in early beta. Functionality and documentation might change. If you have suggestions to make this integration better, reach out and let us know.

Connect Depot to an Origin namespace to run CI on Depot instead of GitHub. Your existing GitHub Actions workflows keep working: Depot CI reads GitHub Actions workflow syntax, and Depot supplies the orchestrator, the compute, and the cache.

Which repositories trigger from Origin

Origin supports two types of repositories:

Origin-hosted repositories store their code in Origin, which is the source of truth. This includes repositories created in Origin and GitHub mirrors that have been detached from GitHub. Pushes and pull requests send events directly from Origin to Depot CI, and job results appear in Origin.
Repositories mirrored from GitHub stay synchronized with a source repository on GitHub. GitHub remains the source of truth, so Origin doesn't send CI events for these repositories. Changes pushed through Origin sync to GitHub, GitHub sends the event to Depot CI, and job results appear in GitHub.

How Origin and Depot CI work together

Runs triggered by Origin events: pushes and pull requests in Origin-hosted repositories start Depot CI runs. Depot receives the events from Origin directly, so there's no webhook to configure.
Status checks on the pull request: job results appear in Origin, inline with your pull requests. Add branch protection rules to require passing CI before a merge.
Automatic workflow migration: depot ci migrate workflows converts .github/workflows/ into .depot/workflows/ and applies Depot CI compatibility fixes.
Origin compatibility analysis: with --forge=origin, migration reports actions that fail or degrade because Origin doesn't expose a GitHub API they need. See Origin compatibility findings.
Secrets and variables import: depot ci migrate secrets-and-vars imports the secrets and variables your workflows reference, so you don't re-enter them by hand.
Everything else Depot CI does: logs, CPU and memory metrics, SSH into a job, step retries, custom runner images, and an API and CLI so agents can start runs and read results without a git event.

Quickstart

Requirements

A Cursor Pro, Teams, or Enterprise plan with Origin access.
Ownership of the Depot organization you connect.
An authenticated Depot CLI session.

Add a repository to Origin

From cursor.com/codebase, choose how to add your repository:

Origin-hosted repository: click + New, then follow the steps. Continue to Connect Depot from Origin.
Repository mirrored from GitHub: click Sync from GitHub, choose the GitHub organization and repository, and confirm the sync. Continue to Repositories mirrored from GitHub.

Connect Depot from Origin

In Origin, open the Depot app.
Review the requested permissions and install the app.
Origin redirects you to Depot. Create a Depot account, or sign in.
Choose the Depot organization to connect, or create a new one.

Depot then opens the Depot CI page in your dashboard, ready for your first run.

Organization owners can also start from the Depot side. In your organization settings, under Origin, click Connect to Origin. Depot redirects you to Origin to confirm the installation.

Repositories mirrored from GitHub

Depot CI uses the Depot Code Access app to read your GitHub repository and register workflow triggers.

Go to Organization Settings in your Depot dashboard.
In the GitHub Code Access section, click Connect to GitHub.
Install the Depot Code Access app on the personal account or organization that owns your GitHub repository.

Migrate your workflows

Convert your existing GitHub Actions workflows, import their secrets and variables, and merge the new .depot/ directory into your default branch. Follow the workflow migration details for the commands and forge-specific behavior.

See your first run

Open the Depot CI page in your dashboard, or list runs from the CLI:

depot ci run list
depot ci status <run-id>

Workflow migration details

What the migrate command does

The depot ci migrate command:

Validates authentication and checks the repo connections according to the specified --forge flag.
Discovers all workflow files in .github/workflows/.
Prompts you to select which workflows to migrate.
Copies selected workflows and all other non-symlink files under .github/workflows/ to .depot/workflows/, and copies local actions to .depot/actions/.
Applies compatibility fixes and adds inline comments for any changes.

Other files can include helper scripts, configuration files, and non-workflow YAML files. The command preserves their relative paths and permissions, but skips symlinks.

--forge names the forge that hosts the repository and sends events to Depot CI. This value determines what the depot ci migrate command does.

Repository	Flag	CLI behavior
Origin-hosted	`--forge=origin`	Looks for an `origin.cursor.com` remote, confirms Origin exposes the repository to your Depot organization, and runs the Origin compatibility analysis.
Mirrored from GitHub	`--forge=github` (default)	Looks for a `github.com` remote and confirms the Depot Code Access app is installed.

For the full command reference, see depot ci migrate.

Run the migration

Run these steps from a checkout of the repository you connected.

Install the Depot CLI.
Run depot login and select the Depot organization you connected.
From the repository root, run the command for your repository type:

Origin-hosted: depot ci migrate --forge=origin
- Mirrored from GitHub: depot ci migrate --forge=github

The command output lists the workflows with triggers Depot CI supports, asks whether to migrate the rest, and writes converted copies into .depot/workflows/. Anything it can't translate cleanly becomes a disabled job for you to review. For Origin-hosted repositories, the command also reports compatibility findings.

Import secrets and variables with the command for your repository type:

Origin-hosted: run depot ci migrate secrets-and-vars --forge=origin.
- Mirrored from GitHub: run depot ci migrate secrets-and-vars --forge=github.

Both commands create a local temporary branch with a one-shot workflow and print a git push command. Push the branch within five minutes. The workflow imports the values into Depot CI and removes the temporary remote branch.

Commit .depot/workflows/ and merge it into your default branch to activate the workflows.

Origin compatibility findings

Compatibility findings apply to Origin-hosted repositories. A repository that triggers from GitHub reaches the GitHub APIs as usual, so its migration reports no findings.

Some GitHub Actions workflows use actions that depend on something Origin has no equivalent for. When you specify origin as the forge during migration, Depot checks the workflows you selected and reports on Origin compatibility.

The check reads your local .github/workflows/*.yml and *.yaml files before Depot copies them, so findings cover the files you're about to migrate, including uncommitted edits. You don't need to push anything first.

Regardless of findings, Depot writes the selected workflows to .depot/workflows/. A finding tells you what to change, but doesn't block the migration.

Compatible actions produce no findings. If all of your workflows are compatible, then the CLI omits the compatibility output.

Severities

Label	Meaning
`FAILS`	The affected mode needs a capability Origin doesn't provide, so that operation fails.
`SILENT DEGRADATION`	The workflow continues and can look successful, but the intended result is never published or completed.
`CONDITIONALLY UNSUPPORTED`	Runtime inputs, events, or configuration decide whether the unsupported operation runs, so not every run will fail.

A label describes the action mode, not the migration command.

Reading the output

A single workflow step can produce more than one finding. Depot reports each unsupported behavior in a separate finding block. Findings are advisory only. A FAILS finding doesn't stop the migration. The following example shows what the findings output looks like:

Origin compatibility findings:

FAILS — .depot/workflows/ci.yml (from .github/workflows/ci.yml)
    Job: release
    Step: Publish release
    Action: softprops/action-gh-release
    Mode: publish-release
    Missing capability: github-releases
    Explanation: Origin does not provide GitHub release or release-asset APIs.
    Workaround: Publish releases from a GitHub workflow or use another release destination.

SILENT DEGRADATION — .depot/workflows/ci.yml (from .github/workflows/ci.yml)
    Job: scan
    Step: Publish dependency snapshot
    Action: aquasecurity/trivy-action
    Mode: dependency-snapshot
    Missing capability: dependency-snapshots
    Explanation: Trivy GitHub format sends the Origin token to the public GitHub dependency snapshot API and does not fail when publication is rejected.
    Workaround: Use another Trivy output format or publish the dependency snapshot from a GitHub workflow.

CONDITIONALLY UNSUPPORTED — .depot/workflows/ci.yml (from .github/workflows/ci.yml)
    Job: codeql
    Step: Analyze
    Action: github/codeql-action/analyze
    Mode: upload-analysis
    Missing capability: code-scanning-sarif
    Explanation: Origin does not provide GitHub code-scanning or SARIF upload APIs.
    Workaround: Set upload to never or run CodeQL analysis on GitHub.

Findings fields

Field	Description
Workflow heading	The migrated destination and the original source.
`Job`	The job that contains the affected step.
`Step`	The step name, when the workflow gives one.
`Action`	The affected action.
`Mode`	The behavior or configuration being reported. An action can work in one mode and fail in another, which is why a finding names a mode and not just an action.
`Missing capability`	The forge capability that mode requires.
`Explanation`	Why the behavior is affected on Origin.
`Workaround`	An alternative, when one exists. When no workaround exists, the output omits this field.

Troubleshooting

Authentication fails

The migration commands require a Depot user token or organization token. Run depot login, set DEPOT_TOKEN, or pass --token.

No Depot organization is selected

A user token needs an active organization. Select one with depot org switch, or pass --org to the migration command.

Depot can't detect the repository

Run migration commands from the repository root and inspect its remotes:

git remote -v

Make sure the remote, forge flag, and installed app match the repository type:

Repository	Expected remote	Migration flag	Required connection
Origin-hosted	`origin.cursor.com/<namespace>/<repository>`	`--forge=origin`	Depot app in Origin
Mirrored from GitHub	`github.com/<owner>/<repository>`	`--forge=github` or no flag	Depot Code Access app

For an Origin-hosted repository, a missing or incorrect remote produces an error like this:

could not detect an Origin repository from git remotes — configure a remote pointing to origin.cursor.com/namespace/repo

Add or correct the remote, confirm the appropriate app can access the repository, and rerun the command with the matching forge flag. The depot ci migrate secrets-and-vars command also needs a remote it can push to.

No run starts after migration

Confirm that the migrated files are under .depot/workflows/ on the default branch and that the workflow contains a trigger matching the event you sent. Also confirm that Depot is connected through Origin for an Origin-hosted repository or through GitHub for a mirrored repository.

For a mirrored repository, status checks appear in GitHub rather than Origin.

Secrets and variables import expires

Push the temporary import branch within five minutes. If the window expires, rerun depot ci migrate secrets-and-vars with the appropriate --forge value to create a new import branch.