Perguntas frequentes

Claude Code, Cursor, Codex e qualquer outro cliente MCP. Cada um se conecta com uma API key do Latchkey, criada no dashboard em Settings > API keys and agents. Os agentes também podem chamar a CLI a partir de um shell depois de npm install -g @latchkeydev/cli: o latchkey run executa um comando em uma VM Linux nova a partir da sua working tree local, mostra os logs ao vivo e retorna o exit code real.

Sim. Quando a autocorreção não consegue resolver uma falha, o Latchkey a reúne em um failure bundle para o seu agente: a causa raiz, o arquivo com falha e os logs capturados, sem os secrets. Gere uma API key (lk_live_) em Settings > API keys and agents, adicione o servidor MCP ao Claude Code, ao Cursor ou a qualquer cliente MCP, e o agente pode baixar failure bundles, verificar o status das execuções e ler os logs de qualquer job concluído. As keys são somente leitura por padrão, então um agente pode ler esse contexto, mas nunca alterar seu código ou sua conta. As ações são opcionais por key: escolha o acesso Dispatch para deixá-lo iniciar workflows do GitHub Actions, ou o acesso CLI runner para deixá-lo executar comandos em VMs novas, cobrados por minuto como qualquer outro job.

Dezessete ferramentas. list_failed_runs, get_failure_bundle, get_run_status e tail_run_logs permitem que um agente encontre e leia falhas de CI. dispatch_workflow inicia um workflow do GitHub Actions. run_job, list_jobs, get_job_status, get_job_logs e cancel_job permitem executar um comando em uma VM nova, acompanhá-lo, ler o resultado ou cancelá-lo. set_batch_budget define ou reduz o orçamento de um lote de jobs, e get_batch lê o orçamento, o gasto e os jobs de um lote. plan_migration, apply_migration e get_migration planejam a mudança de um repositório para o Latchkey CI, abrem o pull request que adiciona os arquivos de workflow dele quando o repositório está em modo consultivo e dizem em que pé ele está. list_latchkey_steps lista os passos do Latchkey que um arquivo de workflow pode nomear, com as entradas de cada versão e suas regras. list_environments lê quais branches cada ambiente de um repositório aceita. dispatch_workflow, as sete ferramentas de job, list_environments e apply_migration só funcionam com uma key criada com essas permissões.

Ele consulta periodicamente as falhas de CI que a autocorreção diagnosticou mas não conseguiu corrigir e entrega cada nova falha a um agente de código: o Claude Code por padrão, ou qualquer comando de agente que você informar. Falhas que já estavam abertas quando o watch começou não são entregues, e cada nova falha é entregue uma única vez. Qualquer API key pode executá-lo, porque ele lê pelo escopo mcp:read que toda key possui.

Por minuto, pela tarifa do tamanho em que rodam, usando os mesmos minutos gratuitos dos seus jobs do Latchkey CI e do Latchkey on GH. A CLI e o servidor MCP estão em todos os planos, sem taxa adicional; eles exigem uma assinatura ativa ou um período de teste. Um orçamento de lote limita quanto um grupo de jobs de agentes pode gastar, e uma API key pode reduzir esse orçamento, mas nunca aumentá-lo.

As keys são criadas em Settings > API keys and agents, e cada uma tem apenas os escopos escolhidos quando foi criada. Toda key tem mcp:read, que permite a um agente ler falhas. Rodar jobs exige jobs:run, ler o status e os logs de jobs exige jobs:read, e disparar workflows é uma opção separada. Não é possível adicionar escopos a uma key existente, qualquer key pode ser revogada, e o Latchkey guarda apenas um hash de cada key. Cada job roda em sua própria VM, destruída ao fim do job.

A autocorreção é o ciclo de reparo do Latchkey para etapas de CI com falha. Quando uma etapa falha por um motivo transitório, o Latchkey detecta a falha, diagnostica a causa e a corrige na própria máquina enquanto o job ainda está em execução, e o job continua sem intervenção humana. Ela funciona da mesma forma no Latchkey CI e no Latchkey on GH.

