For developers and small agencies who set up a new server for every client site
A New Client Shouldn't Mean Another Server To Babysit
If every new client means spinning up another VPS, installing the stack, and pointing DNS by hand, you already know it stops scaling fast. I automated the whole thing: one platform, one git push, and a new client site is live in minutes. Here's what I'm building to teach it.
You already know the drill
New client. Spin up a server. Install the stack. Point DNS. Set up SSL. Test it. Hand it off. Repeat for the next client, and the one after that.
It works. It also doesn't scale. Every new client is another server only you know how to maintain, and none of that time is billable.
Cramming clients onto one bigger server doesn't fix it either
The obvious next move is putting multiple clients on the same server to cut costs and setup time. That's when a new problem shows up: one client's traffic spike, or even just a routine update, can slow down or take out a site that has nothing to do with it.
A small agency running a shared setup hit exactly this: they'd already isolated each client properly, and one client's marketing campaign still starved two unrelated client sites of resources. I hit my own version of it too: a routine deploy, no extra traffic at all, that started starving a neighboring client's site of the resources it needed.
Neither of us found the fix in a beginner tutorial. Consolidating servers by hand doesn't remove the manual work. It just concentrates the risk.
What I'm building
A hosting platform built around one rule: if it can be automated, it is. Point a domain at it, push to git, and a new client site is live with its own isolation and its own TLS certificate. No manual server setup, no repeating the same 10 steps by hand for every new client.
That's the only way I can see to handle real client volume solo, or with a small team, without every new client adding to a pile of manual work that never goes away.
It's not finished yet. Right now I'm still running it, still hitting the edge cases, and writing them down as they happen instead of after the fact. The email list is where that goes out first.
Coolify and Dokploy give you the tool. Nobody sells the judgment.
If you've looked for something better than a plain VPS, you may have already found Coolify or Dokploy. They're free and good, and they solve deploying a single app. They don't tell you what happens once you put several client apps on the same server and one of them has a bad day.
Most Kubernetes courses have the same gap from the other side. They teach the building blocks: how to isolate one app from another, how to set limits, how routing works. They don't tell you which combination actually holds up once real client traffic does something you didn't plan for, or how to automate the whole thing so you're not doing it by hand every time.
Who's writing this
I run SisuOps' own platform on UpCloud (OpenTofu and FluxCD underneath, with the rest automated on top), hosting real client sites and my own, on shared infrastructure. Before this I worked SRE, dealing with the same noisy-neighbor and multi-tenant problems for a living.
This isn't a demo cluster I spun up to make a course. It's the one already running.
Built on EU infrastructure, not by accident
The hosting underneath this is UpCloud, a Finnish cloud provider with EU data centers, not AWS, GCP, or Azure. DNS and CDN run through bunny.net, a Slovenian company, for the same reason. And it's OpenTofu doing the provisioning, not Terraform: same tool, minus being one US company's licensing decision away from disruption. That already happened once, in 2023, when Terraform's license changed overnight and a group of companies and engineers forked it rather than stay dependent on it.
None of this locks you into UpCloud specifically. The whole setup runs on plain Kubernetes, not a cloud's proprietary services like AWS ECS or Fargate, so the only real requirement for a provider is that it can run a Kubernetes cluster. Azure, AWS, GCP, Hetzner, whatever fits: moving the same setup to a different provider is a real but manageable job, not a rebuild. It's the cloud-specific managed services that create lock-in. Plain Kubernetes is what avoids it.
That wasn't originally a political choice. It's turning out to matter anyway. European businesses are moving workloads off US hyperscalers for real, current reasons: data jurisdiction, GDPR exposure, and not wanting infrastructure one policy change away from breaking. If you host client sites, that's not an abstract concern, it's a question clients are starting to ask.
Questions before you sign up
I don't have time to learn this on top of client work.
That's the point of getting on the list instead of piecing this together yourself right now. When it's ready, you get the setup already worked out: what to configure and in what order, not a stack of docs to reverse-engineer nights and weekends.
What if I break production for a paying client while setting this up?
That fear is exactly why this isn't "watch me build a demo." It's built around the failure modes that actually show up with real client traffic, including the ones that only appear after you think you've already handled them.
I don't know Kubernetes at all. Is that a problem?
No. You don't need to become a Kubernetes expert, the automation is the point. You need enough to trust it and fix things when something's actually wrong, and that's what this teaches, starting from a plain-VPS setup like the one you probably already run, not a generic "learn Kubernetes" curriculum.
Isn't Kubernetes overkill for what I actually need?
Maybe, if you only ever host one site. If you're already juggling more than a couple of client sites on separate VPS instances, or hitting per-seat pricing on Vercel or Netlify as you add clients, it stops being overkill and starts being the thing that gets you out of manual provisioning.
There's no course yet. Why sign up now?
Two reasons. The content is still being shaped by who actually shows up here, so answering the optional question above gets you a real say in what it covers. And the first 50 signups lock in $148 instead of the $297 launch price, honored in signup order when it's ready. No payment today: just your spot in that order.
Freelance advice usually says don't host clients yourself, just outsource it. Isn't that right?
That advice exists because most self-hosted setups turn into a snowflake server only you understand, so you're stuck babysitting it forever. That's a real risk. It's also the exact thing a repeatable, git-push platform is built to avoid. You're not turning into a hosting company. You're removing the part of the job that currently eats your weekends.
Have a question this didn't answer?
Email support@sisuops.dev. I read everything that comes in.
Get it when it's ready
Drop your email above. I'll send the real build notes as I hit them, not a countdown timer for a launch that doesn't exist yet.
Get on the list