Monorepo não é bala de prata. É uma decisão de arquitetura com trade-offs claros que dependem do tamanho e maturidade do time, não da popularidade da abordagem.
Monorepo virou assunto recorrente depois que empresas como Google, Meta, Microsoft e Vercel tornaram públicas suas estruturas de repositório. Em paper publicado pela ACM (“Why Google Stores Billions of Lines of Code in a Single Repository”, 2016), o Google revelou números que ajudaram a popularizar o modelo: cerca de 1 bilhão de arquivos, 35 milhões de commits, 86 TB de código, usado por 95% dos engenheiros da empresa.
A pergunta que ficou foi: se funciona pra eles, deveria funcionar pra mim também?
Não é tão simples. Pesquisas recentes do ecossistema mostram que 63% das empresas com mais de 50 desenvolvedores adotaram monorepo até 2025. Mas o número também mostra o outro lado: 37% das empresas grandes optaram por não adotar, e times menores frequentemente erram ao copiar a estrutura sem ter o problema que monorepo resolve.
Quando múltiplos projetos compartilham código, um design system, uma biblioteca de utilitários, tipos TypeScript compartilhados, monorepo elimina a dança de publicar pacotes, atualizar versões e sincronizar mudanças entre repositórios separados.
Em times onde front-end e back-end de um mesmo produto são desenvolvidos juntos, monorepo permite mudanças de API e interface na mesma pull request, com o CI validando ambos simultaneamente. Refatorações que atravessam vários projetos também ficam atômicas: ou tudo passa, ou nada passa.
Esses benefícios são reais. Mas pressupõem que o time tem disciplina para manter o repositório organizado e ferramentas adequadas para lidar com builds incrementais em um repositório grande. Foi por isso que Google construiu o Bazel, Meta construiu o Buck, e Twitter abriu o código do Pants em 2012. Sem build system inteligente, monorepo grande vira lentidão.
Em times pequenos ou em projetos independentes sem código compartilhado, monorepo adiciona complexidade sem retorno proporcional.
Operações de Git ficam mais lentas conforme o repositório cresce, especialmente se ele inclui binários grandes (mídia, modelos ML, artefatos compilados). Controle de acesso fica mais complicado: em vez de permissões por repositório, é preciso configurar restrições por pasta, o que dificulta trabalho com contratados externos ou equipes distribuídas.
CI fica mais complexo também. É preciso garantir que apenas os projetos afetados por uma mudança sejam testados e deployados, o que exige configuração de ferramentas como Turborepo, Nx ou Bazel. Onboarding de novos desenvolvedores fica mais lento quando o repositório tem dezenas de projetos misturados e a navegação inicial confunde mais do que orienta.
Não existe “a ferramenta certa de monorepo”. Existem três famílias claras, cada uma resolvendo um problema diferente:
Turborepo, adquirido pela Vercel em 2021 e reescrito em Rust em 2023, funciona como task runner com cache inteligente para workspaces JavaScript e TypeScript. É a escolha mais natural para times de 5 a 50 pacotes que querem CI mais rápido sem reestruturar o repositório existente. Configuração mínima, integração nativa com pnpm/npm/yarn, e cache remoto via Vercel.
Nx (Nrwl), em uso desde 2019, é uma plataforma de monorepo, não apenas um task runner. Entende o grafo completo do projeto, oferece geradores de código, comandos “affected” precisos (só roda testes do que foi afetado pela mudança), e impõe regras de fronteira entre módulos. Faz sentido para times maiores com estrutura que se beneficia de convenções claras. Está sendo migrado para Rust também.
Bazel (Google, open source desde 2015) é build system para repositórios massivos, poliglotas, com requisitos de reprodutibilidade hermética. Builds completamente isolados do ambiente do host, execução remota, suporte a múltiplas linguagens. Não faz sentido pra time pequeno: o esforço de configuração só compensa em escala muito grande, com investimento em engenharia de build.
Steve Kinney resumiu a distinção de forma útil em material publicado em 2026: Turborepo é a escolha padrão quando o problema é “builds rápidos pra workspace JavaScript/TypeScript”, Nx é melhor quando o problema é “a gente precisa de uma plataforma de monorepo, não apenas um task runner”, e Bazel é o que se usa quando o repositório é grande, poliglota e a correção do build justifica a complexidade real.
A decisão não é “monorepo é boa prática?”. É “qual problema a gente está tentando resolver?”.
Se a resposta é “compartilhar código entre projetos com versionamento controlado”, monorepo pode ser a resposta certa. Se a resposta é “queremos centralizar tudo em um lugar”, isso é organização, não arquitetura, e pode ser resolvido de formas mais simples (workspace pnpm, por exemplo, dá quase todos os benefícios de compartilhamento de código sem precisar de Turborepo ou Nx).
Adotar monorepo porque é o que grandes empresas fazem é o mesmo erro de adotar microsserviços porque é o que grandes empresas fazem. A escala do problema precisa justificar a complexidade da solução. Google tem 86 TB de código e 95% dos engenheiros trabalhando num só lugar porque resolveu construir o Bazel e o Piper (sistema de controle de versão próprio) pra suportar isso. Time de 4 desenvolvedores com 3 aplicações relacionadas precisa de muito menos que isso.
Em projetos da VM2, a gente avalia o uso de monorepo caso a caso. Quando o cliente tem um design system compartilhado entre múltiplas aplicações, ou quando front-end e back-end vão ser desenvolvidos pela mesma equipe com mudanças sincronizadas, monorepo costuma fazer sentido. Quando os projetos têm equipes separadas, ciclos de release diferentes e quase nenhum código em comum, repositórios separados são mais simples e mais rápidos.
A escolha de ferramenta também depende do contexto. Pra workspaces JavaScript/TypeScript de tamanho médio, Turborepo costuma resolver com pouca cerimônia. Pra estruturas que vão crescer e precisar de regras de arquitetura, Nx entra na conversa. Bazel, em projetos web típicos, raramente é a resposta certa.
O que a gente evita é a decisão tomada por moda. Monorepo virou termo de status no mundo de desenvolvimento, e isso atrapalha a conversa real sobre arquitetura. A pergunta que importa não é se está na moda, é se resolve o problema que existe agora, sem criar três problemas novos.
Fontes consultadas: Potvin & Levenberg, “Why Google Stores Billions of Lines of Code in a Single Repository”, Communications of the ACM (2016); documentação oficial de Turborepo, Nx e Bazel; Steve Kinney, “Turborepo versus Nx, Bazel, Lerna, and Friends” (2026); Wikipedia, verbete “Monorepo”.
Acessibilidade não é só obrigação legal. É a diferença entre uma plataforma que funciona para todos e uma que exclui parte do mercado silenciosamente.
A escolha de tecnologia para um projeto digital não começa pela tecnologia. Começa pela pergunta certa: o que essa plataforma precisa fazer?
36% das empresas gastam mais tempo resolvendo problemas de APIs do que desenvolvendo funcionalidades. O problema quase nunca é a API. É a documentação tratada como anexo, não como produto.
