Monorepo vs Polyrepo: Pilihan Stack yang Tepat 2026

Pertanyaan monorepo vs polyrepo muncul sebelum setiap proyek baru, dan jawabannya membentuk berbulan-bulan setup CI/CD, overhead refactoring, dan kontrol akses tim. Untuk kebanyakan developer solo dan indie hacker yang membangun produk dengan paket atau library bersama, pilihan monorepo adalah yang tepat di 2026. Pilihan ini tergantung tiga faktor: apakah layanan berbagi kode, siapa butuh akses ke mana, dan toleransi Anda terhadap kompleksitas CI/CD.

Debat monorepo vs polyrepo bukanlah tentang tren atau gaya architectural. Ini tentang overhead praktis yang Anda hadapi setiap hari. Dalam polyrepo, setiap kali dua paket perlu saling komunikasi, Anda terjebak dalam publish ceremony. Dalam monorepo dengan workspaces, Anda ubah kode dan semuanya langsung terlihat. Jika layanan Anda sepenuhnya independen dan tidak akan pernah berbagi kode, polyrepo lebih sederhana. Tetapi kasus itu lebih jarang dari yang developer bayangkan.

Jam 22.00. Anda baru mulai proyek di editor favorit: API backend TypeScript, paket library tipe bersama untuk types, dan dashboard React frontend yang pasti akan butuh keduanya. Dua tab terminal terbuka. Kursor berkedip di VS Code atau Cursor editor. Keputusan arsitektur repository ini akan membentuk berbulan-bulan workflow development, setup CI/CD automation, refactoring overhead, dan kontrol akses tim Anda.

Kebanyakan artikel tentang monorepo versus polyrepo ditulis untuk tim engineering besar dua puluh orang dengan DevOps engineer khusus yang specialized mengonfigurasi Bazel atau tools enterprise lainnya. Artikel ini untuk builder solo dan indie hacker yang perlu membuat keputusan infrastructure sebelum commit pertama, karena restruktur enam bulan kemudian, saat Anda punya user nyata, data production, dan pipeline CI yang otot memori sudah hafal, adalah hal yang membunuh momentum side project untuk selamanya. Pilihan antara monorepo vs polyrepo bukan keputusan sepele yang bisa dirombak kemudian tanpa biaya.

Apa yang monorepo benar-benar berikan kepada Anda (bukan versi textbook)

Pitch standar untuk monorepo adalah "satu repo, dependensi bersama, perubahan atomik antar service." Itu semua nyata dan akurat. Tetapi bagian yang benar-benar penting dari hari ke hari untuk builder solo lebih konkret daripada teori: Anda tidak perlu melakukan publish atau release ceremony terhadap paket untuk menggunakannya secara lokal.

Dalam setup polyrepo tradisional, jika shared-utils library perlu perbaikan yang juga mempengaruhi behavior api-service, Anda harus menjalankan proses publish versi baru shared-utils ke npm registry, bump dependensi di api-service package.json, tunggu CI pass di repo terpisah, kemudian deploy. Atau Anda kembali ke hack npm link yang bekerja sampai berhenti tiba-tiba di tengah sprint. Dalam monorepo dengan workspace infrastructure, Anda ubah kode di shared-types folder, dan setiap paket yang mengimpornya melihat perubahan langsung tanpa publish. Tidak ada seremonial release.

Ini seperti apa dengan pnpm workspaces, yang menambah overhead konfigurasi minimal dibanding npm workspaces:

/packages
  /shared-types      <- diimport langsung oleh api dan web
  /api
  /web
package.json         <- workspace root dengan field "workspaces"

// api/package.json
{
  "dependencies": {
    "@myapp/shared-types": "workspace:*"
  }
}

Tidak ada publish ke registry. Tidak ada version bumping ceremony saat development. workspace:* resolve ke paket lokal dalam filesystem, dan project references TypeScript memberi Anda incremental compilation di seluruh dependency graph.

Keuntungan nyata kedua dari konfigurasi turborepo monorepo: refactoring cross-package yang besar landing dalam satu PR atomic. Rename interface di shared-types? TypeScript bilang tiap consumer dan service yang consume tipe itu yang rusak, dalam codebase sama, dalam sesi editor sama. Anda track semuanya. Dalam polyrepo multi-repo, Anda rename di repo A, publish versi baru, dan temukan kerusakan di repo B tiga hari kemudian saat kolega jalankan npm install dan tipe tidak match runtime lagi. Type mismatch production bug.

Keuntungan ketiga, yang kebanyakan developer solo underestimate: satu tempat untuk konfigurasi tooling dan linting. Satu .eslintrc, satu prettier.config.js, satu tsconfig.base.json, satu CI workflow file. Penghematan kecil per perubahan, tetapi compound significant over berbulan-bulan iterasi. Ketika Anda upgrade prettier atau eslint version, Anda upgrade di satu tempat saja. Tidak perlu koordinasi multi-repo.