Falhas transitórias e ambientais: problemas de rede (timeouts de registry e 5XXs de npm, Yarn, PyPI, Docker, Terraform), erros de memória (OOM kills, SIGKILL), erros de disco cheio (ENOSPC), ferramentas ausentes (command-not-found, instaladas a partir de uma allowlist verificada) e desvios de ambiente ou configuração (variáveis ausentes, incompatibilidades de versão de toolchain, limites de file-handle). Bugs reais no seu código, como testes com falha ou erros de compilação, explicitamente não são corrigidos e falham com os logs originais.

Em todo job do Latchkey CI e em todo job do Latchkey on GH, em todos os tamanhos, sem configuração. A autocorreção nunca roda em um pull request de um fork. No Latchkey CI, ela também nunca roda em um passo que escreve advisory: skip, em um passo que pode publicar e não escreve advisory:, nem em qualquer passo de um job que escreve advisory: hold ou nomeia um ambiente e não escreve advisory:, porque rodar um passo desses de novo repetiria o que ele fez.

Sim, para novos workspaces. Owners e admins podem desativá-la para todo o workspace em Settings > Self-healing.

Não há taxa separada. A autocorreção roda dentro do job, então qualquer tempo que ela adicione é cobrado pela mesma tarifa por minuto do restante do job.

Ela funciona em etapas. Primeiro, o exit code e o log da etapa com falha são comparados com padrões de falha conhecidos, e os casos simples são repetidos ou corrigidos na hora. O que escapa disso vai para um agente de IA que só pode executar um conjunto fixo de ações, como instalar um pacote do sistema, liberar disco, definir uma variável de ambiente ou repetir com backoff, dentro de um limite de tempo. Por padrão, uma etapa com falha é reexecutada no máximo três vezes.

O agente recebe stderr, stdout, exit code e um conjunto selecionado de arquivos de manifesto (por exemplo, package.json, requirements.txt) para poder raciocinar sobre a falha. O código-fonte não é enviado. As ações do agente são limitadas a uma allowlist verificada; ele não pode executar comandos arbitrários nem modificar seu código.

Sim, por meio de pull requests de correção. Quando uma correção bem-sucedida remonta a uma causa estrutural, como uma etapa de setup ausente no workflow ou um timeout de job baixo demais, o Latchkey pode abrir um pull request com a correção duradoura para você revisar e fazer merge. Mudanças duradouras sempre chegam como PRs revisáveis; a autocorreção nunca modifica seu código durante uma execução.

Sim. A página da execução marca cada etapa corrigida como Healed, e Open the heal no job abre o relatório completo da correção: o veredito, o que estava errado, a ação tomada e, para correções feitas pelo agente de IA, a transcrição completa do agente.

Uma plataforma de CI/CD independente, feita para agentes de código. Você faz commit de um arquivo de workflow, e o Latchkey o coloca na fila, executa cada job em uma VM Linux nova, corrige falhas transitórias durante a execução, guarda os logs e as páginas de execução e reporta o resultado no seu pull request como checks. Seus agentes de código usam o mesmo CI por meio de uma CLI e de um servidor MCP. Equipes que querem manter seus workflows do GitHub Actions podem usar o Latchkey on GH, nossos runners gerenciados para o GitHub Actions.

Cadastre-se, instale o GitHub App do Latchkey na sua conta ou organização e ative o repositório no dashboard. Depois, faça commit de um arquivo de workflow como .latchkey/workflows/ci.yml e faça push. O Latchkey o executa a cada push e pull request e reporta o resultado como checks do GitHub: Latchkey para a execução e Latchkey / plan para indicar se o arquivo de workflow compilou. Cada check leva à página da execução, com logs ao vivo.

Ele usa o formato de workflow do GitHub Actions que você já conhece, com cada etapa escrita como run: ou como um passo do Latchkey (uses: latchkey/<name>@<version>). Ele suporta jobs, needs, matrix com include e exclude, services, env, secrets, environment, if e timeout-minutes, e roda em push, pull_request e em uma agenda. Cada job define runs-on: com um tamanho: small, medium, large ou xlarge. O checkout é automático, e Node, Python, Go, Rust e Java já vêm na imagem. Um job que define um environment espera até que um owner ou admin aprove a execução, a menos que o ambiente esteja definido para não precisar de aprovação. Uma chave que o Latchkey não suporta é recusada pelo nome, com o número da linha.

