A practical one-server playbook for running a production-shaped SaaS on a cheap VPS: auth, Stripe subscriptions, webhooks, backups, and a boring de...
For further actions, you may consider blocking this person and/or reporting abuse
As a student, the 'cloud tax' of managed services is a huge barrier to actually shipping projects. This playbook makes it feel much more realistic to host something production-ready without a massive monthly bill.
Thanks, that means a lot.
That’s exactly why I wrote it. When you’re a student or building your first real projects, the default stack pushes you into monthly bills way too early.
If you try the setup, I’d love to hear what feels hardest in practice. For most people it’s not the app code, it’s stuff like env vars, SSL, and having a backup and restore story that’s actually real.
I will definitely try it on one of my hobby projects and give feedback if i encounter any issues, thank you for sharing
Awesome, please do.
If you run into anything confusing, feel free to reply here with the exact step that tripped you up and I’ll tighten the guide. Good luck with the project.
Nice! It’s exactly the kind of “boring, survivable baseline” I tend to favor.
Thank you! Boring + survivable is the goal.
What baseline do you think most teams are missing?
That question is a trap door into everything no one wants to say out loud.
Here’s what most teams are actually missing—not fancy tooling, just the baselines that keep a system alive:
• Tested restores—Backups exist; restores don’t. No one has practiced recovering under pressure, with clocks ticking and data integrity uncertain.
• Secrets hygiene—Environment variables are set once and forgotten. Rotation is rare, revocation is chaos, and no one can tell you which secret is still valid.
• Dependency awareness—Teams run npm install on packages they’ve never audited, written by maintainers they’ve never verified, with transitive dependencies they’ve never mapped.
• Incident response that isn’t “whoever’s awake”—No runbooks, no escalation paths, no decision logs, no post‑incident discipline. Just vibes and adrenaline.
• Actual logging—Logs exist, but no one reads them until something breaks. No baselines for “normal,” no anomaly detection, no drift awareness.
• Access control beyond “everyone’s an admin”—Least privilege is a slide deck concept, not a lived practice. Permissions accrete like sediment.
• Any threat model at all—No one asks “what happens if X gets compromised,” for any value of X: database, CI pipeline, package registry, developer laptop, or the human operator.
None of these are advanced.
They’re the minimum viable baselines for a system that intends to survive its own success.
Totally agree, and that’s a brutally accurate list.
The “tested restores” point especially hits: everyone feels safe because backups exist, but the first real restore is during an outage… which is basically roulette.
If you had to pick one of these to implement first for a small team (say 3–10 devs) with limited time, which gives the biggest survival boost? And what would the “minimum viable” version look like in practice?
Bro, if you want me to seed your next gumroad product, let's just team up and hit the SMB market together. I've already been building this out.
That is an interesting proposition. The SMB market is definitely where the real stability is compared to selling tools to developers.
I generally prefer the solo route to keep velocity high, but I am pragmatic. If you have a specific vertical or distribution channel already built, I am open to chatting.
check my bio for email or add me on linkedIn!
Refreshing! No cloud, Kubernetes, PaaS, serverless etc etc ...
Thanks leob! Always good comments from you!
You're welcome - still a question though:
If this SaaS app is doing any serious multi user "transaction" processing, isn't it then better to skip SQLite and go for MySQL (or PostgreSQL) right away?
Running a web server/app server and MySQL on one VPS is not a big deal and very well possible, although I don't know if the same is true for that "$5 VPS" ... but, in my experience, MySQL is pretty lightweight, and next to "zero maintenance" - I'm running it routinely on simple VPS boxes without ever looking at it (including automated backups).
Good question.
If you expect heavy write traffic or lots of concurrent transactions from day one, I’d start with Postgres/MySQL. Running app + DB on one VPS is totally doable.
My point is just that for many early SaaS apps, SQLite in WAL mode is enough and keeps ops simple. One file, easy backups, easy restores.
And if it stops being enough, you can move to Postgres later without rewriting the whole app.
What kind of workload are you thinking of when you say serious transactions?
Point is just whether concurrent ACID transactions (which you can even have with a low traffic app) are "completely" reliable with SQLite ...
But yeah, point is also that I'm used to MySQL, so I guess for me that would make it the "simple" option, since already I know it ... backups are also trivially easy - execute a command, you get a file, you zip/archive that somewhere - not that different from SQLite, for the rest it's also close to zero maintenance.
Yep, that’s a fair way to put it.
SQLite is ACID and reliable, but if you have overlapping write transactions you can run into lock contention, and that can feel “unreliable” even if it’s not data corruption.
If MySQL is your default and you’re comfortable running it on the same VPS, that’s a totally boring and valid choice. App plus MySQL on one box is still a big win versus managed-service sprawl.
My argument isn’t really “SQLite good, MySQL bad”. It’s “keep it on one box and keep ops simple until the workload forces you to split things out.”
Thanks!
Curious from a business perspective: are you setting this up as a sole proprietor or an LLC, since you'll be taking payments at some point? I have a cloud tax as well, but trying to maximize it by building in more than one space.
I’m planning to start simple as a sole proprietor just to validate demand and keep the admin/tax overhead low, then switch to an LLC once there’s consistent revenue or any meaningful liability/contract needs.
Also curious what you mean by “cloud tax” are you talking about deducting cloud spend, or sales tax/VAT on payments?
That's too much to validate an idea to be honest. For us we are using:
Tanstack Start + Instant DB (has auth init) + Cloudflare Workers.
All this is free until you hit the limits which is good to do (we hit it with our first app).
If the app or the idea made it we pass to the second step self hosted solution but we keep things low :
Tanstack Start + Convext (or Instant DB) self hosted + Cloudflare CDN
Here we use Hostinger for production VPS we usually have them bought on Black fridays for 1 year or three years based on our needs. They don't cost much . We use also (now they got a little up for some reasons) SSDNodes for stagings and testing servers.
If the app get too big (didn't happen yet) :)