Nilai untuk namakan apa yang monorepo tidak berikan: tidak membuat layanan less coupled atau more decoupled secara otomatis. Jika layanan Anda sepenuhnya independen dan Anda masukkan mereka ke monorepo anyway, Anda tambah coordination overhead tanpa return on investment. Keuntungan monorepo materialize hanya saat layanan benar-benar share code atau library atau perlu berubah bersama untuk feature cohesive. Struktur repo harus reflect dependency structure architecture, tidak impose satu yang artificial.

Kapan polyrepo mendapat tempatnya di arsitektur repository kode

Polyrepo bukan kesalahan architectural atau pilihan yang salah. Itu pilihan yang tepat untuk situasi spesifik yang well-defined, dan pura-pura sebaliknya adalah bagaimana Anda berakhir dengan monorepo 40-service yang butuh 25 menit untuk clone dari GitHub.

Kasus paling jelas untuk memilih polyrepo: layanan dengan ownership berbeda, release cycles berbeda, atau compliance requirements yang genuinely berbeda antar service. Jika billing service Anda PCI-scoped dan marketing site customer-facing bukan, menyimpan mereka di repo terpisah berarti keep access control, audit logs, dan blast radius cleanly terpisah. Itu bukan operational overhead yang sia-sia. Itu fitur security yang crucial. Financial data terpisah dari marketing data adalah best practice.

Polyrepo juga menang when Anda open-source bagian dari codebase Anda. Dedicated public repo separate biarin external contributors fork dan PR tanpa pull private infrastructure Anda ke scope mereka. Model permission repository GitHub tidak kasih clean path-based access isolation at scale untuk mixed public-private codebase. Repo terpisah handle ini dengan benar dan jelas.

Dan untuk pure microservices dengan tech stacks sepenuhnya distinct dan tidak compatible: layanan Go backend dan React Native mobile app yang literally share nothing di code level atau library level, monorepo add coordination cost tanpa deliver benefit apapun. Jika tidak ada shared packages atau shared types atau shared infrastructure code, tidak ada yang di-share sama sekali.

Versi jujurnya dari pengalaman real: kebanyakan indie projects dan startups yang mulai dengan polyrepo end up regretting eventual, bukan karena polyrepo bad architecture, tetapi karena mereka overestimate bagaimana independent bagian akan stay over time. Frontend web selalu butuh tipe definition dari backend API. Worker script selalu butuh utility helper dari API. Scheduler task butuh types dan constants dari core library. Dua repo structure become empat sampai enam PRs untuk tiap feature cross-service. Koordinasi menjadi bottleneck.

Biaya CI/CD yang tidak ada yang mention sampai hit production bill Anda

Monorepo architecture punya real operational cost yang perlu Anda pikirkan sejak awal: jika CI pipeline Anda naively jalankan everything dan run all tests on every commit, Anda bayar dalam waktu cloud compute dan uang credit untuk builds dan tests yang completely tidak ada hubungan dengan apa yang Anda ubah dalam commit.

Push CSS tweak saja ke web package folder. CI jalankan full test suite untuk api folder, worker folder, dan shared-types folder. Itu enam menit GitHub Actions cloud compute untuk perubahan warna button. At scale dengan banyak contributor, ini turn ke CI queues panjang yang block seluruh tim development Anda dari merging PR.

Solusinya exist dan tested, tetapi perlu setup yang deliberate dan thoughtful: build orchestration tools yang understand dependency graph architecture Anda dengan baik. Turborepo dan Nx keduanya solve ini dengan baik. Turborepo turbo.json configuration define pipeline di mana tiap task run hanya untuk packages dengan changed inputs atau changed dependencies:

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "cache": true
    }
  }
}

Dengan remote caching enabled (gratis di Turborepo Cloud tier Vercel untuk small teams dan indie hacker), cache hit pada paket unchanged instant, tidak rebuild sama sekali, tidak retest sama sekali. Untuk developer solo di side project, ini keep CI pipeline under dua menit pada kebanyakan pushes sekali build artifacts warm dan cached. Speed improvement ini significant untuk developer productivity.

Biayanya: Anda harus learn Turborepo atau Nx sebelum Anda desperately butuhkan, bukan setelah. Itu roughly setengah hari research dan setup. Jika Anda skip deliberate learning dan biarkan CI accumulate fat dengan slow test, monorepo CI slow to crawl sampai Anda mulai question seluruh architectural choice dan wonder if polyrepo right semua along, saat problem nyata adalah missing config file atau missing Turborepo integration. Inilah mengapa planning ahead penting untuk monorepo success.

Bagaimana AI coding tools mengubah math tentang debate monorepo ini

Sampai recently beberapa tahun lalu, satu argument genuine dan legitimate untuk polyrepo adalah cognitive load dan mental model: repo yang lebih kecil adalah lebih mudah untuk reason about karena mereka isolated dan focused. Context-switch ke service baru, lihat hanya yang relevant untuk specific service itu. Argument itu genuine legitimate dari perspective developer yang work manual.

