Perguntas frequentes

Não. O Latchkey funciona apenas com contas de organização do GitHub; instalações em contas pessoais são rejeitadas e removidas automaticamente. Criar uma organização no GitHub é gratuito e leva um minuto.

Não. Developer e Launch iniciam um trial de 30 dias sem cartão. Scale passa pelo checkout com o trial aplicado.

A pessoa que instala o GitHub App. Há exatamente um dono por workspace, e a propriedade pode ser transferida a outro membro depois com Transfer Ownership. Veja Equipe e papéis.

Sim. Cada instalação recebe seu próprio workspace com seu próprio plano, equipe, repositórios e dados, e o alternador de workspace na barra lateral do painel move entre eles.

Sim. Se você pertence a vários workspaces, o alternador de workspace na barra lateral do painel move entre eles; cada workspace tem seu próprio plano, equipe e dados.

Não. Você pode pular a seleção de repositórios e adicionar repositórios depois pelo modal de Monitoramento do painel. Veja Gerenciando repositórios.

Ainda não: o painel é apenas para desktop, e navegadores de celular veem um aviso de bloqueio. Notificações por email, Slack e push cobrem você longe da sua mesa.

Apenas a linha runs-on:, e somente para os jobs que você escolher mover. Todo o resto permanece como está, e runners hospedados no GitHub continuam funcionando lado a lado.

Ubuntu 24.04 LTS em x86_64. Não há runners de Windows, macOS, arm64 ou GPU hoje; mantenha esses jobs em outros runners e misture livremente dentro de um workflow.

Sim, nativamente: Docker CE com BuildKit, buildx e compose vêm pré-instalados, incluindo QEMU para builds de imagem multi-arch.

Segundos quando um runner quente está disponível (Launch e Scale incluem capacidade de warm pool); cold starts levam cerca de 10 segundos, contra 30-60 segundos típicos para os hospedados no GitHub.

Até 4 horas por runner; a máquina é terminada em 4 horas mesmo que o job ainda esteja em execução. Limites completos em Limites e concorrência.

20 runners ocupados por workspace por padrão; runners quentes ociosos não contam, e limites mais altos estão disponíveis. Jobs além do teto aguardam por uma vaga.

Não. Runners são de uso único: um job por máquina, destruída depois, então qualquer coisa gravada no disco local se perde quando o job termina. Use artifacts ou caches para persistência.

Em AWS us-east-1, em máquinas Ubuntu 24.04 LTS x86_64. Veja Limites e concorrência.

Runners de configuração personalizada são cobrados à taxa xlarge ($0.0200/min), independentemente do seu formato. Veja Runners personalizados.

Sim: conecte-o ao servidor MCP do Latchkey com uma chave de API e ele poderá triar falhas, puxar pacotes de falha e conduzir correções a partir do seu editor. Veja Conecte seu agente de IA.

Não. Correções durante a execução só afetam o runner efêmero, que é destruído após o job. Correções duráveis são sempre propostas apenas como pull requests para sua revisão, e nada é mesclado automaticamente.

Sim: para todo o workspace em Settings, na seção Self-Healing (donos e admins), e por configuração de runner na página de Runners. Não há toggle por repositório hoje.

Não. Ela só intervém em classes transitórias conhecidas (rede, memória, disco, ferramentas ausentes, deriva de configuração). Falhas genuínas de código e de teste falham normalmente, e toda recuperação é registrada no feed Recent Heals.

Toda intervenção aparece no feed Recent Heals na página de Runners, com sua categoria, veredito e a ação tomada em linguagem simples. Execuções recuperadas também são sinalizadas na tabela de execuções de Pipeline Performance e levam por deep-link ao seu relatório de recuperação.

Não. As tentativas são limitadas por passo, o estágio de diagnóstico de IA tem um orçamento de tempo rígido de cerca de três minutos, e o próprio runner tem um limite de vida útil de 4 horas. Detalhes em Auto-recuperação.

Metadados de execução de workflow e de job, e seus arquivos YAML de workflow. Não o código-fonte da sua aplicação, e nunca segredos ou valores de variáveis de ambiente. Detalhes em Segurança e permissões do GitHub.

Desabilitar um repositório para a ingestão e arquiva seus dados. Cancelar bloqueia o acesso mas retém seus dados, então reassinar os restaura. Excluir o workspace o remove permanentemente.

Por minuto, arredondado para cima por job, a taxas por tamanho, após os minutos gratuitos do seu plano. Veja Uso de runners e minutos gratuitos.

No primeiro dia de cada mês do calendário. Minutos dentro da camada gratuita não custam nada; apenas o uso além dela é cobrado às taxas por minuto.

Com uma assinatura registrada não há limite rígido: os jobs continuam rodando e o excedente é medido na sua fatura, com avisos aos 80% e novamente aos 100% dos seus minutos incluídos. Em um trial sem cartão, novos jobs de runner gerenciado são bloqueados assim que os minutos gratuitos se esgotam, até você assinar.

A assinatura passa a Past Due: o acesso ao painel e à API é bloqueado e os lançamentos de runner param até que o método de pagamento seja corrigido no portal do Stripe. Seus dados não são afetados. Veja Gerenciando sua assinatura.

No portal do cliente Stripe: abra o modal de Cobrança e clique em Manage Billing. Faturas (com PDFs), métodos de pagamento e detalhes da assinatura são todos gerenciados ali.

Sim: Change Plan no modal de Cobrança faz upgrade ou downgrade no local. Fazer downgrade abaixo da sua contagem de repositórios monitorados pede que você escolha quais repositórios permanecem monitorados, e fazer downgrade para Developer exige que o workspace tenha apenas um membro. O trial não reinicia com uma mudança de plano.

Launch inclui 1 assento e Scale inclui 5; assentos extras custam $5/month cada. O plano Developer é para uso individual, então convites de equipe não estão disponíveis nele. Veja Equipe e papéis.

Não. Convites concedem Admin ou Member. Para entregar o workspace, o dono usa Transfer Ownership.

Você escolhe uma expiração entre 1 e 30 dias (7 por padrão) e um número máximo de usos. Convites podem ser revogados a qualquer momento na aba Pending Invites.