How I Built a Multi-Tenant Static Site Engine with Next.js, Nginx, and Coolify

Published: (December 13, 2025 at 07:00 AM EST)
3 min read
Source: Dev.to

Source: Dev.to

High-Level Overview

Before diving into the technical details, here’s what the system looks like from the top.

Most landing pages today are built manually or with drag‑and‑drop tools. I wanted something different:

  • Automated
  • Config driven
  • Super fast
  • SEO optimized
  • Super cheap to host
  • Able to host hundreds of sites without breaking a sweat

Architecture

A single engine built with Next.js:

  • Config driven system for each tenant
  • Component factory that assembles pages
  • Static export that generates pure HTML
  • Automated output (sitemap, robots, analytics, Nginx configs)
  • Deployment handled by Coolify, assigning subdomains or custom domains

One engine → unlimited landing pages.

Multi Tenant Landing Page Architecture

Build Pipeline

Multi Tenant Landing Page Build Pipeline

Business Config

Each tenant has a JSON config with branding, colors, services, copy, etc.

Component Factory

The engine picks from a library of reusable section templates. Example structure:

hero
├─ default
└─ split

features
├─ grid
└─ list

footer
├─ default
└─ multi-columns

gallery
├─ default
└─ scrolling

Static Export (Next.js)

Next.js compiles everything into static HTML.

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  output: "export",
  images: {
    unoptimized: true,
  },
  trailingSlash: true,
};

export default nextConfig;

Auto‑Generated Assets

The system produces:

  • sitemap.xml
  • robots.txt
  • Analytics scripts
  • OpenGraph metadata, etc.

Nginx Configuration

The generator builds the routing and subdomain configuration for each tenant.

Deploy via Coolify

Coolify picks up the static output, reloads Nginx, and the site goes live.

What This Means in Practice

Instead of building landing pages one by one, you can:

  1. Onboard a new business
  2. Fill out its JSON config
  3. Pick the desired sections
  4. Run the generator
  5. Instantly deploy a fully functional, SEO‑ready landing page

It’s fast, cheap, scalable, and extremely flexible.

Why Static > SSR for This Kind of Project

For a multi‑tenant system hosting tens or hundreds of small business sites, server‑side rendering (SSR) can be overkill:

  • Every request would need a Node.js process
  • Middleware, auth, data fetching, layout logic run on each hit
  • Concurrency, memory, cold starts, scaling become concerns

With a static export:

  • Pages are rendered to HTML at build time
  • Nginx (or any simple web server) just serves files from disk
  • No per‑request React/Next.js execution → less CPU, less RAM, fewer points of failure

Benefits for static sites:

  • Faster first byte (no render step)
  • Simpler scaling
  • Easier performance reasoning
  • Much cheaper infrastructure

If dynamic behavior is needed later, you can still add:

  • Small API routes
  • Client‑side interactivity
  • Webhooks or background workers

The core of the site remains static.

Why I Can Host Hundreds of Pages on a “Cheap” Server

A basic cloud server (e.g., a small DigitalOcean, Vultr, or Linode instance) typically costs $4–7 / month and provides:

  • 1 vCPU
  • 0.5–1 GB RAM
  • ~10–25 GB SSD
  • 500 GB – 1 TB outbound bandwidth

Assuming an average page size of ~300 KB:

  • 500 GB outbound → ~1.6 million page views/month
  • 1 TB outbound → ~3.3 million page views/month

Even after accounting for images and other assets, you can comfortably serve hundreds of thousands of page views.

Example multi‑tenant scenario

  • 100 tenants × 1,000 page views/month each = 100,000 views/month

With static hosting and Nginx, the bottleneck is bandwidth, not CPU or RAM.

If traffic grows, you can:

  • Add a CDN in front
  • Scale horizontally with more small boxes
  • Upgrade to a slightly larger instance

The core advantage remains:

Static + Multi‑Tenant = many sites on very little infrastructure.

Back to Blog

Related posts

Read more »