The reason was not need. Ordinary hosting was more than enough for a site like this. What the writer was really after was curiosity: knowing what sits behind the screen every time the deploy button is pressed. So the writer bought a small VPS and took care of it alone, without a teacher, without a team, without anyone to answer when something broke at midnight.

The First Day: A Black Screen

What arrived first was not a graphical panel but a command line and one SSH connection. The first days were mostly invisible work: creating an SSH key, disabling password login so only the key could enter, opening only the necessary ports through the firewall (SSH, HTTP, HTTPS), and making sure the server responded before installing anything. There was no application yet. There was an empty machine and security rules set up first.

That habit has followed the writer everywhere since: before installing anything, make sure there is only one door and the key is not a guess.

Software the Writer Did Not Write

To run applications, the writer installed Dokploy, an open source platform that handles deployment on top of Docker. Inside it run things the writer did not write either: Docker Swarm to run the services, Traefik as the reverse proxy handling domains and TLS, PostgreSQL and MySQL for the data.

Learning here means reading. Official documentation first, then GitHub issues when the documentation does not answer, then community conversations when no issue exists. The first lesson came from versions: a platform like this has to be pinned to a specific version instead of following whatever is newest, because a small version difference can change behavior that already works in production. Since then every install names its version explicitly, and before two machines are considered the same, their differences are checked one by one.

The second lesson came from documentation quality. Good documentation feels like a gift from strangers; stale tutorials feel like traps, because they confidently describe a version that no longer behaves that way. The writer learned to check the date and the version number before trusting any instruction found online.

Learning from Numbers That Do Not Lie

The VPS the writer holds has only 1.9 GB of RAM. To avoid running out, 4 GB of swap was added, and that swap turned out to be genuinely used. The 40 GB disk runs at around sixty percent usage. These numbers make the decisions: services cannot all be opened at once, logs must be trimmed, and every additional service needs a reason.

Learning alone here means nobody warns you first. When RAM runs out, what stops is the application. So the writer got used to watching: RAM, disk, Traefik and Dokploy logs, for days after every big change.

A Backup That Was Actually Tested

The scariest part became the part the writer liked most: moving the entire contents of one machine to another. The plan was simple: reinstall the same versions on a second machine, dump the database, copy the volumes that matter, redeploy from the same git repository, then switch over. No machine cloning; what moved was the data and the steps.

The old machine was not turned off. It stayed alive with its application stopped, as a way back in case something turned out wrong. And after the move, what the writer did was not celebrate but watch for days: RAM, disk, logs, certificates. A backup that has never been restored is not a backup; it is hope with a filename.

Everything Was Open Source

Everything the writer runs on this small machine was not bought: Ubuntu, Docker, Dokploy, Traefik, PostgreSQL, MySQL. What was paid for is only the rent of the machine. In return the writer owes unknown people, and that dependence is exactly what gives the learning its meaning. Documentation written well feels like a gift; an issue answered by a maintainer feels like direct help.

The writer's own applications live here too. This portfolio keeps its data in PostgreSQL running on the same VPS, and Kas TIY, the cash book application the writer built for the organization, runs there as well while being prepared as an open source project. Even a Laravel Filament application for a client runs on the same machine. One machine, real production, nobody watching over it.

Closing

Plenty of tutorials can explain how to install Docker. What none of them can explain is the first time a server stops responding and the writer had nobody to ask. Learning to operate a VPS on your own, in the end, is not about memorizing commands; it trains the writer to read numbers, read documentation, and make decisions with incomplete information. The entry price was a small machine and the determination to take care of it alone.