Why a Production Ready Server Setup Matters
If you’re seriously asking that question, I’m already a little worried about you.
No offense — but I probably wouldn’t trust you with my servers just yet.
Setting up a server for production isn’t for shits and giggles.
It’s a responsibility. A commitment.
In my case, my servers don’t just host toy projects.
They store critical databases, handle email infrastructure, and power real-world applications.
Considering that, setting up your server in a secure and stable way isn’t optional — it’s essential.
Know Your Stack, Before the Terminal
Before even thinking about setting up a server properly, we need to get some factors straight. We need to know what we need, and what the server is going to be used for. Following topics are critical thoughts you will not get around considering:
- VPS vs. Dedicated
- Distro (Ubuntu, Debian, etc.)
- If you complain about me not listing Windows, please get off of my blog.
- Use-Case and what you really need
VPS vs. Dedicated
When building your stack, it’s crucial to distinguish between a Dedicated Server and a Virtual Private Server (VPS).
Before getting into the details, let’s first define VPS and Dedicated:
What is a VPS?
Let’s imagine this: You’re getting ready to move, you pack your things into boxes to make transportation easier. Now, you don’t get one large box for one small item: You get one large box and put many items in it.
That’s how a VPS works: Your hosting provider purchases one server with a lot of resources, and you get assigned one small portion of said server (the server is called a Node, and I am going to refer to it as such).
The VPS itself is usually implemented as a container or virtual machine — technologies like LXC or KVM are common, but you won’t need to worry about that just yet.
Another fact to consider is: A VPS shares resources. You do get what you pay for, don’t get me wrong – but the CPU and the RAM are shared, meaning:
One node can hold so many users, and those users can host processes on their servers. Now, if one of those brain-rot users decides to try a crypto miner, that will affect the cpu’s performance, as it is a difficult task for the CPU to handle.
You can imagine it as such: You get your slice of the pie, but that pie’s CPU gets chewed on by everyone else at the table.
Now, if you’re just going to host a game server for your imaginary friends, you’re most likely not going to need a Dedicated Server. If you’re going to host a portfolio, you’re not going to need one either.
What is a Dedicated Server?
Unlike a VPS, a dedicated server does not share resources. You’re not just renting a slice, you own the whole damn pie – like a greedy kid unwilling to share.
MEANING:
- Full CPU, full RAM, full disk – all yours.
- No noisy neighbours.
- No unexpected load spikes from someone mining crypto at 3am.
If your server runs slow: That’s on you. (Or the datacenter, but that’s unlikely, long as it’s not Skylink)
Your architecture.
Your services.
Your responsibility.
It’s freedom, and freedom comes with accountability.
Wow’ we just got lost in a whole damn rabbit hole about VPS vs Dedicated, didn’t we? Let’s continue with the other topics, been writing like my life depends on it god damn it.
Distro (Ubuntu, Debian, …)
Let’s be real: There’s not much difference between Ubuntu and Debian. Ubuntu is like Debians small brother – same DNA, just wrapped in corporate branding and owned by Canonical.
If you’re just starting out: Both are great. But, if you’re going to use a Dedicated Server (spoiler: You will, in this series), I personally recommend going with Proxmox and separating the services as much as possible.
Proxmox brings back the concept of nodes – yeahhh, those again. But this time, you will become the provider.
You can create VPS instances (via LXC) or even full-blown Virtual Machines with desktop environments.
Like windows, but … uhhh, please don’t? If you’re going to use a Desktop Environment, do yourself the favor of setting up Linux with Gnome, KDE Plasma or whatever, just … don’t do windows please.
You’re here to build servers after all, not to update Edge and Cortana.
Use-Case – And What You Really Need
I’ll try to make this as short as possible, because this post is 774 words long already god damn it.
Sooo … Let’s just list use-cases and the best approach shall we?
Self-Hosting a Portfolio
If all you wanna host is your portfolio … well, sorry to inform you – but you don’t need a VPS or a Dedicated Server. You don’t need to self-host your portfolio, there’s providers such as Vercel that do a great job at hosting that for you.
But if you really do wish to self-host your portfolio, go with a VPS: You don’t need a tank just to deliver pizza, although … that would be cool as fuck, if you deliver pizza with a tank, hmu.
Running a Game Server
Wanna host Minecraft for your imaginary Discord cult?
Go VPS. You don’t need a whole datacenter just for 3 friends who log in once a month.
Running a Mailserver
Now we’re talking.
You could run it on a VPS —
but if you value deliverability, reputation, and not crying at 3am, go Dedicated.
Or better yet: host your own VPS on your Dedicated Server.
(Ssshhh… more on that in a future post.)
Mailservers are divas.
And they’re sassy af.
Running Nextcloud
VPS = totally fine.
Just don’t store your entire anime stash in /media without backups. I warned you.
Security Starts Before Installation
Alrightyyyy — enough about boxes, nodes, divas, and tanks.
Now that we know what we’re working with (or at least I do — can’t speak for you),
it’s time to make sure nobody breaks into our shit.
If someone does manage to break into yours…
yeah, that’s a skill issue right there.
In this section, we’re going to focus on:
- Why security isn’t optional (even for test servers)
- Root access is power — and power attracts chaos
- Choosing a hoster that isn’t shady as hell
- DDoS protection, firewalls, and basic hygiene
Why Security Isn’t Optional (Even for Test Servers)
You’ve read over 1000 words by now, so I’ll assume you’re well aware:
I’m madly in love with metaphors — so here’s another one.
Let’s imagine this:
You’re moving out. Again.
(Seriously, settle down already.)
But this time, you’re building a house. No more rent, financial freedom, baby.
You hire a company to install the doors, windows, and facades.
They give you a 2-week ETA.
Until then, you don’t want the neighborhood kids stepping foot on your construction site, do you?
Yeah. Didn’t think so.
So what happens?
Temporary wooden doors. Basic. Placeholder.
And let’s be real — you could probably kick that thing in.
(Unless you’re weak as hell.)
Now here’s the parallel:
When you rent a fresh server, it comes like that —
placeholder auth, default configs, weak entrypoints.
Sure, it might have password authentication.
But like that wooden door, it can be kicked in —
just with enough brute-force attempts from some botnet halfway across the world.
That’s why security isn’t optional. Not even for “test” boxes.
You build like it matters — because it does.
Root access is power — and power attracts chaos
We just talked about why security isn’t optional – and now, we’re going to talk about one of the most crucial risks: Root access.
Imagine root access like letting your friend sign the documents of your mortgage – officially, he owns it. He owns the house, and the house – in that case, is your server. Root is the administrative account, that should under no circumstances be used as your default user.
Just like the friend that signed the mortgage of your house, the root user can just delete as he pleases. No sudo, no password verification on risky endeavours – just rm -rf /
No sudo. No questions asked.
Just gone.
Root should never be your default user, and it should absolutely not be exposed via SSH.
Give yourself the power you need — but wrap it in layers of accountability.
Choosing a hoster that isn’t shady as hell
As you may have noticed, we’re now just sprinting through the topics: the blog post is way too long for the average joes attention span, and I will not risk losing traffic over this.
Anyways, let’s get to choosing the right hosting provider.
When it comes to choosing the right hosting provider, there’s 3 main points you wanna look out for:
- Location, location, location. You want your server close to your users —not floating somewhere in “Undisclosed Asia Zone 9”.
- Reputation. Don’t just go for the cheapest option. Avoid providers that sound like malware: MrServerZ, OnionHost, FreeVPS — the names alone should give you the ick. If their logo looks like clipart, just… run.
- Specs that aren’t ancient. Check. The. Damn. Specs. If it says DDR3 or an Intel Itanium,
cancel the mission and go touch grass.
If the server comes with a free VPN and a prayer, it’s probably cursed.
DDoS, firewalls, basic hygiene
Okay I’m actually getting tired of writing. I have been writing for at least an hour. Let’s wrap this security chapter with the boring stuff that actually saves your ass.
- DDoS Protection choose a hoster that offers decent DDoS Protection. If a 10-year-old with a booter can nuke your server, it’s not production-ready.
- Firewall Rules
- Default-deny everything.
- Allow only what you need.
- SSH on port 22? Change it, dipshit.
- Open ports “just in case“? Close them. You’re not Amazon.
- Basic Hygiene
- Disable root login
- Disable password authentication
- Use SSH keys
- Set up fail2ban
- Don’t install 300 packages you found on Reddit
- Document your setup
- Use backups. Not vibes.
Security isn’t sexy, I’m speaking from experience. But Dataloss is worse than spending a few hours of existential crisis on security procedures.
Final Word
I don’t know how, but somehow we survived part 1 of “How To Prepare a Production Ready Server Setup” , in the next post we will get into renting a dedicated server from a trustworthy company, and taking action on security measures. Until then, go touch grass and stop drinking so much coffee.
Anyways, bye!
