When you host on a big cloud, the attack surface is not just your code. It includes every employee at that provider, every third-party tool each employee uses, every OAuth connector those tools have, every other customer on the same platform, and often another cloud underneath it all.
The Vercel incident showed this. An employee installed a third-party AI tool. That tool got compromised through an infected machine. The attacker used OAuth tokens to reach the employee’s Google Workspace, pivoted into Vercel’s internal systems, and read environment variables of real customers. You did not install that AI tool. You did not approve that OAuth scope. But the consequences reached your project anyway.
There is also a target value problem. Hackers rarely hunt small projects one by one. They hunt platforms that host thousands of projects, because one breach gives them thousands of victims at once. Your project is not the prize. The platform is. You just happen to be inside it.
When you use Vercel, you are not on one cloud. You are on Vercel, which runs on AWS. Two platforms. Two sets of employees. Two sets of third-party tools. Two sets of co-tenants. Your actual attack surface is the union of both, and you have visibility into almost none of it.
A VPS on Hetzner or similar is different. You install only what you need, know every open port, hold every key, control every update, and have a short list of services you put there yourself. Or go further: a private server with the same rules.
Cloud platforms also sell you a lot of things you probably do not need. Autoscaling for traffic you do not have. Edge functions when one region would do. Ten integrations when you use two. You pay for all of it, and every unused feature is still part of the surface.
A VPS that can comfortably host most indie projects costs somewhere between 5 and 20 euro per month. That is less than one mid-tier SaaS subscription. Fewer moving parts, fewer integrations, and often fewer exposure points than a platform wired into hundreds of services you never chose. Setting it up is easier than most developers assume.
Yes, you take on patching, backups, firewalls, and monitoring. That is work. But the surface is small, it is known, and it is yours.
AI also lowers the bar here. You can ask Claude or a similar tool to configure nginx, write firewall rules, set up automated backups, review a systemd unit, harden SSH, or explain a log you do not understand. Work that used to need a senior sysadmin is now realistic for a careful solo developer. That gap has mostly closed.
What is actually more secure?
A cloud stacked on another cloud, with an unknown number of employees, connectors, and third-party tools, where you are one customer of thousands? Or a minimal box you understand end to end?
I do not think there is one answer for everyone. Someone with zero infra experience still should not ship production on a server they cannot debug. But a small team with some infra curiosity should think about this harder than the industry default suggests. The default answer is “use the cloud, it’s more secure than you.” After this weekend, I am not sure that is still obviously true.
Which option you can actually reason about might matter more than which one is theoretically safer. Running your own server is more work. But if you know what you are doing, you know exactly what is running, what is open, and who has access. With a managed platform, you do less but you trust more: their employees, their tools, their vendors, their decisions. More work and trust in your own knowledge, or less work and trust in someone else’s?