Repositórios Git privados
Repositórios privados para o time, com o fluxo Git que os desenvolvedores já usam.
Plataformas gerenciadas · Código-fonte
A LFC Sistemas oferece uma plataforma de gestão de código-fonte com repositórios Git privados e CI/CD integrado — como SaaS gerenciado dedicado ou instalada on-premise, na sua infraestrutura. O código do seu time, sob o seu controle.
Recursos
Um lugar só para código, revisão e entrega — sem depender de plataforma pública para manter o time trabalhando.
Repositórios privados para o time, com o fluxo Git que os desenvolvedores já usam.
Pipelines de build, teste e entrega acionados por push e pull request, na própria plataforma.
Pull requests com revisão, discussão e aprovação antes do merge.
Organizações, times e níveis de acesso por repositório — quem vê e quem escreve, sob controle.
Registro de tarefas, bugs e marcos junto do código, sem ferramenta extra.
API e webhooks para conectar a plataforma ao restante do seu fluxo de trabalho.
Para quem é
Se alguma destas situações descreve a sua semana, o problema que a plataforma resolve é o seu.
Oferta
A mesma plataforma, dois jeitos de rodar: no ambiente que a LFC Sistemas opera, ou dentro da sua própria infraestrutura.
A plataforma roda em ambiente dedicado, implantado e operado pela LFC Sistemas. Para times que querem sair da plataforma pública sem assumir a operação.
A plataforma instalada na sua infraestrutura, nos seus servidores. Para empresas com requisito de manter código-fonte dentro de casa.
Riscos
As plataformas públicas de código são excelentes — até o dia em que o incidente é delas e o prejuízo é seu. Indisponibilidade e vazamento de segredos de CI são eventos documentados, recorrentes e fora do seu controle. Os fatos abaixo são públicos, com fonte.
24h11min
de degradação no GitHub em um único incidente (out/2018), com cerca de 200 mil webhooks descartados.
4 outages em 8 dias
no GitHub em março/2022 — no primeiro deles, todas as operações de escrita pararam: git, PRs, API, Actions.
FONTE: GitHub, An update on recent service disruptions, 2022
81%
dos outages públicos rastreados em 2022 foram causados por operadores terceirizados (cloud, hosting, telecom).
Cada item traz data, o que aconteceu e o link para a fonte primária. Recolhido para não ocupar a página — abra se quiser conferir.
05/2026
O dispositivo de um funcionário foi comprometido por uma extensão de terceiro envenenada (Nx Console), e o atacante exfiltrou repositórios internos do GitHub — ~3.800, número reivindicado pelo atacante e considerado “directionally consistent” pela investigação. Sem evidência de impacto em repositórios de clientes, mas a resposta exigiu rotação de segredos críticos e da chave de assinatura do GitHub Enterprise Server. Segundo a imprensa, o grupo TeamPCP pôs os dados à venda a partir de US$ 50 mil.
jan/2023
Malware no laptop de um engenheiro roubou uma sessão autenticada (contornando o 2FA) e deu acesso a sistemas de produção com segredos de clientes. A empresa pediu a rotação de todo e qualquer segredo armazenado: variáveis de ambiente, tokens OAuth e de API, chaves SSH.
abr/2022
Tokens de usuário emitidos para dois integradores terceiros (Heroku e Travis CI) foram roubados e usados para baixar repositórios privados de dezenas de organizações, incluindo a npm. O elo fraco não foi o GitHub — foi a cadeia de terceiros conectada a ele.
FONTE: GitHub Security Alert, 2022
mar/2022
Contenção de recursos no cluster de banco principal derrubou o serviço 4 vezes entre 16 e 23 de março (5h36, 2h28, 2h53 e 2h51). No primeiro incidente, nenhuma operação de escrita funcionava: git, webhooks, pull requests, API, Actions, Pages.
FONTE: GitHub, 2022
31/01/2017
Um engenheiro apagou por engano o diretório de dados do banco primário. Dos 5 mecanismos de backup/replicação, nenhum funcionava de forma confiável; o último backup viável tinha 6 horas. ~5.000 projetos afetados no banco (issues, merge requests).
FONTE: GitLab Postmortem, 2017 (via The Register) · GitLab, postmortem oficial, 2017
Perguntas frequentes
Sim, e sem depender de nenhum recurso de exportação nosso. Repositório de código é distribuído por natureza: cada cópia que o time já tem na máquina contém o histórico completo. Apontar essa cópia para outro destino é operação padrão da própria ferramenta de versionamento — não há formato proprietário no meio.
No on-premise, nada: a plataforma roda na sua infraestrutura e continua funcionando sem nenhuma participação nossa. No SaaS, cada cópia local do time segue sendo um histórico completo, o que já elimina o risco de perda do código — mas o prazo e o processo formais de transição são acertados em contrato, e não temos uma cláusula padrão publicada aqui.
No SaaS, o ambiente é dedicado ao seu time, e o nosso acesso é o necessário para operar a plataforma: implantar, atualizar e monitorar. No on-premise, o código não sai da sua infraestrutura e o acesso é apenas o que você conceder para suporte.
Hoje não. Preferimos não publicar um número que não esteja sustentado por contrato — a mesma regra que aplicamos a qualquer estatística deste site. Compromisso de disponibilidade é acertado caso a caso. O que vale desde já: quem responde quando algo quebra é quem opera a plataforma, sem central terceirizada no caminho.
No SaaS, a plataforma roda em ambiente dedicado que a LFC implanta e opera — você não lida com servidor. No on-premise, a mesma plataforma é instalada na sua infraestrutura: a instalação e a configuração são nossas, o hardware e a operação diária são seus.
Mover o conteúdo é a parte simples, porque o formato é aberto. O trabalho real costuma ser recriar permissões por equipe e as automações de entrega. Isso é levantado na conversa inicial, antes de qualquer proposta — o prazo depende do número de repositórios e de integrações, e não teria sentido publicar um número fixo aqui.
Conte como seu time trabalha hoje e nós apresentamos o modelo — SaaS dedicado ou on-premise — que faz sentido para o seu caso.
Chamar no WhatsAppConversa direta com quem opera a plataforma. Sem robô de atendimento.