Etapas que chamam uma action do GitHub com uses:. O Latchkey executa só os próprios passos, escritos uses: latchkey/<name>@<version>, então escreva qualquer outra etapa como run:. O Latchkey não executa actions do marketplace, composite actions nem reusable workflows. Gatilhos manuais, Git LFS, containers e permissions também ainda não são suportados, e concurrency: não aceita cancel-in-progress: true, porque o Latchkey nunca interrompe um job em execução. Para cache, use os passos latchkey/cache-restore e latchkey/cache-save, ou instale a CLI em uma etapa (npm install -g @latchkeydev/cli) e rode latchkey cache restore e latchkey cache save. Um workflow que precise de algum desses recursos pode continuar no GitHub Actions com o Latchkey on GH.

Na página da execução no dashboard do Latchkey, para a qual cada check do GitHub aponta. Ela mostra cada job com seus needs e skips, as combinações da matrix, os services e as etapas corrigidas, além de logs por etapa, com busca, que se atualizam ao vivo enquanto o job roda. Reexecute só o que falhou pelo botão Re-run do GitHub ou pelo dashboard: um job que passou não roda nem é cobrado de novo, a menos que dependa de um job reexecutado. Os logs dos jobs ficam guardados por 7 dias, e os agentes leem os mesmos logs com latchkey logs ou pelo servidor MCP.

No Latchkey CI, quando é o Latchkey, e não o seu código, que interrompe uma execução, o check Latchkey termina como neutral e explica o motivo. Se a interrupção for um erro nosso, o check Latchkey / plan fica vermelho para continuar visível. Reexecute pelo GitHub ou pelo dashboard.

O Latchkey on GH, nossos runners gerenciados para o GitHub Actions, mantém seus arquivos em .github/workflows como estão. Defina runs-on: latchkey-small (ou latchkey-medium, latchkey-large ou latchkey-xlarge) e as mesmas VMs com autocorreção executam seus jobs do GitHub Actions, incluindo as actions. Ele exige uma organização no GitHub. Todo plano mantém um runner latchkey-small aquecido e três em espera prontos para esses jobs, e os tamanhos maiores sobem sob demanda. O AI Scan também pode criar um runner personalizado para um repositório.

Para o Latchkey CI, Move CI to Latchkey, em Migrate no dashboard, planeja cada pipeline, transfere os segredos dele e abre o pull request que adiciona os arquivos, depois roda os dois lado a lado até você trocar. Um agente pode planejar a mesma mudança com a ferramenta plan_migration, que propõe um arquivo .latchkey/workflows para cada pipeline e marca o que precisa de uma pessoa. Abrir o pull request que adiciona os arquivos, com apply_migration, exige o repositório em modo consultivo. À mão, copie os jobs para .latchkey/workflows/<name>.yml, defina runs-on: com um tamanho como small e reescreva cada etapa uses: como run: ou como um passo do Latchkey (uses: latchkey/<name>@<version>); o Latchkey recusa uma chave não suportada por vez, pelo nome e pela linha, para que você as corrija em ordem. Para o Latchkey on GH, mantenha o workflow e troque runs-on: ubuntu-latest por runs-on: latchkey-small.

No Latchkey on GH, sim. A ferramenta Migrate Runners na página Runners abre um pull request pronto para revisão por repositório, para até 20 repositórios por vez. Apenas as linhas de runs-on são alteradas; todas as outras linhas de cada arquivo permanecem byte a byte idênticas, e os jobs de Windows e macOS ficam intocados. Nada muda até que sua equipe faça o merge. Mover vários repositórios para arquivos de workflow do Latchkey CI ainda não é automatizado.

