DEV Community: Alexandros Kyvrikoseos

42 domains, one VPS, Cloudflare Free: the five things that actually broke

Alexandros Kyvrikoseos — Thu, 10 Sep 2026 16:29:17 +0000

description: "Running a network of sites on Cloudflare's Free plan and a single origin server. Not a setup guide: an honest list of what went wrong and the checks that now prevent it."

I run 42 domains on Cloudflare's Free plan: tourism guides for my region in Greece, AI chat assistants, a couple of SaaS platforms and some client sites. Almost all of them point at one VPS. The rest are answered at the edge by Workers and never touch the server.

Cloudflare costs me nothing. What it costs is attention, because a free, powerful dashboard makes it very easy to end up with 42 zones configured 42 slightly different ways.

This isn't a setup guide. It's the list of things that actually broke, or quietly leaked, and the check I now run so they don't happen again.

Diagram: zones (proxied, DNS only, Worker routes, parked) pass through the Cloudflare edge (SSL modes, edge cache, WAF) to one origin VPS running nginx and Node services. Five numbered failure points are marked.

1. One grey cloud exposes everyone

Cloudflare's orange cloud hides your origin IP. The grey cloud ("DNS only") publishes it.

When I inventoried every zone, some sites were proxied and some weren't. Even within one family of six near-identical sites the split was three and three, and nobody could tell me whether that was deliberate.

That split matters more than it looks. All of those sites share the same IP. One DNS-only record reveals the origin for every proxied site on the same box, and the proxy protection on the other 41 is only as strong as that one grey cloud.

The quickest audit is to ask each domain who answered:

curl -sI https://example.gr | grep -i -E '^(server|cf-ray):'

A cf-ray header means the request went through Cloudflare. No cf-ray means you just talked to your origin directly.

The real fix goes further than flipping clouds to orange. An origin IP is discoverable from historical DNS anyway, so the server itself should only accept web traffic from Cloudflare's IP ranges. That's on my list, and it only becomes possible once no zone depends on a grey cloud.

2. Flexible SSL: a padlock with plain HTTP behind it

The same inventory found four live, proxied sites on the Flexible SSL mode.

Flexible means the visitor gets HTTPS to Cloudflare, and Cloudflare talks to your origin over plain HTTP. The browser shows a padlock. The second half of the trip is unencrypted. It works, it looks secure, and nothing ever warns you.

Other zones had drifted too: some on "Automatic" SSL mode, where Cloudflare picks for you and can change its mind, and six with Always Use HTTPS switched off.

3. Switching to Full (strict) took four sites down

The obvious fix for Flexible is Full (strict): Cloudflare connects to the origin over HTTPS and verifies its certificate. I switched the four sites over, and all four started returning a JSON {"error":"not found"}.

These were static sites. They have no JSON anywhere.

What happened: those domains had no server block on port 443 at all. Under Flexible that never mattered, because Cloudflare only ever knocked on port 80. Under Full (strict), Cloudflare knocked on 443, nginx found no matching server_name, and handed the request to its default server for that port. With no explicit default_server, that's simply the first listen 443 ssl block nginx loads. On my machine it belonged to an API subdomain running Express, which politely replied that / didn't exist.

I switched them back to Flexible. The rule I use now, before touching any SSL mode, is to ask the origin directly, bypassing Cloudflare:

curl -sk -o /dev/null -w '%{http_code}\n' \
  --resolve example.gr:443:ORIGIN_IP https://example.gr/

200 means go ahead. 404 or 000 means there's nothing real on 443 yet, and switching will break the site.

The proper fix, in order:

A Cloudflare Origin Certificate per domain (it can last up to 15 years, so no renewal cron to forget)
A real 443 server block, plus a redirect from 80 to 443
nginx -t, reload, the curl --resolve check again
Only then, Full (strict)

All eight hostnames came back with 200. One more thing I'd recommend: an explicit catch-all for unknown hostnames, so a missing block fails obviously instead of borrowing another site's backend:

