Why I went down this road

At the start, I wanted control over things. A server meant I could let things run forever without limits. It's not just that something would live there—it's the feeling that I understand it inside, that I have complete mastery.

Concretely, I was drawn to trying things that are worth running unattended. A web app with its own API. Market data collection. A chat application. Things that run nonstop and gather information. In my head it looked efficient. In reality it had a hidden price.

What ran on it

I had several applications at once. A web app with a database. A scanner that collected market data. A chat application. In the background, an experimental bot in demo mode. Everything ran in different places on the server, each on its own address.

To make it work, I had automated processes—services that watched whether everything kept running. A proxy server that routed everything correctly. Regular health checks of the system. Every night the databases and logs got backed up. All automatic, no hand-holding from me.

The disk accumulated about 10 gigabytes of data. Product databases, historical market data, automation scripts. It all lived on the server, running without me having to monitor it manually.

Specs and cost

I had two servers. One in Germany in Falkenstein, model CX53: 16 processor cores, 32 gigabytes of RAM, 320 gigabytes of SSD. It cost 27.21 EUR per month, roughly $29 USD. The other ran in Finland.

Per year it came to around $348 for one. Two servers meant over $700 annually. That sounds cheap. But the real point was that I did almost nothing on them—they ran themselves and I just watched.

How I set it up

I didn't log into the server via command line. I told Claude what I wanted and how it should run. Claude handled the rest. He connected to the server, installed what was needed, set up security. I just talked to Claude in a text window.

The web app ran over an encrypted connection. Certificates renewed themselves. The database got backed up every night. Everything important was protected and stored elsewhere too.

Configuration lived in files. Passwords, tokens—always in the environment, never in the code. The firewall had rules. SSH was locked down. No risk.

What worked and what didn't

Technically it worked. The web app ran. Data got collected. Every service ran without issues. Backups happened. From a technical angle it was solid work.

But the problem wasn't the code. The problem was what the server actually did. The web app had no visitors. Data got collected, but for what? The experimental bot in demo mode made no sense. All that infrastructure, all that automation—it ran, but nobody used it. You watch things run themselves and think it's brilliant. Really you're just sitting and staring at a monitor.

Second problem: a server wants attention. It doesn't take care of itself. You need to check in now and then to make sure everything's fine. If it were running with real money on the line, you'd need to respond in seconds. I didn't want to do that, and it made no sense to pay for it.

Why I shut it down

Work moved to managed hosting. The web app now runs on Vercel at $40 a month for all my web projects combined. Database on Supabase for free. The private server was a cost with no return.

The money is clear: 27 EUR per month. But the attention the server needs? That's not tracked. Three or four hours a month checking. Wondering if something breaks. When nothing real was actually running on it, it was pointless stress. Like buying a car and letting it sit.

Everything important I have backed up. Data on GitHub. The experimental bot on my local machine in case I ever return to it. The server was just a monthly bill for nothing.

For whom yes, for whom no

A private server makes sense when something actually runs on it. Thousands of orders a month? Then it's worth watching. An API that others use from outside? Then yes. Something that needs live money and immediate attention? Then you need a server under you.

It doesn't make sense in an experimental phase. When you're trying things out. When the web app isn't finished. When you don't yet know if it'll work. Cloud services like Vercel or Supabase are simpler. You pay less and don't have to watch. If your web app grows later, cloud services can scale without migration.

The lesson: you don't want to own infrastructure unless you live by it. Cloud seems more expensive than it is. A private server seems cheaper than it is. The cheapest option is when you don't have to think about it.

The server was a good education. Now I know what can be run and what hides under the hood. But I don't do it anymore. Everything new runs on Vercel, Supabase, and Cloudflare—details in What I use.