Running Your Own Server in 2026: What We Secure First (and Why)

Running Your Own Server in 2026: What We Secure First (and Why)
Photo by Scott Rodgerson / Unsplash

Self-hosting isn’t about control it’s about responsibility.

The moment you expose a server to the internet, it becomes a target. Not because you’re important, but because automation doesn’t care. Bots scan everything, all the time, looking for one weak assumption.

This post outlines the first things we secure on any new server, before adding “interesting” services like mail or apps.

1. SSH is the front door

If someone gets SSH, they get everything.

Our baseline:

  • Password authentication disabled
  • Key-only access
  • Root login locked down or removed
  • Non-standard ports don’t add security discipline does

We also assume credentials will leak eventually, which means rate limiting and banning matter.

Fail2ban or equivalent isn’t optional. It’s table stakes.

2. Firewalls before services

A firewall is not a “later” task.

Only three categories of ports should be open:

  • Public services (HTTP, HTTPS, mail)
  • Management (SSH restricted)
  • Internal traffic (never exposed)

Everything else stays closed by default.

If a service needs internet access, it should justify it.

3. Containers are not security boundaries

Docker makes deployment easier not safer.

We treat containers as:

  • Process isolation, not trust boundaries
  • Replaceable, not precious
  • Minimal by default

That means:

  • No privileged containers
  • No unnecessary capabilities
  • Internal networks for databases and mail components
  • Reverse proxies as choke points, not shortcuts

4. Mail servers are hostile territory

Running your own mail stack (Mailcow, Postfix-based systems, etc.) is where theory meets reality.

Mail servers are:

  • Constantly probed
  • Relentlessly abused
  • Judged by reputation systems you don’t control

Before accepting a single email, we ensure:

  • Proper DNS (SPF, DKIM, DMARC)
  • TLS everywhere
  • Rate limits on SMTP
  • Strong authentication on submission ports
  • Logs monitored, not ignored

Mail is not “set and forget”. It’s an ongoing relationship.

5. Logs are signals, not noise

If you’re not reading logs, you’re flying blind.

We pay attention to:

  • Auth failures
  • SMTP abuse attempts
  • HTTP probing for common exploits
  • Sudden traffic pattern changes

Most attacks aren’t sophisticated they’re repetitive.
That’s good news, if you’re watching.

6. Backups are part of security

Security isn’t just preventing access it’s recovering cleanly.

Every critical service needs:

  • Automated backups
  • Off-server storage
  • Regular restore tests

If you’ve never restored it, you don’t have a backup.

The mindset shift

The biggest mistake in self-hosting is assuming:

“I’ll harden it later.”

Later is usually after something breaks or worse, after something leaks.

Security isn’t paranoia.
It’s respect for the fact that the internet is not friendly.