server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;
}

4. The change that didn't show up

I updated the footer on six sites in one go. Most showed the change straight away. One didn't, and I spent a while convinced the write had failed.

It hadn't. All six files had been written in the same second. That one zone was proxied and serving its HTML from Cloudflare's edge cache, so which site lagged wasn't random: it was predictable from how each zone was configured.

Checking the origin's copy of a file isn't enough on a proxied site. Look at what the edge is actually serving:

curl -sI https://example.gr | grep -i cf-cache-status

DYNAMIC means you're seeing the origin. HIT means you're seeing a copy, and you need a purge before you can judge the change.

5. `nginx -t` passed, and nothing changed

I added a location block, ran nginx -t, got "syntax is ok", reloaded, and the new endpoint returned 404.

The block had been pasted inside a section of the file that was commented out. nginx -t tells you the configuration parses. It says nothing about whether the lines you care about are active.

Even nginx -T, which dumps every loaded file, prints the comments along with everything else, so a careless grep will "find" a block that nginx is ignoring. The only proof that a change is live is a request that hits it:

curl -s -o /dev/null -w '%{http_code}\n' -X POST https://example.gr/new-endpoint

Bonus: what a sweep found in the web roots

A read-only sweep across every vhost found two things that no dashboard ever showed me:

.git/config publicly downloadable on seven sites
about 88 backup files (index.html.bak-… and friends) sitting inside document roots

Both are now blocked by one shared snippet included in every server block, and the backups moved outside the web roots entirely. Mine looks roughly like this:

location ~ /\.(?!well-known) { return 404; }
location ~* \.(bak(-[^/]*)?|old|orig|swp|sql)$ { return 404; }

And a smaller one: static sites using try_files $uri $uri/ /index.html return 200 with the homepage for every wrong URL. That hides broken links from you and serves duplicate pages to search engines. For sites that aren't single-page apps, try_files $uri $uri/ =404 is the honest version.

The checklist I run per zone now

Proxied, or deliberately DNS only? (cf-ray)
SSL mode set explicitly, never "Automatic"
A real 443 block on the origin (curl --resolve)
Always Use HTTPS on
On proxied zones: cf-cache-status before judging any change
No .git, no backups, no soft-404s

None of this needed a paid plan. It needed looking at all 42 zones side by side, once, and writing down what each one actually does.

Do you run many zones on one origin? I'm especially curious how people handle locking the origin down to Cloudflare's IPs without losing direct access for maintenance.

Alexandros · Web Host Pro · Diakopto, Greece

"How I let AI agents work on my production server without breaking it"

Alexandros Kyvrikoseos — Thu, 10 Sep 2026 16:19:45 +0000

description: "A solo operator's rulebook: agents propose, a human applies. Real incidents and the rules they produced, from a small town in Greece."
tags: ai, devops, productivity, webdev
cover_image:
[Image description]

[Human Gate]

I'm not a classic programmer. I started as a photographer and art director, and today I run a network of 42 domains, a handful of SaaS platforms and a fleet of AI chat assistants from Diakopto, a small town in Greece. Most of that code was written by AI agents working inside my editor over SSH, on the same server that serves real users.

The agents are faster than me at almost everything. That's exactly the problem. A fast agent with shell access can take down in thirty seconds what took a month to build.

So I don't try to make the agents smarter. I make the path to production narrower. This post is the rulebook, and most of the rules exist because something went wrong once.

Rule 1: Agents propose, I apply

