The Monoclone Architecture Explained

If you have ever tried to run more than three websites simultaneously, you know the maintenance problem. Three repos. Three sets of dependencies. Three deployment pipelines. Three places where a security patch needs to be applied. By site number five, you are spending more time on infrastructure upkeep than on the thing that actually makes money: publishing content.

The monoclone architecture solves this. It is a pattern borrowed from enterprise software development — specifically the monorepo pattern used by Google, Meta, and Microsoft — adapted for independent publishers running networks of niche sites. One codebase. One build system. Sixteen (or more) visually and structurally distinct websites.

This is not theoretical. It is the core engine behind the approach laid out in The $100 Network, and once you understand it, the economics of running a multi-site portfolio change permanently.

The Core Idea: Everything Shared Lives in Templates, Everything Unique Lives in Data

A monoclone starts with a single static site generator project — Eleventy (11ty) works particularly well for this because of its data cascade and flexible templating. Your layouts, partials, CSS architecture, JavaScript utilities, and build logic live in one place. They are shared infrastructure.

What makes each site different — the brand name, color palette, tagline, niche focus, curated content lists, FAQ data — lives in a single configuration file called sites.json. Each site is an object in that array.

The bridge between them is one environment variable: SITE_ID.

When your build system runs, it reads SITE_ID from the environment, looks up the matching entry in sites.json, and the entire site — colors, copy, content selection, schema markup, meta tags — cascades from that single string.

How SITE_ID Drives Everything

Here is the core data file that makes this work in an Eleventy project:

// _data/site.js
const sites = require('../sites.json');

module.exports = function() {
  const siteId = process.env.SITE_ID || 'default-site';
  const siteConfig = sites.find(s => s.id === siteId);

  if (!siteConfig) {
    throw new Error(`No config found for SITE_ID: ${siteId}`);
  }

  return siteConfig;
};

That is it. Seven lines of JavaScript. Every template in your project now has access to site.name, site.colors.primary, site.tagline, site.keywords, and every other field you defined in the configuration.

Your Nunjucks templates consume it naturally:

<header style="background-color: ">
  <h1></h1>
  <p>A $10 book. A $100/month empire. The sequel to The $97 Launch and The $20 Agency.</p>
</header>

Same template file. Different output for every site. No conditionals, no branching logic, no template duplication.

What sites.json Actually Contains

A real sites.json entry carries more weight than you might expect. Here is a representative example:

{
  "id": "best-pressure-washers",
  "domain": "bestpressurewashers.net",
  "name": "PressureWash Pro",
  "tagline": "Expert reviews for every budget",
  "niche": "outdoor-power-equipment",
  "template": "review-authority-v2",
  "provider": "netlify",
  "status": "live",
  "colors": {
    "primary": "#2563eb",
    "primaryDark": "#1d4ed8",
    "accent": "#f59e0b",
    "bgDark": "#0f172a"
  },
  "monetization": "affiliate",
  "affiliatePrograms": ["amazon-associates", "home-depot"],
  "contentCount": 47,
  "targetContentCount": 100,
  "relatedSites": ["outdoor-gear-hub", "lawn-care-daily"],
  "primaryKeyword": "best pressure washer",
  "indexNowKey": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}

Every field is consumed by some part of the system. The template field selects which layout variant to use (critical for avoiding template fingerprinting, which we will cover in a future post). The provider field tells the deployment script where to push the build output. The status field controls whether build and indexing scripts target this site at all.

The relatedSites array drives cross-domain linking. The affiliatePrograms array tells the link injection script which product URLs to rewrite. The indexNowKey feeds the automated indexing pipeline.

One JSON file. Sixteen sites. Zero ambiguity.

Why This Is Not a PBN

This is the question that comes up immediately, so let us address it directly.

A Private Blog Network is a collection of domains — usually expired domains bought for their backlink profiles — that exist for one purpose: passing PageRank to a money site through manipulative links. PBN sites have thin or spun content, no real audience, and no brand. They are hollow shells designed to game link graphs.

A monoclone network is the opposite. Every site is a real website with original content, a unique brand identity, and genuine utility for visitors. Each site could be discovered by a user who would never guess it shares infrastructure with the others. The monoclone is an efficiency pattern, not a deception pattern.

Think of Red Ventures. They own Bankrate, CreditCards.com, The Points Guy, CNET, and Healthline. These are separate brands, separate editorial voices, separate audiences — but they share corporate infrastructure, analytics platforms, and probably significant chunks of backend code. Nobody calls that a PBN because each property is legitimate.

The monoclone gives a solo operator the same structural advantage. The shared codebase is an implementation detail. The separate brands are the product.

The Deployment Flow

In practice, deploying a monoclone site looks like this:

1. Push code to your repository (one push, shared by all sites)
2. CI/CD triggers one build job per site, each with a different SITE_ID environment variable
3. Each build reads sites.json, resolves the config for its SITE_ID, and produces a complete static site
4. Output deploys to the provider specified in that site's config — Cloudflare Pages, Netlify, Vercel, or GitHub Pages

For sixteen sites, this means sixteen parallel build jobs triggered by a single git push. GitHub Actions handles this well with a matrix strategy, and because you are building externally and deploying pre-built output, you consume zero build minutes on the hosting providers themselves.

The result: one commit updates all sixteen sites. A bug fix propagates instantly. A new feature rolls out network-wide without touching sixteen separate projects.

The Maintenance Advantage

After six months of running a monoclone, the maintenance advantage becomes the dominant benefit — even more than the deployment speed.

When a dependency has a security vulnerability, you update it once. When you discover a better schema markup pattern, you implement it once. When a hosting provider changes their API, you adjust one deployment script.

Compare this to sixteen independent projects. Every update is multiplied sixteen times. Every dependency conflict is unique. Every configuration drift has to be hunted down individually. At scale, independent repos are not just inefficient — they are operationally dangerous.

Where to Go Deeper

This post covers the concept and the core mechanism. The full implementation — including template differentiation strategies, the complete sites.json schema with all thirty-plus fields, the GitHub Actions matrix deployment pipeline, and the content generation system that populates all sixteen sites — is laid out step by step in The $100 Network by J.A. Watte. Chapter 2 walks through the monoclone blueprint from first file to first deploy, and Chapter 4 covers the complete sites.json schema reference.

If you are currently managing multiple sites as separate projects, the monoclone pattern will save you more time in the first month than the book costs. That is not marketing — it is arithmetic.

This article is based on techniques from The $100 Network. If you're just getting started, begin with The $97 Launch to build your first site, then The $20 Agency to set up your marketing stack.