AI coding tools dan copilot shift calculation ini significantly. Saat Anda work dengan Cursor, Claude Code, atau GitHub Copilot, tool bekerja dengan full codebase Anda in context window. Ia see cross-service dependencies dengan jelas, understand interface mana consumed oleh service mana, dan track renamed field through tiap consumer di codebase tanpa Anda hold seluruh mental model. Argument "isolated repo lebih mudah untuk understand karena smaller" weakens significantly saat AI assistant Anda hold seluruh dependency graph in context anyway. LLM context windows terus berkembang.

Contoh konkret untuk illustrate poin ini: dalam setup polyrepo multi-repo, jika Anda ask AI assistant untuk refactor API endpoint yang juga affect shared type definition, ia typically tidak bisa lihat kedua repos dalam satu session atau context window. Anda do manual coordination, hand-holding, dan copy-paste between sessions, yang exactly overhead yang monorepo supposed eliminate. Dalam monorepo, refactor same adalah one cohesive conversation dengan AI tool tanpa batas repository.

Ini tidak flip decision monorepo vs polyrepo entirely atau make it clear-cut selalu monorepo. Tetapi ia remove satu dari justifikasi historis untuk polyrepo untuk small teams dan solo devs, dan tips default slightly lebih jauh ke monorepo saat code genuinely coupled dan interdependent. Trade-off calculation berubah dengan AI tools.

Tiga sinyal konkret yang berarti Anda harus split repo sekarang

Anda mulai dengan monorepo strategy. Bagus decision. Tetapi berikut tiga sinyal konkret bahwa split ke polyrepo sudah right call untuk situasi Anda:

Access control menjadi load-bearing requirement. Contractor atau freelancer butuh frontend access code, tetapi tidak boleh baca backend. Partner tim integration butuh baca API schema documentation tetapi tidak boleh baca business logic proprietary Anda. GitHub Codeowners file bisa restrict siapa allowed review path mana, tetapi tidak restrict read access ke file. Jika read isolation penting untuk compliance reason atau security reason, repo terpisah adalah clean architectural answer. Codeowners gymnastics dan branch protection rules tidak pernah fully replace repository-level permission.

CI failures di satu service block deployment di service unrelated. Jika broken test di payment-service gate hotfix production urgent yang Anda absolutely need ship di marketing-site, monorepo Anda create coupling yang actual codebase Anda tidak punya. Baik build configuration perlu fixing proper (task scoping dengan Turborepo solve ini), atau kedua service genuinely tidak belong dalam repo sama dan share nothing.

Satu part akan open-source public dan satu part harus closed proprietary. Ini cleanest split case dan paling clear-cut. Extract open-source piece ke public repo sendiri dedicated. Mixed public dan private code dalam GitHub monorepo genuinely painful to maintain: Anda butuh organization terpisah atau manual pruning process yang create permanent maintenance overhead selamanya.

Setup praktis yang kebanyakan builder experienced land pada

Jawaban yang kebanyakan experienced developers settle pada setelah experience banyak project: satu monorepo per product domain business, bukan "satu monorepo untuk everything yang pernah Anda build" dan bukan "satu repo per package dalam monorepo."

Jika Anda build SaaS product dengan web frontend, API service, dan shared type library, itu satu product domain logical. Keep dalam satu monorepo unified. Jika Anda juga maintain CLI utility open-source yang other projects use, itu repo berbeda dengan audience berbeda dan release cycle berbeda. Separation ini jelas dan makes sense untuk business model.

Kesalahan common adalah treat monorepo atau polyrepo choice sebagai ideological absolut decision. Bukan "monorepo teams" versus "polyrepo teams" dalam ideology. Ini structural decision pragmatic berdasarkan tiga pertanyaan: Apa dependency graph antara layanan Anda? Siapa butuh access apa, dan apakah isolation penting untuk compliance? Apa tolerance Anda untuk CI/CD setup complexity dan learning curve? Jawab ketiga pertanyaan ini dengan jujur.

Untuk side projects dan indie hacker specifically: mulai dengan monorepo menggunakan pnpm workspaces atau npm workspaces (npm workspaces work juga, hanya kurang ergonomic dalam practice). Add Turborepo dan remote caching hanya saat CI start regularly hit 4 plus menit atau lebih. Split ke repo terpisah hanya saat Anda punya concrete reason clear: open-source requirement, access control compliance, regulatory requirement, atau partner team dengan different release cadence. Bukan karena terasa architecturally cleaner atau karena tren blog terbaru atau karena conference talk yang Anda dengarkan minggu lalu.

Debate monorepo versus polyrepo adalah satu dari pilihan infrastructure di mana jawaban yang tepat untuk kebanyakan solo devs adalah sama: mulai simple dengan pnpm workspaces, optimize friction spesifik saat friction appear beneran. Kursor masih berkedip di terminal. Waktunya ship commit pertama dan mulai iterate dengan user real. Stack architecture decision yang overthinking adalah enemy dari productivity.