Sim. Se seus workflows rodam no GitHub Actions, o caminho mais curto é o Latchkey on GH: aponte a linha runs-on: para um label do Latchkey e deixe o resto do workflow como está. Caches de dependências, cache de camadas Docker e etapas que dependiam de uma máquina gerenciada por você podem precisar de ajustes próprios, e os guias de migração abaixo cobrem cada provedor. Para que o Latchkey execute o próprio pipeline, faça commit dos mesmos jobs como um arquivo de workflow do Latchkey CI.

Ubuntu 24.04 em x86_64, na região us-east-1 da AWS, em quatro tamanhos: small (2 vCPU, 8 GB), medium (4 vCPU, 16 GB), large (8 vCPU, 32 GB) e xlarge (16 vCPU, 64 GB), com as toolchains mais comuns pré-instaladas. Cada job ganha sua própria VM, destruída ao fim do job. Máquinas Windows, macOS, arm64 e com GPU não são oferecidas, e o Migrate Runners deixa os jobs Windows e macOS onde estão.

Sim. Cada job roda em sua própria VM nova, em uma rede privada sem acesso de entrada, e a VM e seu disco são destruídos ao fim do job, então nada passa de um job para o outro como pode acontecer em um runner self-hosted persistente. No Latchkey CI, a VM clona seu repositório com um token de curta duração restrito a esse repositório, e nada é registrado no GitHub.

Cada job roda em sua própria VM. Um job do Latchkey CI pode definir timeout-minutes até 180 (30 por padrão), um job da CLI roda por até 3 horas, e um job do Latchkey on GH por até 4 horas, ou até 8 se ainda estiver em execução ao completar 4 horas. Cada plano define quantos jobs um workspace pode executar ao mesmo tempo: Developer 20, Launch 40, Scale 80; um teste gratuito usa o número do Launch, e os jobs acima do limite esperam na fila. Os limites do Enterprise são definidos em contrato. Se sua equipe precisar de mais simultaneidade, entre em contato pelo suporte.

Os jobs são cobrados por minuto conforme o tamanho, arredondados para cima por job, sem taxa por ociosidade, igual no Latchkey CI, no Latchkey on GH e em jobs de agentes: small (2 vCPU / 8 GB) custa $0,0025 por minuto, medium (4 vCPU / 16 GB) custa $0,005, large (8 vCPU / 32 GB) custa $0,01 e xlarge (16 vCPU / 64 GB) custa $0,02. Os runners personalizados são cobrados pela tarifa do xlarge. Pelos preços de tabela do GitHub, isso é de 52 a 58% menos por minuto do que os runners hospedados pelo GitHub. Todo plano inclui minutos gratuitos a cada mês (2.000 no Developer, 4.000 no Launch, 6.000 no Scale), e o uso além dos minutos incluídos é cobrado pela tarifa por minuto. Os minutos de runner gratuitos são contados em unidades equivalentes ao small: um minuto no latchkey-small conta como um, no medium como dois, no large como quatro e no xlarge ou em um runner personalizado como oito, e a franquia incluída em cada plano permanece a mesma.

Sim. No Latchkey CI, adicione os passos latchkey/cache-restore e latchkey/cache-save, ou instale a CLI em uma etapa (npm install -g @latchkeydev/cli) e rode latchkey cache restore e latchkey cache save: o cache é restrito ao repositório e à branch, as outras branches leem o cache da branch padrão, e uma falha de cache ou um erro do proxy de cache nunca faz o job falhar. No Latchkey on GH, use latchkey-dev/cache-action@v1 para caches de dependências e latchkey-dev/docker-cache-action@v1 para camadas do Docker; o armazenamento e as credenciais já vêm provisionados, na mesma região do runner. Os caches de dependências ficam guardados por 14 dias; os caches de camadas do Docker mantêm a imagem de cache atual e descartam as camadas substituídas 7 dias depois de enviadas.

O Insight lê os jobs que o Latchkey executa para você e encontra correções de custo, confiabilidade e segurança, como um runner superdimensionado, minutos gastos em jobs com falha, um job instável ou uma action sem versão fixada. Cada achado traz um valor em dólares ou em tempo, calculado a partir das suas próprias execuções, e um modelo de IA escreve a explicação curta. Quando um achado tem correção, aprová-lo abre a mudança como um pull request.

