I built exactly that as a 27-section playbook, and it's what runs all five of my live client sites. This post is the map of what's inside. The step-by-step implementation — commands, configs, and scripts — is what I deliver for clients, because a half-followed server guide is how people lock themselves out of SSH on a Friday night.

What's inside

Foundation & networking — static LAN addressing done safely (with rollback), plus optional KVM virtual machines on a bridged network so a client's app can live in its own isolated VM.

The core tunnel stack — Nginx installed and verified, cloudflared installed and authenticated, your domain (say, example.com) connected to Cloudflare, one shared tunnel created, and a wildcard origin certificate so traffic is encrypted all the way to the server — Full Strict, not Almost.

Serving sites & apps — static sites as folders, Node/SvelteKit apps behind reverse proxies on their own ports, PM2 keeping every app alive across crashes and reboots (including the pm2 save step everyone forgets), and the full tunnel ingress config tying every hostname together with a safe catch-all.

Staying alive — a health-check script that curls your real public URL every 5 minutes and restarts the tunnel when the connection silently drops (systemd alone can't see that), plus Cloudflare-side tunnel alerts for when the whole box is unreachable.

Private admin access — a WireGuard-based VPN so you reach SSH, logs, and dashboards from anywhere with zero open inbound ports, friendly hostnames instead of IPs, and remote VM management without X11 pain.

Backups without downtime — live disk snapshots of running VMs on a nightly schedule with retention pruning, triggerable on demand from your phone before risky changes.

Hardening & hygiene — edge WAF with managed rules, bot protection, per-site rate limits (scoped by hostname so clients never affect each other), automatic security patching, log rotation, and resource monitoring bound to the private network only.

Operations — a one-command script that adds a new static site (folder, Nginx block, tunnel route, DNS, reloads) in about five minutes, a checklist for the manual SSR path, a 20-row troubleshooting table built from real failures, and a per-site-type quick reference.

Why this isn't a copy-paste tutorial

Three honest reasons:

1. The dangerous steps are order-dependent. Bridge networking, static IPs, and firewall changes can lock you out of your own server if sequenced wrong. My playbook is sequenced from scars, not theory.
2. Every server is different. Cloud VM vs home lab, single site vs multi-client, static vs SSR — the right choices change, and a generic guide can't make them for you.
3. The value is the guarantee. When I deploy this, I verify every layer live, hand over plain-English notes, and remain the person to call. A tutorial can't do that.

What "done for you" looks like

• Audit — I look at what you're running now and tell you straight whether this architecture fits (sometimes your current hosting is fine — I'll say so)
• Build — server hardened, tunnel live, your sites migrated with zero-downtime DNS cutover
• Handover — monitoring verified, snapshots scheduled, the 5-minute new-site routine in your hands
• Backup human — when something breaks at 11pm, you message me, not a support forum

Five sites on one VPS instead of five hosting bills typically pays for the setup within months — and every site gets the same live uptime badge my clients have. Contact me with your current setup and I'll scope it honestly.

Here's the architecture, honestly explained — and at the end, how to get the whole thing built for you.

The shape of it

Visitor → Cloudflare edge (DNS + SSL) → Cloudflare Tunnel → Nginx → your sites

Three jobs, three tools:

• Cloudflare handles DNS and the public SSL certificate. Free plan is enough.
• Cloudflare Tunnel (cloudflared) is an outbound-only connection from the server. The firewall stays shut — there is nothing to attack.
• Nginx routes each domain to the right folder or app on the machine, e.g. shop.example.com → one folder, app.example.com → a Node app on port 3000.

A basic static site block looks like this — this part is standard Nginx anyone can look up:

