A contractor, a nearshore engineer, or an agency hire working a single three-month contract doesn't need the same repository access as someone who's been on payroll for four years. Repo architecture decides how hard that distinction is to enforce. Once part of a team is external, monorepo vs polyrepo is an access-control question before it's a build-speed question.
What's the actual difference between a monorepo and a polyrepo
A monorepo keeps every project, service, and package in a single version-controlled repository, with one commit history and one set of CI pipelines shared across everything inside it. A polyrepo splits that same code across as many repositories as there are projects, each with its own history, CI config, and release cadence. Nx's guide to monorepo and polyrepo tooling tradeoffs frames the practical difference in terms of who can touch what: a monorepo relies on "per-folder ownership rules" inside one repository, while a polyrepo hands each team "repository-level permissions per team" instead.
Scale is where the two models diverge hardest, and Google is the standard reference case for it. Buildkite's monorepo vs polyrepo comparison puts a number on it: "Google stores billions of lines of code in a single repository used by 95% of its developers." That's a monorepo running at a size almost no company outside Google will ever hit, and Buildkite names the cost of running one at any real scale: "Cloning a Git monorepo can be glacially slow, and build times can be frustratingly upwards of an hour," sometimes running to several hours or overnight.
Monorepo vs polyrepo: access control compared
Access matters more than build speed once part of a team is external. Spacelift's monorepo vs polyrepo comparison states the monorepo risk plainly: "When all projects live in one repository, developers can access everything you've created," including projects they never touch. The same page names why that's hard to fix after the fact: "Implementing precise access-control guardrails can be challenging, so monorepos may be unsuitable for teams with stringent security requirements."
A polyrepo flips the default. Spacelift again: using multiple repositories "enables each repository to have its own fine-grained access controls, permissions, and deployment policies," which "allows you to reliably enforce required security and compliance requirements, including when some projects must be restricted to specific developers." Buildkite's read on isolated repositories and identity management makes the same point from a different angle: "Isolated repositories make granular identity management and access possible, restricting access to a smaller subset of users," where a monorepo's contributors are usually the whole engineering team.
| Factor | Monorepo | Polyrepo |
|---|---|---|
| Default access | Org-wide by default, scoped by folder rules layered on top | Scoped by the repository boundary itself |
| Fine-grained control | Requires CODEOWNERS and role assignment to restrict by path | Native to the model, one repository per team or project |
| Review gating | Ownership rules define who must approve which folders | A repository role often covers it without extra rules |
| First-day setup | One clone, one CI config, everything visible at once | Multiple repositories to clone and configure before shipping |
How to set repo access when some of your engineers are external
1. Default a new contractor to scoped access, not full write
GitHub defines five repository roles inside an organization, and the design already assumes not everyone needs the same level of access. GitHub's documentation on repository roles for an organization describes Read as "Recommended for non-code contributors who want to view or discuss your project," and Triage as a step up, "Recommended for contributors who need to proactively manage issues, discussions, and pull requests without write access." Write is the first tier that can push code, "Recommended for contributors who actively push to your project." Maintain goes to "project managers who need to manage the repository without access to sensitive or destructive actions," and Admin is reserved for people who need "full access to the project, including sensitive and destructive actions like managing security or deleting a repository."
A contractor on a three-month engagement rarely needs more than Write. Save Maintain and Admin for people who'll still be answering for the repository next year.
2. Use CODEOWNERS to gate review, not commit access
Repository roles decide who can push. CODEOWNERS decides who has to approve before that push merges, and the two solve separate problems. GitHub's documentation on code owners defines it directly: "You can use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository." Once that file names an owner, "Code owners are automatically requested for review when someone opens a pull request that modifies code that they own," and an organization can go further: "When someone with admin or owner permissions has enabled required reviews, they also can optionally require approval from a code owner before the author can merge a pull request in the repository."
That second setting is what protects a repository with mixed staffing. A contractor with Write access can open a pull request against any folder in a monorepo; a required CODEOWNERS approval stops it from merging until someone who owns that folder signs off. GitHub's one constraint worth planning around: "The people you choose as code owners must have write permissions for the repository," so the owner has to be someone you'd already trust with that access.
joelparkerhenderson's public comparison of monorepo and polyrepo tooling names the same mechanism in one line: GitLab and GitHub "offer ownership control where you can say who owns what directories for things like approving merge requests that affect those directories(using CODEOWNERS)." That line doesn't get into the follow-through: deciding CODEOWNERS applies specifically to contractors and nearshore engineers, regardless of who happens to own the folder already. That's the same question HighCircl's guide to who holds review authority on a blended team answers for code review, and it applies just as directly to repository setup.
3. Match the repo model to your access requirement, not your team's habit
A team can pick polyrepo because compliance requires per-repository scoping, or pick monorepo because most engineers already need visibility into most of the code, then work backward from CODEOWNERS and repository roles to patch whatever gap the choice created. That sequence works. What's worth avoiding is defaulting to monorepo because it's what the team has always used, then discovering later that scoping a single contractor's access means bolting ownership rules onto folders nobody organized with that in mind. Decide the access requirement first: does this engineer need to see the whole codebase to do the job, or only the service they were hired for. That answer sets the repo model.
4. Write the decision down as an ADR
Whichever model gets picked, the reasoning behind it is worth keeping somewhere a new engineer, in-house or external, can find it without asking around. HighCircl's guide to recording the decision as an ADR covers the format: a short record with the context, the decision, and the consequences. A one-page version that names the access requirement behind a repo choice saves a repeat argument the next time someone asks why a service lives in its own repository instead of the shared one.
5. Revisit the decision at your scaling threshold
The same comparison's monorepo scaling thresholds name the point where the tooling starts to strain, rather than leaving it vague: "Monorepo scaling seems to become an issue, in practice, at approximately these kinds of metrics: 10-100 developers writing code full time. 10-100 projects in progress at the same time... 1M-10M lines of code."
A team with two contractors and a handful of in-house engineers isn't near that range. A team that's added enough augmented and nearshore engineers to clear it is a different conversation. At that scale, the CODEOWNERS rules and role assignments from steps 1 and 2 are what keep working, regardless of whether the repo stays a single monorepo or gets split apart.
Onboarding time: what changes for a new or nearshore engineer
Repo choice also changes how much setup a new engineer needs before their first pull request, on top of who can see what once they're in. Spacelift's note on polyrepo onboarding overhead names the polyrepo cost directly: "With polyrepos, new developers need to clone and configure multiple repositories and their dependencies before they can become productive."
For a nearshore or contract engineer starting a three-month engagement, that setup time is a bigger share of the whole contract than it is for someone staying two years. A monorepo trims it: one clone, one dependency tree, one CI config to learn, even if it means the org-wide access problem from the comparison above now needs solving with CODEOWNERS and scoped roles instead of repository boundaries. It's the same tradeoff HighCircl's guide to how a blended team splits architecture sign-off makes for code review authority: scope what an engineer can decide, don't restrict which seat they're allowed to sit in.
When to choose monorepo, when to choose polyrepo
The decision comes down to which cost a team would rather manage. Monorepo trades faster onboarding and shared tooling for a bigger access-control job. Polyrepo trades slower onboarding for access that's scoped by the repository boundary from day one. A team where every engineer, in-house or external, works across most of the codebase leans monorepo, with CODEOWNERS and repository roles doing the access work. A team hiring contractors for one clearly bounded service, and keeping them bounded to it, leans polyrepo, because the repository boundary already does the scoping without extra tooling.
Migrating an existing estate, folding a polyrepo into one repository or splitting a monorepo apart, is its own project with its own cost. It fits the same sign-off process HighCircl's guide to budgeting the migration as its own technical debt line lays out for any other structural rewrite: name an owner, price it, and get sign-off before it starts, rather than squeezing it into a sprint that was already committed to something else.
Frequently asked questions
Does a monorepo make it harder to give a contractor limited access?
Yes, by default. A monorepo's baseline is that anyone with access can see and often touch the whole codebase, which is why Spacelift calls implementing precise access-control guardrails "challenging" for monorepos with strict requirements. It's fixable with CODEOWNERS-gated review and scoped repository roles, but that's extra setup a polyrepo doesn't need, since access is already split at the repository boundary.
What's the difference between CODEOWNERS and GitHub repository roles?
Repository roles, Read, Triage, Write, Maintain, Admin, set what someone can do across a repository: view it, comment on it, push to it, manage it, or administer it. CODEOWNERS sits on top of that: it names who has to approve a pull request that touches a specific file or folder, and GitHub can make that approval mandatory before anyone merges. A contractor can hold Write access and still need a code owner's sign-off before anything they push actually lands.
Should a blended in-house and nearshore team default to polyrepo?
Not automatically. Default to polyrepo when contractors are hired for one bounded service and don't need visibility into the rest of the codebase; the repository boundary does the access scoping for free. Default to monorepo, paired with CODEOWNERS and repository roles, when engineers, in-house or external, genuinely need to work across shared code, since splitting that code into repositories they'd still need write access to solves nothing.
At what size does monorepo access control actually break down?
joelparkerhenderson's comparison puts the strain point at roughly 10-100 developers writing code full time, 10-100 projects in progress at once, and 1M-10M lines of code, among the other thresholds it lists in that range. Below that, folder-level CODEOWNERS rules and scoped repository roles hold up fine. Past it, the tooling and the review load both start to strain, and splitting into multiple repositories becomes a live conversation instead of a hypothetical one.