Não. Toda alteração de repositório que o Latchkey faz, seja um insight de otimização, uma correção de heal ou uma migração de runner, chega como um pull request que você revisa e faz merge. Nada entra no seu repositório sem a sua aprovação.

Quatro planos: Developer a $5/mês (1 repositório, 2.000 minutos gratuitos em equivalente small, 1 seat), Launch a $19/mês (até 10 repositórios, 4.000 minutos gratuitos em equivalente small, 3 seats incluídos e seats extras a $5/mês), Scale a $49/mês (até 40 repositórios, 6.000 minutos gratuitos em equivalente small, 5 seats incluídos) e Enterprise com preço personalizado. Todo novo workspace começa no plano Launch, e o primeiro workspace de uma pessoa começa com um teste de 30 dias desse plano.

Não. Um novo workspace começa com um teste de 30 dias do plano Launch, com acesso a todos os recursos e sem cartão. Cada pessoa tem um teste gratuito, no seu primeiro workspace.

Cada repositório que você ativa no dashboard ocupa uma das vagas de repositório do seu plano: 1 no Developer, 10 no Launch, 40 no Scale. O Latchkey CI e o Latchkey on GH compartilham as mesmas vagas. Repositórios que você não ativou não contam, e desativar um libera a vaga.

Não. Não há cobrança por execução, por workflow nem por check. Os minutos são o único uso medido: todo plano inclui minutos gratuitos a cada mês, e o uso além deles é cobrado pela tarifa por minuto do tamanho que você usa.

Cada plano inclui seats: o Developer é de um único seat, sem membros de equipe, o Launch inclui 3 seats e o Scale inclui 5. No Launch e no Scale você pode adicionar seats por $5/month cada, para que toda a sua equipe de engenharia possa acessar o dashboard e os insights.

Para ativar mais repositórios do que seu plano permite, faça upgrade para um plano maior na página de cobrança do dashboard e depois ative os novos repositórios. Você pode fazer upgrade a qualquer momento.

Os minutos gratuitos são redefinidos no primeiro dia de cada mês civil e são contados em unidades equivalentes ao small, de modo que um minuto em um runner maior consome mais da franquia do que um minuto no latchkey-small. Depois de usados, os minutos de runner adicionais são medidos pela tarifa por minuto do tamanho de runner que você usa. Se você estiver em um teste sem cartão, novos jobs de runner ficam bloqueados até que você adicione uma forma de pagamento.

Se você tiver uma forma de pagamento cadastrada, sua assinatura é convertida automaticamente para o plano que você escolheu, com a cobrança tratada de forma segura pelo Stripe. Se você começou sem cartão, o Latchkey solicita que você assine: escolha qualquer plano no dashboard e continue de onde parou. Seus dados são mantidos em qualquer um dos casos.

Desativar um repositório arquiva seus dados em vez de excluí-los. Cancelar sua assinatura mantém seus dados, para que você possa retomar de onde parou se voltar, e você pode solicitar a exclusão completa dos dados a qualquer momento.

Para repositórios públicos, sim: os runners padrão hospedados no GitHub são gratuitos, sem limite de minutos, e os runners self-hosted são gratuitos em qualquer repositório. Para repositórios privados existe uma cota mensal e você paga pelo excedente, então "gratuito" depende de o seu código ser público. O Latchkey cobra por minuto em qualquer repositório, com 2.000 a 6.000 minutos gratuitos em equivalente small por mês conforme o plano.

A cota mensal publicada pelo GitHub para repositórios privados é de 2.000 minutos no plano Free, 3.000 no Pro e no Team e 50.000 no Enterprise Cloud, além de 500 MB a 50 GB de armazenamento de artefatos conforme o plano e um cache do Actions de 10 GB por repositório em todos os planos. Repositórios públicos não são medidos. Os números vêm da documentação de cobrança do GitHub.

A tarifa de tabela publicada pelo GitHub para um runner Linux padrão de 2 núcleos x64 é de $0,006 por minuto, cobrada apenas em repositórios privados depois que a cota do plano se esgota. Runners maiores e outros sistemas operacionais custam mais. Um job small do Latchkey, em uma VM Linux comparável de 2 vCPU / 8 GB, custa $0,0025 por minuto.