server {
    listen 80;
    server_name shop.example.com;

    root /var/www/shop;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Simple. The parts that actually take experience are everything around it.

What "everything around it" means

Getting from that snippet to five always-on client sites took a full playbook:

• One shared tunnel carrying every hostname, with a catch-all rule so unknown domains get a clean 404 instead of leaking somewhere
• Wildcard origin SSL so browser-to-server traffic is encrypted end to end (Full Strict), not just browser-to-Cloudflare
• Node apps kept alive across crashes and reboots (PM2 + startup hooks that people always forget to save)
• Health checks that restart the tunnel when the connection silently drops — systemctl alone won't catch that
• WAF + rate limiting at the edge, scoped per client so one site's rules never affect another's
• Auto security patching, log rotation, and resource monitoring so the box is safe to leave running unattended
• Private admin access (VPN, no open SSH) and automated snapshots before risky changes
• A one-command script so adding site number six takes five minutes, not an afternoon

That's the difference between "a server block" and "hosting you can sell to clients." The snippet above is 5% of it.

Proof, not promises

I don't just write about this stack — I run it. All five client sites on my Live Sites list run on exactly this architecture, each with a badge that pings the real URL from your browser and shows the round-trip time. If a tunnel ever drops, the badge says Offline. No fake "99.9%".

Get the full setup — done for you

The complete implementation playbook (tunnel config, SSL, monitoring scripts, hardening, automation) is something I deploy for clients, not something I publish. Here's what you get:

• Your sites migrated onto one efficient server (or your existing one, hardened)
• DNS, SSL, tunnel, monitoring, and backups configured and verified live
• A 5-minute routine for adding future sites, handed over with plain-English notes
• Someone to call when something breaks at 11pm — me

One server instead of five hosting bills usually pays for the setup within months. Contact me with what you're running now, and I'll tell you honestly whether this architecture fits — including when the answer is "your current hosting is fine."

1. adapter-static

Install it and point the output at a build folder:

// svelte.config.js
import adapter from '@sveltejs/adapter-static';

const config = {
  kit: {
    adapter: adapter({
      pages: 'build',
      assets: 'build',
      fallback: '404.html',
      precompress: true,
      strict: true
    })
  }
};

Three settings matter:

• fallback: '404.html' — generates a fallback page so unknown URLs (and client-rendered routes like my project modals' deep links) don't hit a dead end. It also doubles as your custom 404 page.
• precompress: true — emits gzip + brotli versions of everything at build time. Free bandwidth savings.
• strict: true — fails the build if any route isn't prerenderable, so you catch dynamic-route mistakes before deploying, not after.

2. Prerender every route, including dynamic ones

Static output means every URL must exist at build time. Normal pages just work. Dynamic routes like my /blog/[slug] pages need an entries() function telling SvelteKit which slugs to generate:

// src/routes/blog/[slug]/+page.ts
export const prerender = true;

export function entries() {
  return posts.map((p) => ({ slug: p.slug }));
}

Forget this and the build fails under strict — which is exactly what you want.

3. The Render blueprint

One render.yaml in the repo root turns deploys into "push to branch, done":

services:
  - type: web
    name: jadeangco-portfolio
    env: static
    buildCommand: npm ci && npm run build
    staticPublishPath: ./build

Connect it via New → Blueprint in the Render dashboard. Every push rebuilds and republishes. Keep the publish path and the adapter output (build) in sync or you'll deploy an empty site — I speak from experience.

4. Don't ship megabytes

Before my last deploy, four PNG screenshots weighed 7.8 MB. I converted every referenced image to WebP (same folder, code updated) and the total dropped to 548 KB — a 93% cut with no visible difference. Image weight is the cheapest Core Web Vitals win on a portfolio.

The short version: static adapter + strict prerendering + blueprint deploys + light images. If you want this exact setup, it's all running right here — and if you'd rather hire someone to do it for your site, that's me.

Reactivity: runes vs refs

Svelte 5 runes ($state, $derived) feel like writing plain JavaScript that happens to be reactive. No .value unwrapping, no thinking about refs vs reactive objects:

let activeFilter = $state("All");
const filtered = $derived(
  activeFilter === "All" ? projects : projects.filter((p) => p.status === activeFilter)
);

Vue's Composition API is excellent, but .value ceremony adds up across a large codebase. For speed of writing, Svelte wins.

Ecosystem: Nuxt wins on breadth

Need auth, i18n, image optimization, content? Nuxt has a first-party module for all of it. SvelteKit's ecosystem is younger — you'll assemble more yourself. For a content-heavy marketing site with a team, Nuxt's module catalog is a genuine advantage.

Output and performance

Both ship fast static sites. Svelte's compiler approach (no virtual DOM, tiny runtime) gives it the edge in bundle size on interactive apps — noticeable on Philippine mobile data, which is the network half my users are on.

When I'd pick which

• Pick Nuxt for content sites with a team, when you need its module ecosystem, or when hiring Vue developers later matters.
• Pick SvelteKit for interactive apps, dashboards, and solo/small-team builds where velocity matters most.

My portfolio runs SvelteKit; my tourism sites run Nuxt. Both choices were right for those projects. If you're deciding for yours, describe it to me and I'll give you a straight answer — including when the answer is "plain HTML is enough."