CI no Cursor Origin: como rodar seus workflows do GitHub Actions com Depot ou Buildkite
CI no Cursor Origin já funciona sem reescrever pipeline: as extensões de app trazem Depot e Buildkite, e os dois rodam os workflows do GitHub Actions que já estão no seu repositório. A instalação acontece nas configurações do codebase, em cursor.com/codebase/settings/apps, e os apps aparecem na aba Apps das configurações do repositório. Vale só para repositórios hospedados nativamente no Origin, ou seja, mirror do GitHub fica de fora. O Buildkite ainda soma pipelines nativas dele. Tudo está em beta ou preview experimental, então mantenha o CI atual rodando como rede de segurança
Fala aí, beleza? Reescrever pipeline só pra experimentar plataforma nova é o tipo de trabalho que ninguém quer fazer 😅
E é justamente isso que as extensões de app de CI do Origin evitam
O Origin é a plataforma de hospedagem de código da Cursor, apresentada em junho de 2026 e liberada em early beta no dia 17 de agosto de 2026
Junto dela veio a abertura pra ferramentas externas por meio de extensões de app (apps de terceiros), começando por Vercel, Depot e Buildkite, com mais integrações prometidas
O ponto que interessa aqui: pra rodar CI no Cursor Origin dá pra conectar Depot ou Buildkite, e os dois executam os workflows do GitHub Actions que você já tem no repositório
O Buildkite ainda soma as pipelines nativas dele por cima disso
Bora ver como isso funciona na prática?
Formação Claude Code
Domine Claude Code do absoluto zero até o avançado
- 120 aulas
- 4 projetos
- 9h 45min
O que você precisa antes de conectar Depot ou Buildkite
Antes de sair clicando, confere essa lista:
- Plano pago da Cursor: o Origin está em early beta para Pro, Teams e Enterprise, com rollout escalonado, e não está disponível no plano gratuito
- Enterprise sem opt-out: organizações Enterprise cujos administradores optaram por sair ficam de fora
- Repositório hospedado nativamente no Origin: Depot e Buildkite funcionam apenas nesses repos, e não em repositórios espelhados do GitHub
- Workflows do GitHub Actions já versionados no repositório que você quer rodar
- Acesso às configurações do codebase, em cursor.com/codebase/settings/apps
E aí vem a pergunta clássica: repositório nativo, como assim?
O Origin faz sincronização bidirecional de pull requests com o GitHub, o que permite espelhar repositórios que continuam morando lá
Esse é o mirror
O repositório nativo é o contrário: ele vive no Origin, com clone, fetch, push e pull por git, navegação e busca de código no navegador, pull requests com comentários, reviews, checks, conflitos e merges, configurações de repositório com branch protection e uma API REST pública
Pra criar um repo nativo tem a CLI própria do Origin, separada da CLI do agente da Cursor
O instalador coloca o binário em ~/.local/bin/origin e o login pelo navegador configura o git credential helper
Os comandos de repositório são estes:
origin repo create
origin repo deletePasso a passo: instalar a extensão de app de CI no seu codebase
Esse trecho é igual pros dois, Depot ou Buildkite
- Abra as configurações do codebase em cursor.com/codebase/settings/apps, que é onde os apps de terceiros (Vercel, Depot e Buildkite) são instalados
- Instale o app de CI que você quer usar, ali mesmo, no nível do codebase
- Abra Repository settings e vá na aba Apps do repositório: ela mostra os apps instalados para aquele repositório específico
- Use a opção Manage Apps quando precisar voltar: ela abre as configurações de Apps no nível do codebase de novo
O erro comum deste passo é tentar conectar num repositório espelhado do GitHub
Depot e Buildkite funcionam apenas em repositórios Origin-native, então mirror não vai te levar a lugar nenhum
Pra sentir a mecânica da aba Apps antes de mexer no CI, o Vercel é um bom exemplo: conectado por ali, cada pull request recebe um deploy de preview pra testar e comentar antes do merge
Mesma aba, mesma lógica de conexão
Como rodar seus workflows do GitHub Actions com o Depot
O Depot CI está em beta e adotou a sintaxe do GitHub Actions como primeira sintaxe de workflow
Ou seja: ele roda os workflows na infraestrutura do Depot sem você reescrever YAML
- Instale o app do Depot nas configurações do codebase, em cursor.com/codebase/settings/apps
- Confirme na aba Apps das configurações do repositório que ele aparece pro repo certo
- Conheça o assistente de migração do Depot CI: o comando depot ci migrate abre um assistente que descobre os workflows do GitHub Actions, analisa compatibilidade e copia os workflows selecionados e as actions locais para um diretório .depot/
depot ci migrateO erro comum deste passo é contar com uses apontando para workflows de outros repositórios
Isso não é suportado na compatibilidade do Depot CI com o GitHub Actions
Já o uses referenciando actions do GitHub Actions Marketplace continua funcionando normal
Como rodar seus workflows do GitHub Actions com o Buildkite
O Buildkite é parceiro de lançamento do Origin e é distribuído no Origin Marketplace
A integração está disponível para clientes selecionados do Origin a partir de 17 de agosto de 2026, e o Buildkite passa a funcionar com GitHub, GitLab, Bitbucket e também com o Origin
- Instale o app do Buildkite nas configurações do codebase, em cursor.com/codebase/settings/apps
- Verifique na aba Apps do repositório se ele está ativo ali
- Entenda o que acontece com o seu YAML: o projeto buildkite-gha, do próprio Buildkite, roda workflows do GitHub Actions como builds nativos do Buildkite, sem criar uma execução no GitHub Actions
E como fica a tradução? Cada job de workflow suportado e cada entrada de matriz estática vira um job do Buildkite
A partir daí o Buildkite controla agendamento, logs, retries, cancelamento e a UI do build
O erro comum deste passo é tratar isso como coisa estável
O buildkite-gha é um preview experimental pré-1.0: suporta actions locais e públicas, checkout limitado ao job, GITHUB_TOKEN, artifact e cache, mas não suporta actions privadas, secrets comuns de workflow nem OIDC compatível com GitHub
Depot ou Buildkite: qual encaixa no seu caso
Quatro cenários bem diretos:
| Cenário | Encaixe |
|---|---|
| Quer o mesmo pipeline rodando em outra infraestrutura, sem mexer no YAML | Depot ou Buildkite |
| Já usa Buildkite em GitHub, GitLab ou Bitbucket e quer unificar com o Origin | Buildkite |
| Quer somar pipelines nativas ao que já existe | Buildkite |
| Depende de actions privadas, secrets comuns de workflow ou OIDC compatível com GitHub (nada disso é suportado no buildkite-gha, que é preview pré-1.0) | Mantenha esses workflows onde eles já rodam por enquanto |
Repara que o fio condutor é sempre o mesmo: aproveitar o que você já montou em vez de refazer do zero
É o mesmo raciocínio de quem pesquisa se dá pra usar OpenCode com conta do ChatGPT Plus antes de assinar mais uma coisa
Limites conhecidos e o que fazer quando o workflow não roda
O app não aparece para o repositório:
Causa provável: o repositório é um mirror do GitHub, e não um repo hospedado nativamente no Origin
O que fazer: use um repositório Origin-native, porque Depot e Buildkite só funcionam nesse formato
O workflow falha no buildkite-gha:
Causa provável: ele usa actions privadas, secrets comuns de workflow ou OIDC compatível com GitHub
O que fazer: nada disso é suportado no preview pré-1.0, então deixe esses workflows rodando onde já rodam
O uses de outro repositório não executa no Depot:
Causa provável: a chave uses referenciando workflows de outros repositórios não é suportada no Depot CI
O que fazer: mantenha as actions do Marketplace (essas seguem funcionando) e trate o workflow compartilhado como caso à parte
E como prevenir tudo isso? Rode o assistente de compatibilidade antes de migrar e não desligue o pipeline original enquanto os produtos estiverem em beta
É a mesma disciplina de quem vai atualizar o n8n sem quebrar fluxos: caminho de volta primeiro, coragem depois 😀
Um vídeo do canal pra continuar no assunto
Se você gosta de acompanhar o que está saindo em ferramentas de IA, esse vídeo do canal mostra a IA grátis que o PewDiePie lançou pra rodar no seu próprio PC:
Vale conectar CI no Origin agora?
O caminho existe e ele é honesto: Depot e Buildkite rodam os workflows do GitHub Actions que você já tem, sem reescrita de pipeline
Mas tem os poréns, e eles são grandes
Tudo isso vale só pra repositórios hospedados nativamente no Origin, o Depot CI está em beta, o buildkite-gha é preview experimental pré-1.0 e a integração do Buildkite com o Origin está liberada pra clientes selecionados
Tem também o contexto de fundo: o lançamento do Origin em 17 de agosto de 2026 caiu no mesmo dia de uma grande instabilidade do GitHub, o que ajudou a esquentar o assunto
E um ponto que merece peso na sua decisão: até 18 de agosto de 2026, a Cursor não havia publicado termos de retenção de dados, política de uso para treino, lista de subprocessadores nem ferramenta de migração para código hospedado nativamente no Origin
Minha sugestão de próximo passo é conservadora: cria um repositório novo com origin repo create, conecta o app de CI ali e observa o comportamento, mantendo o seu CI atual rodando como rede de segurança
Dá pra experimentar sem apostar o time inteiro, beleza?
até o próximo post! 🙂
Perguntas frequentes
Repositório espelhado (mirror) do GitHub funciona pra rodar CI no Cursor Origin?
Não. Depot e Buildkite funcionam apenas em repositórios hospedados nativamente no Origin, e repositórios espelhados do GitHub ficam de fora. Se o seu repo ainda é um mirror, o CI via essas extensões simplesmente não vai aparecer disponível.
CI no Cursor Origin funciona no plano gratuito da Cursor?
Não. O Origin está em early beta apenas para planos pagos: Pro, Teams e Enterprise, com rollout escalonado. Organizações Enterprise cujos administradores optaram por sair também ficam de fora, então nem todo Enterprise tem acesso garantido.
Qual a diferença entre conectar o Depot e o Buildkite pro CI no Origin?
O Depot CI adotou a sintaxe do GitHub Actions e roda seus workflows na infraestrutura do Depot sem reescrever YAML. Já o Buildkite usa o projeto buildkite-gha pra transformar cada job de workflow e cada entrada de matriz estática em job nativo do Buildkite, e ainda soma pipelines nativas próprias por cima disso.
O buildkite-gha já suporta secrets e OIDC como o GitHub Actions?
Ainda não. O buildkite-gha é um preview experimental pré-1.0, e não suporta actions privadas, secrets comuns de workflow nem OIDC compatível com o GitHub. Ele suporta actions locais e públicas, checkout limitado ao job, GITHUB_TOKEN, artifact e cache.
O que o comando depot ci migrate faz?
Ele abre um assistente que descobre os workflows do GitHub Actions do seu repositório, analisa a compatibilidade e copia os workflows selecionados e as actions locais para um diretório .depot/. É o caminho de migração documentado do Depot CI, que está em beta e roda os workflows na infraestrutura do Depot sem reescrita de YAML.
A Cursor já publicou como fica a retenção de dados do código hospedado no Origin?
Até 18 de agosto de 2026, não. A Cursor ainda não tinha publicado termos de retenção de dados, política de uso para treino, lista de subprocessadores nem ferramenta de migração para código hospedado nativamente no Origin.
Matheus Battisti
Formações
Formação Vibe Coding
Do Prompt ao Produto: Crie Software Real com IA
- 474 aulas
- 20 projetos
- 39h 27min
Blog | Mais populares
Como revisar, comentar e fazer merge de uma pull request no Cursor Origin
Veja como revisar, comentar e fazer merge de uma pull request no Cursor Origin sem sair do editor: diff, comentários bidirecionais e merge direto.
Comentários e reações em PR: como funciona a sincronização entre Cursor e GitHub?
A sincronização entre Cursor e GitHub funciona nos dois sentidos: comentários e reações no PR aparecem em segundos, com o GitHub como fonte da verdade.
Vale a pena sincronizar seus repositórios do GitHub com o Origin do Cursor?
Origin do Cursor chegou em beta com repositórios, PRs e sync com GitHub. Veja o que vale sincronizar, o que evitar e como funciona o Detach from GitHub.