O GitHub não cobra nada por runners self-hosted, então a linha por minuto desaparece e o custo migra para a sua conta de nuvem e para os seus engenheiros: instâncias ociosas entre jobs, atualização de AMIs, ajuste do autoscaler e uma revisão de segurança das máquinas que fazem checkout do seu código. Calcule os dias de engenharia junto com as horas de instância; é com esse total que uma plataforma de CI gerenciada compete, não com o zero da fatura do GitHub.

Sim. Depois que a cota do plano se esgota, o GitHub cobra minutos adicionais pela tarifa por minuto publicada, dentro de um limite de gastos que você define, de modo que a conta acompanha o uso em vez de interromper o build. Outra opção é rodar esses jobs no Latchkey, a partir de $0,0025 por minuto: faça commit deles como um arquivo de workflow do Latchkey CI, ou mantenha o workflow e mude a linha runs-on: com o Latchkey on GH.

Sim, para o Latchkey CI: conecte uma conta pessoal, selecione o repositório no dashboard, faça commit de um arquivo de workflow em .latchkey/workflows/ e dê push. O Latchkey on GH (os runners gerenciados do Latchkey no GitHub Actions) exige uma organização do GitHub que seja proprietária dos repositórios.

Seu código passa pelo Latchkey para ser executado, e parte dele fica guardada por um tempo. No Latchkey CI, cada job clona seu repositório na própria VM, que é destruída ao fim do job. O latchkey run envia sua working tree como contexto do job, excluída quando o job termina, ou por uma expiração de 2 dias se essa exclusão falhar. Uma entrada de cache que um job salva fica guardada por 14 dias, e um artefato que um job envia com o latchkey artifact, por 7 dias após o envio. Os logs dos jobs ficam guardados por 7 dias. Quando a autocorreção grava um registro de uma etapa com falha, esse registro guarda a saída da etapa, e o que a autocorreção leu dos seus arquivos, por 90 dias. O conteúdo dos arquivos das correções propostas fica guardado por 365 dias. As únicas escritas do GitHub App em um repositório são pull requests que você revisa e faz merge.

No Latchkey CI, o pull request de um fork espera até que um mantenedor aprove aquele commit exato, pelo check ou pela página da execução, a menos que o autor já tenha acesso de escrita. Depois ele roda em um sandbox que só alcança o GitHub e os principais registries de pacotes, sem secrets, sem token, sem cache e sem autocorreção. O arquivo de workflow é lido do seu repositório, não do fork, e forks de repositórios privados nunca rodam. No Latchkey on GH, pull requests de forks seguem as regras do próprio GitHub.

No Latchkey CI, adicione secrets no dashboard em Settings > Secrets, para todo o workspace, para um repositório ou para um ambiente de um repositório; o valor do ambiente prevalece sobre o do repositório, e o do repositório sobre o do workspace. Eles são criptografados com uma chave por workspace e mascarados nos logs, e uma etapa lê um secret como ${{ secrets.NAME }} no seu env:. Um job só lê os secrets de um ambiente depois que a execução dele é aprovada para esse ambiente, ou em uma execução nas branches dele quando o ambiente não precisa de aprovação. Pull requests de forks nunca os recebem. No Latchkey on GH, seus secrets do GitHub Actions funcionam como hoje.

Sim, o Latchkey funciona com repositórios públicos e privados no GitHub.com. No entanto, instâncias on-premise do GitHub Enterprise Server não são suportadas no momento.

O dashboard do Latchkey é somente para desktop por enquanto. Notificações do Slack e push do navegador mantêm você informado longe da sua mesa, mas o dashboard em si é feito para navegadores de desktop.

Ainda não. O Latchkey executa o pipeline por conta própria, e o GitHub é o primeiro host de código ao qual ele se conecta: seu código e seus pull requests ficam onde estão, e o Latchkey reporta o resultado neles. Outros hosts de código estão no nosso roadmap.