Monorepo y multirepo: definiciones sin falsas equivalencias
| Criterio | Monorepo | Multirepo |
|---|---|---|
| Cambios transversales | Un commit o PR puede cubrir varios proyectos | Normalmente varios repositorios, versiones y PR |
| Dependencias | Centralización y reglas comunes más sencillas | Mayor independencia de versiones |
| CI | Requiere selección por grafo, caché y escalado | Alcance natural menor por pipeline |
| Acceso | Ownership por rutas mediante reglas y revisiones | Aislamiento natural a nivel de repositorio |
| Tooling | Más estándares compartidos | Más libertad por proyecto |
| Releases | Pueden ser independientes pero requieren orquestación | Pipelines naturalmente separados |
Un monorepo es un repositorio que contiene varios proyectos lógicamente separados, como aplicaciones, servicios, bibliotecas o herramientas. Multirepo, también llamado polyrepo, mantiene esos elementos en repositorios separados. Los límites del repositorio son límites de gestión del código fuente, no necesariamente límites de despliegue. [1][13][15]
Por tanto, un monorepo puede contener muchos servicios desplegados de forma independiente, mientras que un entorno multirepo puede contener módulos de un único sistema grande. Confundir la estrategia de repositorios con monolito o microservicios conduce a malas decisiones de arquitectura.
Lo que muestra la investigación de Google: ambos modelos tienen ventajas reales
La investigación de Google con ingenieros que habían trabajado con ambos modelos identificó la visibilidad de toda la base de código como una ventaja importante del monorepo. Facilita descubrir API reutilizables, encontrar ejemplos y actualizar código dependiente durante migraciones. También se valoró la gestión centralizada de dependencias. [1]
El mismo estudio señala ventajas de multirepo: mayor libertad de toolchain, límites de acceso más fuertes y mayor estabilidad entre proyectos. Los autores también destacan que la calidad de las herramientas alrededor del repositorio influye mucho en la experiencia. [1]
Cambios transversales: la ventaja práctica más clara del monorepo
Si un cambio de interfaz exige actualizar backend, frontend, bibliotecas y pruebas al mismo tiempo, un monorepo puede contener toda la migración en un commit o pull request. Google cita la actualización automática del código dependiente durante migraciones de API como una ventaja importante. [1][2]
En multirepo, el mismo cambio suele convertirse en una secuencia: modificar el productor, publicar una versión, actualizar consumidores y coordinar varios pull requests. La automatización reduce la fricción, pero los límites de repositorio siguen siendo límites del proceso de integración.
Dependencias y versiones: centralización frente a independencia
Los monorepos facilitan alinear versiones comunes y referenciar paquetes locales directamente. Yarn Workspaces conecta paquetes dentro de un proyecto, mientras que Constraints puede imponer reglas de versiones o de `package.json` en todo el workspace. [13][14]
Multirepo da a cada proyecto más libertad sobre versiones y calendario de actualizaciones, pero las bibliotecas comunes pueden divergir entre repositorios. Funciona bien cuando los contratos son estables y los artefactos se publican mediante registries controlados.
CI en monorepo: reconstruir todo en cada commit es el enfoque equivocado
Un monorepo grande no debería ejecutar todos los tests y builds después de cada cambio. Nx `affected` usa el historial de Git y el grafo de proyectos para calcular el conjunto mínimo afectado y omitir trabajo no relacionado. [4]
La caché remota comparte resultados ya calculados entre equipos y CI, mientras que la ejecución distribuida reparte las tareas restantes entre varias máquinas. Bazel aborda el mismo problema mediante ejecución remota y caché para acciones de build y test. [5][7][8]
CI en multirepo: un alcance menor no elimina la coordinación
En multirepo, un pipeline individual ve naturalmente menos código, por lo que es más fácil limitar build y pruebas a un proyecto. Es una ventaja real cuando los servicios están poco acoplados y pertenecen a equipos distintos.
El coste aparece cuando existen dependencias entre repositorios. Un cambio en una biblioteca o contrato compartido puede exigir publicación, actualizaciones en varios repositorios, compatibilidad de versiones y pruebas de integración. Google destaca estabilidad en multirepo y visibilidad y migraciones en monorepo. [1]
Límites arquitectónicos: un monorepo sin reglas se degrada rápido
Un repositorio compartido no debe permitir imports libres entre todos los proyectos. Nx puede imponer límites de módulos con tags y restricciones de dependencias, bloqueando imports no deseados y acoplamiento no planificado. [6]
En multirepo, algunas fronteras existen físicamente porque el código está en repositorios separados. Aun así, eso no sustituye la arquitectura: puede haber fuerte acoplamiento mediante API, bases de datos, colas o bibliotecas compartidas.
Acceso y seguridad: multirepo suele tener el modelo más sencillo
GitHub asigna roles y permisos a nivel de repositorio. Los repositorios separados encajan de forma natural cuando equipos o contratistas deben ver bases de código diferentes. Los roles van desde Read hasta Admin. [11]
En monorepo, CODEOWNERS y rulesets pueden exigir revisiones para rutas y equipos concretos, pero son mecanismos de ownership y aprobación. Si se necesita separación estricta de visibilidad, los repositorios privados separados suelen encajar mejor con el modelo de acceso. [10][12]
Releases y despliegues: un repositorio no significa un release
Yarn describe workspaces como varios paquetes dentro de un proyecto y señala expresamente que pueden desplegarse de forma independiente. Los multi-project builds de Gradle también dividen el sistema en subproyectos lógicos con sus propias dependencias y tareas. [13][15]
Por tanto, un monorepo puede tener pipelines y versiones separadas para aplicaciones, servicios y bibliotecas. Multirepo ofrece esta separación de forma más natural, pero necesita más automatización cuando varios releases deben coordinarse como un único cambio de producto.
Tamaño del repositorio y Git: los monorepos muy grandes requieren herramientas específicas
Google ha descrito un monorepo interno con miles de millones de líneas de código, pero también ha subrayado la infraestructura personalizada utilizada. El ejemplo demuestra que un monorepo puede escalar mucho, no que esa escala sea gratuita o adecuada para cualquier empresa. [2]
Git actual ofrece `sparse-checkout` para reducir el working tree a un subconjunto de archivos. Es útil con repositorios grandes, aunque la documentación de Git sigue marcando su comportamiento como experimental y sujeto a cambios. [9]
Las herramientas de 2026 reducen el coste de ambos enfoques
En JavaScript existen workspaces nativos y herramientas maduras de grafos, caché y CI solo sobre proyectos afectados. En JVM, Gradle admite multi-project builds y los composite builds permiten combinar builds independientes y desarrollarlos juntos sin publicar antes artefactos. [13][15][16]
Esto también importa en multirepo: repositorios separados no tienen por qué implicar un entorno local completamente desconectado. Los composite builds muestran cómo conservar límites independientes y probar proyectos conjuntamente. [16]
Los agentes de código IA añaden un nuevo criterio en 2026
La documentación de Nx de 2026 sostiene que los agentes se benefician del contexto completo del monorepo, un grafo de proyectos consultable, verificación rápida de lo afectado y límites automáticos. Como Nx es proveedor de tooling monorepo, debe tratarse como perspectiva de producto, no como prueba independiente. [3]
En la práctica, el contexto compartido puede ayudar a un agente a cambiar un contrato y sus consumidores en una sola tarea. Por otro lado, multirepo puede reducir el código y permisos disponibles para una sesión del agente. Es un criterio adicional, no un argumento definitivo.
Cuándo elegir monorepo
Monorepo es especialmente adecuado cuando aplicaciones y bibliotecas cambian juntas con frecuencia, muchos equipos comparten componentes y hacen falta refactorizaciones atómicas y un grafo de dependencias visible. La investigación de Google respalda estas ventajas mediante visibilidad, descubrimiento de API, ejemplos, migraciones y centralización de dependencias. [1]
La condición es invertir en límites de módulos, CI selectiva, caché, ownership y automatización. Sin esos controles, el crecimiento solo traslada la complejidad a un pipeline enorme. [4][5][6]
- Cambios frecuentes entre frontend, backend y bibliotecas.
- Mucho código compartido y estándares comunes.
- Necesidad de refactorizaciones atómicas.
- Toolchain unificada o compatible.
- Disposición a invertir en grafo, caché y CI selectiva.
- Sin necesidad estricta de ocultar la mayor parte del código a otros equipos internos.
Cuándo elegir multirepo
Multirepo es una opción fuerte cuando los dominios tienen límites claros, los equipos necesitan toolchains, ciclos de vida y permisos independientes y los cambios transversales son poco frecuentes. Google identifica flexibilidad de herramientas, control de acceso y estabilidad como ventajas significativas. [1]
Otra señal es la existencia de código con visibilidad restringida, requisitos de compliance separados o grupos distintos de contratistas. El modelo de roles por repositorio de GitHub soporta esta separación directamente. [11]
- Gran autonomía de equipos y ciclos de vida separados.
- Lenguajes, toolchains y procesos de build distintos.
- Requisitos estrictos de acceso o compliance.
- Pocos cambios que afecten a muchos proyectos.
- Contratos estables y gestión madura de versiones.
- Los pipelines independientes importan más que un grafo global de plataforma.
Modelo híbrido y decisión práctica en 2026
| Situación | Dirección por defecto | Por qué |
|---|---|---|
| Cambios frecuentes en varias apps y bibliotecas | Monorepo | Refactorizaciones atómicas y grafo común |
| Equipos que no deben ver todo el código | Multirepo | Permisos por repositorio simplifican el aislamiento |
| Toolchains y ciclos de vida diferentes | Multirepo | Menos estandarización central |
| Plataforma y bibliotecas muy compartidas | Monorepo | Mejor visibilidad y centralización |
| Muchos servicios pequeños | Depende | Importa más la frecuencia de cambios compartidos que el número de servicios |
| Requisitos mixtos de dominio, acceso y tecnología | Híbrido | Monorepos por dominio más repositorios separados seleccionados |
La elección no tiene que ser binaria. Una organización puede mantener monorepos por dominio para productos muy relacionados, repositorios separados para componentes sensibles o específicos de clientes y paquetes compartidos publicados en registries. Los composite builds de Gradle muestran incluso cómo desarrollar juntos builds independientes. [16]
Antes de migrar conviene medir frecuencia de cambios transversales, número de dependencias compartidas, duración de CI, cantidad de repositorios tocados por una funcionalidad típica, requisitos de acceso y coste de coordinar releases. Esos datos deberían decidir la topología.
