One repo per tool — is this overkill?

[xniperbuilds]

🏷️ Discussion Type

Question

Body

I've been doing this for a while: every small utility tool gets its own repo.
Not a monorepo, not subfolders — separate repo, separate GitHub Pages deployment.

What pushed me toward this:

• Each tool gets its own URL, issues, and release history
• GitHub Pages deploys cleanly with no routing setup
• Contributor permissions stay isolated

Where it starts to hurt:

• Shared components (like a nav bar) need updating in 10+ repos separately
• Issue triage gets scattered across repos fast
• No easy cross-repo search

Running this setup across all my tools at xnipertools.com — works fine at
this scale, but I can feel it getting harder to manage as the count grows.

Has anyone hit a repo count where this breaks down completely? And did you
migrate to a monorepo or find another way around it?

Guidelines

• I have read and understood this category's guidelines before making this post.

[avijit-990]

Hey there! @xniperbuilds ,

This is a super common wall to hit. The "one repo per tool" approach feels amazing at first because of the clean, isolated deployments, but as soon as you need a unified brand or shared UI components, it turns into an absolute maintenance nightmare.

Most developers hit the breaking point right around 10 to 15 repos, exactly when a simple 5-minute nav bar update turns into an hour of pulling, copy-pasting, and pushing.

Here are the two most common ways people escape this trap:

1. The Monorepo Route (Highly Recommended)
   If these tools all belong to the same ecosystem (like your xnipertools site), migrating to a monorepo using tools like Turborepo or Nx is usually the best fix.

The fix: You get one repo (which solves your scattered issues and cross-repo search problems instantly). Shared components live in a packages/ui folder that all your tools just import locally.

The bonus: You can still configure GitHub Actions to deploy each tool independently to GitHub Pages, so you don't lose that benefit.

2. The "Shared Package" Route
   If you absolutely want to keep the repos separate, you need to stop copy-pasting code. Pull your shared components (nav bar, footers, styles) into one dedicated repo and publish it as an npm package or GitHub Package.

The fix: Your 10+ tools just install it as a dependency.

The bonus: You can use a tool like Dependabot to automatically open PRs across all your repos whenever you update the nav bar package.

If I were in your shoes, I would take a weekend to migrate to a monorepo. It solves all three of your pain points natively. Good luck with the tools!

[CamiloCod3]

I don’t think there’s a specific repo count where it suddenly becomes unmanageable. It’s more about how often you need to make the same change across all repos.

If the tools are mostly independent, separate repos can still make sense. But once things like the navbar, shared styles, CI config, labels, or deployment logic start changing together, that’s usually the signal to centralize something.

Before moving everything into a monorepo, I’d probably try a middle-ground approach first: keep the repos separate, but move shared UI into a small package or template, use reusable GitHub Actions workflows, and manage cross-repo work with GitHub Projects or consistent labels.

If that still feels painful after a while, then a monorepo with independent deployments would probably be the cleaner long-term move.