For a long time, I had a VPS running online almost all the time. It had SSH exposed, some services running, a domain pointing to it, and a few things hosted on top of it.
From the outside, everything looked fine. The services were reachable, Docker containers were running, and I could connect to the server when I needed to. So I treated it like many beginners probably do: once the deployment worked, I moved on.
But after spending more time self-hosting, I realized something uncomfortable. Having a VPS and actually managing a VPS are not the same thing.
I was able to install things, configure services, expose ports, and make applications run. But I was not really checking what was happening after that. I was not looking regularly at SSH attempts, logs, updates, firewall status, failed logins, suspicious activity, or even the general health of the machine.
In practice, I had a server connected to the internet, but very little visibility over it.
The problem with “it works”
When you are learning self-hosting, it is easy to focus only on deployment. You install Docker, run a container, configure Nginx or a reverse proxy, add SSL, point a domain to the server, and once the application opens in the browser, it feels like success.
And it is success, at least partially.
But the problem is that the server does not stop existing after the deployment. It continues to receive traffic. Bots continue to scan the internet. SSH keeps getting hit by random login attempts. Logs continue to grow. Updates pile up. Services can fail silently. Configuration mistakes can stay hidden for a long time.
The application may look fine, while the server behind it is slowly becoming something you do not fully understand anymore.
That was my case. My VPS was not necessarily broken, but I was not observing it properly. I only checked things when I needed to deploy something new or when something stopped working.
That is not really management. That is more like hoping everything is fine.
Silence is not always safety
One of the biggest mistakes I made was assuming that because nothing obvious was happening, everything was okay.
No alert? Good.
No crash? Good.
No visible issue? Good.
But that logic is weak when you do not have any monitoring or regular checks. If you are not looking at logs, you do not know what is normal. If you never check failed SSH attempts, you do not know how often your server is targeted. If you do not check your firewall or Fail2Ban status, you do not know if your protection is actually active.
Silence can feel reassuring, but sometimes it just means you are not listening.
This was the moment where I started changing my approach. I did not want to become paranoid, and I was not trying to turn my small VPS into an enterprise infrastructure. I just wanted a clearer picture of what was happening.
Why I started building a small VPS security toolkit
At first, I started doing manual checks. I would SSH into the server and inspect some logs, check services, verify Fail2Ban, look at disk usage, and review a few security-related details.
It helped, but it was not something I wanted to repeat manually every time. Manual checks are useful, but they are also easy to forget. And when something depends only on memory, it usually stops happening after a while.
So I started building a small VPS security toolkit for myself.
The idea was simple: create a set of scripts that could give me a quick overview of the server without having to remember every command manually.
Nothing fancy. Nothing enterprise. Just practical scripts to answer basic questions like:
- Is the server healthy?
- Are there many failed SSH attempts?
- Is Fail2Ban active?
- Is the firewall configured?
- Are there pending security updates?
- Are there suspicious login attempts?
- What services are running?
- Is disk or memory usage becoming a problem?
The goal was not to replace real security tooling. The goal was to stop being blind.
What changed for me
The most useful part was not the scripts themselves. The useful part was the visibility they gave me.
For example, checking SSH logs helped me understand how common automated login attempts are. It is one thing to know that “bots scan servers on the internet.” It is another thing to see the attempts on your own machine.
Checking Fail2Ban helped me confirm that it was not just installed, but actually active and doing something.
Checking updates reminded me that a VPS is not something you configure once and forget.
Checking services helped me notice what was exposed, what was running, and what deserved more attention.
None of this made me a security expert. But it made me more aware. And for a beginner or intermediate self-hoster, that is already a serious improvement.
The real lesson
The biggest lesson I learned from this project is that basic visibility should come early in self-hosting.
It is tempting to focus only on adding new services. A dashboard here, a media server there, a personal app, a database, a reverse proxy, maybe a few experiments from GitHub. That part is fun, and it is one of the reasons self-hosting is interesting.
But the more things you run, the more important it becomes to understand the state of your server.
You do not need to start with a complex monitoring stack. You do not need to build a SOC at home. But you should at least know how to check the basics.
For me, the minimum starts with:
- SSH access and failed login attempts
- firewall status
- Fail2Ban status
- running services
- exposed ports
- pending updates
- disk usage
- memory usage
- important logs
- basic system health
These are not advanced topics, but they matter. They give you a baseline. And having a baseline helps a lot when something goes wrong.
What I would tell another beginner
If you have a small VPS, do not wait until something breaks before learning how to observe it.
Start small. Learn the basic commands. Check your logs from time to time. Understand what services are running. Know which ports are exposed. Make sure your SSH configuration is intentional. Verify that your firewall and protection tools are actually working.
Then automate the boring checks.
Automation does not have to be complicated. Even a simple script that summarizes the health and security state of your server can be useful. The point is not to build the perfect tool. The point is to create a habit of visibility.
Because when you understand what “normal” looks like on your server, it becomes much easier to notice when something is wrong.
Conclusion
For years, I had a VPS that was online and running services, but I was not really managing it. I was mostly deploying things and assuming the rest was fine.
Building a small VPS security toolkit helped me change that mindset.
The project is simple, and I am still learning a lot about security. But it gave me something important: visibility.
And that was the real starting point.
The goal is not to become a security expert overnight. The goal is to stop treating your own server like a black box.
Top comments (0)