Every change to production starts as a file, not a command. The agent audits first (read-only: configs, logs, row counts, what's actually deployed) and then writes a PROPOSED.md with four parts:

The change: which files, which tables, which services
Blast radius: what else could break, and for whom
Rollback: the exact steps back, written before the change
Checks: how we'll know it worked

I read it, ask questions, and only then say GO. Silence is not a GO. "Looks fine" in the middle of a different conversation is not a GO.

The incident behind the rule: once, my editor froze while I was still reading a proposal. The agent didn't wait. It applied the change, which happened to pass every check. Nothing broke, and that's what scared me: next time the change might not be one that passes. Since then, the agent's instructions end every proposal with write it, report, stop.

Rule 2: Some commands are never the agent's

Agents write files to disk. Unless I give an explicit GO for that specific step, they don't:

run npm run build
restart processes (pm2 restart)
change nginx
run database migrations
git push
publish anything

The build one surprises people. On my server, several frontends are served straight from their dist/ folder. That means building is deploying. An agent that "just runs a quick build to check for errors" has shipped whatever was on disk to every visitor.

Two of my repos also had GitHub Actions that deployed on every push to main. I switched both off. If a push can deploy, then anything that can push can deploy.

Rule 3: Never `prisma migrate dev` on the server

migrate dev is a development tool. When it detects drift between your migration history and the real database, its answer can be to reset the database. On a laptop that's a shrug. On production it's a very bad afternoon.

My database also has partial unique indexes that I created with raw SQL, because Prisma's schema doesn't express them the way I needed. Prisma doesn't know they exist, so any tool that "syncs" the schema is a tool that can quietly drop them. For the same reason, prisma db push is banned too: it bypasses migration history completely.

Schema changes on the server follow one fixed sequence:

pg_dump -Fc mydb > /var/backups/mydb-before-change.dump
psql mydb -f 2026-09-10-add-column.sql
npx prisma generate

Snapshot at the provider, dump, handwritten SQL, update schema.prisma to match, regenerate the client, and then a restart that I approve. It's boring. Boring is the point.

Rule 4: Every command has an address

I work with three places that can run commands: the terminal on my Mac, a terminal on the server, and the agent itself. Every command I receive is labeled with where it runs, and I get one command at a time.

This sounds bureaucratic until you paste scp ~/Downloads/logo.png ... into the server terminal, or a sudo command into your Mac. I've done both. My rule of thumb now: if it starts with cd ~/Downloads or scp, it belongs on the Mac. If it starts with cd /var/www or sudo, it belongs on the server.

Rule 5: A test that has never failed has proven nothing

One of my platforms caches data per client. I asked for a test that proves client A can never see client B's data. The test passed.

Then we broke the code on purpose: made the cache global, so every client shared it. If the test still passed, it was decoration. It failed, loudly, which is the only reason I trust it now.

When an agent writes a security test, make it show you the test failing against broken code before you believe it passes against working code.

Rule 6: Silent fallbacks are lies

My AI chat gateway was configured with a primary model provider and a fallback. Everything "worked". An audit showed that the primary had never worked on that gateway: first a dead key, then retired model names. For weeks every conversation had silently gone through the fallback, and nothing anywhere said so.

Now every fallback is counted and visible. When the gateway serves a prompt from its fallback path, a counter goes up and the logs say why. A fallback you can't see is a fault that hasn't been reported yet.

Rule 7: Real numbers only

A mockup for my company's homepage once had a lovely "live console": a site count slowly drifting upward, a made-up hostname, ping values from Math.random(). It looked great. It was also lying to every visitor.

The rule now covers every screen I own: if a number isn't measured, the UI shows "—". No placeholder that looks real, no "estimated" metric that nobody estimated.

Rule 8: Ground truth beats screenshots

I was once sure a redesign was already live, because I had a screenshot of it. The agent disagreed, and instead of arguing it proved it with four checks: which docroot nginx actually serves, the hash of the file on disk versus what the edge returned, the MIME types, and which stylesheet loaded last. The design had never been live. My screenshot was the prototype, open in another tab.

Memory, mine or the agent's, is not evidence. The server is.

The small rules

Backups live outside the web root. I once found a backup file sitting in a public folder on one of my own sites, downloadable by anyone who guessed the name.
Secrets never go into chat. The agent never gets admin passwords. If a check needs a real login in a browser, I do that part myself.
Two editor windows, maximum. Power cuts happen here, and every cut leaves dead SSH sessions behind that eat connections.
Two files per project. JOURNAL.md is append-only and written by the agent. PENDINGS.md is the to-do list, and only I edit it.
Every session closes with three lines: what closed, what's blocked, what's next.

What it costs, what it buys

It's slower. A change I could "just do" in two minutes takes fifteen: audit, proposal, questions, GO, apply, verify.

What it buys is that I can sleep. A recent audit showed four long-running services on the server that had gone more than two weeks without a single restart. That's not because the agents never make mistakes. They make plenty. It's because their mistakes land in a proposal, where they cost me a question instead of an outage.

How do you work with AI agents near production? Do you let them run builds or migrations, or do you keep a gate like this? I'd genuinely like to know where other people draw the line.

Alexandros · Web Host Pro · Diakopto, Greece

ShopOS: designing a multi-tenant e-shop SaaS on a single VPS

Alexandros Kyvrikoseos — Thu, 10 Sep 2026 13:02:49 +0000

I started out as a photographer and art director. Today I run the infrastructure behind 42 domains from Diakopto, a small town on the north coast of the Peloponnese in Greece. I'm self-taught, I don't have a CS degree, and I'll say it plainly: I work as a production manager who directs and reviews AI-assisted code.

That is exactly why I care about architecture. The code can be generated. The boundaries, the trade-offs and the "what happens when this fails" have to be mine.

This post is about ShopOS, a multi-tenant e-shop platform I'm building for small businesses in Greece: many shops on one core, each with its own domain, products and customers, and data that never leaks between them.

Where it actually stands

I don't like dashboards with fake numbers, so here is the honest status:

Written: tenants, JWT auth with roles, plan gating, catalog with variants, an inventory ledger, orders, customers, analytics, and an AI agent with tool calling.
Not yet: audited against this design, or running a live shop. The first shop on it will be a small local business near me.
In the diagram: solid boxes exist (in code or in my current infrastructure), dashed boxes are planned.

[ShopOS Αrchitecture Diagram]

Why multi-tenant at all

The alternative is one codebase per shop. That starts faster, but every bug gets fixed N times and every new shop is a new project. With a shared core, a new shop is a new row and a domain, a fix ships once, and the product itself can be sold as a subscription.

The price is real: a bug in the core hits every shop at once, and one shop's data is only a missing WHERE clause away from another's. Most of the design below is about paying that price safely.

L1 — Edge: Cloudflare

Every shop domain sits behind Cloudflare for DNS, TLS and WAF rate limiting. Nginx restores the real client IP from Cloudflare's headers, so logs and rate limits see the shopper, not a Cloudflare edge node. Turnstile will guard login and checkout.

L2 — One VPS, on purpose

Everything runs on a single Ubuntu VPS (4 vCPU, 8 GB, NVMe): Nginx serves the built frontends and proxies /api to a Node/Express process managed by PM2. A second PM2 process runs background jobs.

One machine is a single point of failure, and I accept that at this stage. What I don't accept is running it without nightly database dumps, provider snapshots before risky changes, and a rollback plan written before the change.

The request pipeline

Every API request passes the same five steps, in the same order:

resolveTenant — which shop is this? (from the Host header)
requireAuth — who are you, and does your token belong to this shop?
requireRole — OWNER, ADMIN or STAFF
requirePlanFeature — does this shop's plan include this?
handler — a query that can only see this shop's rows

Simplified versions (not production code):

// middleware/resolveTenant.js
import { prisma } from '../lib/prisma.js';

const cache = new Map(); // host -> { tenantId, expires }
const TTL_MS = 60_000;

export async function resolveTenant(req, res, next) {
  const host = (req.hostname || '').toLowerCase();
  const hit = cache.get(host);
  if (hit && hit.expires > Date.now()) {
    req.tenantId = hit.tenantId;
    return next();
  }
  const domain = await prisma.domain.findUnique({
    where: { host },
    select: { tenantId: true },
  });
  if (!domain) return res.status(404).json({ error: 'SHOP_NOT_FOUND' });
  cache.set(host, { tenantId: domain.tenantId, expires: Date.now() + TTL_MS });
  req.tenantId = domain.tenantId;
  next();
}

The important line in auth is the tenant match. A valid token from shop A must be useless on shop B's domain:

// middleware/requireAuth.js
import jwt from 'jsonwebtoken';

export function requireAuth(req, res, next) {
  const header = req.get('authorization') || '';
  const token = header.startsWith('Bearer ') ? header.slice(7) : null;
  if (!token) return res.status(401).json({ error: 'AUTH_REQUIRED' });
  try {
    const claims = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'] });
    if (claims.tid !== req.tenantId) {
      return res.status(403).json({ error: 'TENANT_MISMATCH' });
    }
    req.user = { id: claims.uid, role: claims.role };
    next();
  } catch {
    return res.status(401).json({ error: 'TOKEN_INVALID' });
  }
}

Roles have a small JavaScript trap worth showing:

// middleware/requireRole.js
const RANK = { STAFF: 1, ADMIN: 2, OWNER: 3 };

export const requireRole = (min) => (req, res, next) => {
  const have = RANK[req.user?.role];
  // `undefined < 2` is false in JS, so a naive `if (have < RANK[min])`
  // would let an unknown or missing role straight through.
  if (have === undefined || have < RANK[min]) {
    return res.status(403).json({ error: 'ROLE_NOT_ALLOWED' });
  }
  next();
};

Unknown means deny. Always.

Plans live in one file

Limits and features come from a single plans.js. Middleware, the admin UI and the billing page all read from it, so there is no second copy to drift out of sync.

// config/plans.js — numbers are illustrative, pricing isn't final
export const PLANS = {
  STARTER:  { maxProducts: 100,    maxUsers: 2,  agent: false, analytics: false },
  PRO:      { maxProducts: 1_000,  maxUsers: 5,  agent: true,  analytics: true  },
  BUSINESS: { maxProducts: 10_000, maxUsers: 15, agent: true,  analytics: true  },
};

export const requirePlanFeature = (feature) => (req, res, next) => {
  const plan = PLANS[req.subscription?.plan];
  if (!plan) return res.status(403).json({ error: 'NO_ACTIVE_PLAN' });
  if (!plan[feature]) {
    return res.status(402).json({ error: 'PLAN_UPGRADE_REQUIRED', feature });
  }
  next();
};

L3 — Data: one database, shared schema

I considered a schema or a database per shop. Both give stronger isolation, but every migration then runs N times, and with a solo operator that's where things break at 2 a.m.

So: one PostgreSQL database, a shared schema, a tenantId on every business row, and composite indexes that start with it (@@index([tenantId, ...]) in Prisma).

The weakness is obvious: isolation depends on application code never forgetting the filter. Two planned layers cover that:

Isolation tests that run before every commit. Tenant A logs in and tries to read, update and delete tenant B's products, orders and customers. Every attempt must fail. I already run this pattern on another platform of mine.

Row-Level Security as a second wall:

ALTER TABLE "Product" ENABLE ROW LEVEL SECURITY;
ALTER TABLE "Product" FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON "Product"
  USING ("tenantId" = current_setting('app.tenant_id', true))
  WITH CHECK ("tenantId" = current_setting('app.tenant_id', true));

With Prisma, this means setting app.tenant_id inside each transaction (SELECT set_config('app.tenant_id', $1, true)), and making sure the app's database role can't bypass RLS. That's the part I'd most like feedback on.

The AI agent can't choose a tenant

Each shop gets an assistant that can answer "what's low on stock?" or "top customers this month?" and perform a few write actions. The model never receives a tenantId as a parameter. The tools close over it on the server:

// agent/tools.js
export function makeTools({ tenantId, prisma }) {
  return {
    lowStock: async ({ threshold = 5 }) =>
      prisma.productVariant.findMany({
        where: { tenantId, stock: { lte: threshold } },
        select: { sku: true, name: true, stock: true },
        take: 50,
      }),
    // recentOrders, salesSummary, adjustStock, ...
  };
}

The model sees a tool called lowStock with one optional number. However cleverly a prompt is written, there is no argument it can pass to reach another shop. Write tools also respect role and plan, and agent messages are metered per billing period.

Background jobs without Redis

Renewals, low-stock alerts, the email outbox and usage rollovers run in a separate worker. The queue is a Postgres table:

UPDATE "Job"
SET status = 'running', "lockedAt" = now()
WHERE id = (
  SELECT id FROM "Job"
  WHERE status = 'queued' AND "runAt" <= now()
  ORDER BY "runAt"
  FOR UPDATE SKIP LOCKED
  LIMIT 1
)
RETURNING *;

SKIP LOCKED lets more than one worker pull jobs without taking the same one twice. A sweep puts jobs back in the queue if they've been running for too long. One less service to run, monitor and back up.

L4 — External services, HTTPS only

My VPS provider blocks outbound SMTP ports, which turned out to be a useful constraint: everything external is an HTTPS API.

Email: Resend
AI: Gemini (I'm consolidating my AI traffic there, away from OpenAI)
Payments: card, IRIS (Greece's instant payments) and cash on delivery; provider not chosen yet
Shipping: parcel lockers and courier vouchers; provider not chosen yet
myDATA (Greek tax e-invoicing): deliberately not in the core, handled through a certified provider

Rules I work by

These matter more to me than any framework choice:

No auto-deploy. AI agents write to disk and report. Publishing is a human decision.
Proposal before apply. Every change to production starts as a written proposal with a rollback plan.
Backups live outside the web root. I've found exposed backup files on my own servers before. Once is enough.
Real numbers only. If a metric isn't measured, the UI shows "—", never a made-up value.

What's next

Audit the existing code against this diagram, box by box
Host-based tenant resolution and the tenant-match check
The isolation test suite, then RLS
Checkout, and the first live shop

I'd like your take

Have you run Postgres RLS with Prisma in production? Worth it, or more pain than protection?
Custom domains for tenants: Cloudflare for SaaS custom hostnames, or one zone per shop?
Postgres as a job queue: where did it stop being enough for you?

I'll post the audit results next in this series.

Alexandros · Web Host Pro · Diakopto, Greece

DEV Community: Alexandros Kyvrikoseos

42 domains, one VPS, Cloudflare Free: the five things that actually broke

1. One grey cloud exposes everyone

2. Flexible SSL: a padlock with plain HTTP behind it

3. Switching to Full (strict) took four sites down

4. The change that didn't show up

5. nginx -t passed, and nothing changed

Bonus: what a sweep found in the web roots

The checklist I run per zone now

"How I let AI agents work on my production server without breaking it"

[Human Gate]

Rule 1: Agents propose, I apply

Rule 2: Some commands are never the agent's

Rule 3: Never prisma migrate dev on the server

Rule 4: Every command has an address

Rule 5: A test that has never failed has proven nothing

Rule 6: Silent fallbacks are lies

Rule 7: Real numbers only

Rule 8: Ground truth beats screenshots

The small rules

What it costs, what it buys

ShopOS: designing a multi-tenant e-shop SaaS on a single VPS

Where it actually stands

Why multi-tenant at all

L1 — Edge: Cloudflare

L2 — One VPS, on purpose

The request pipeline

Plans live in one file

L3 — Data: one database, shared schema

The AI agent can't choose a tenant

Background jobs without Redis

L4 — External services, HTTPS only

Rules I work by

What's next

I'd like your take

5. `nginx -t` passed, and nothing changed

Rule 3: Never `prisma migrate dev` on the server