DEV Community: byteguard

SSH Hardening — The Ultimate Guide for 2026

byteguard — Tue, 05 May 2026 23:39:21 +0000

SSH Hardening — The Ultimate Guide for 2026

If your server has a public IP, it's getting SSH brute-force attempts right now. Not maybe. Not eventually. Right now. Check your auth log:

grep "Failed password" /var/log/auth.log | tail -20

You'll see hundreds — sometimes thousands — of failed login attempts from IPs you've never seen. Botnets scan the entire IPv4 space and hammer port 22 with common username/password combinations 24/7.

My basic VPS hardening guide covers the essentials. This SSH hardening guide goes deeper — every sshd_config setting that matters, key-based authentication, two-factor auth, and monitoring. By the end, your SSH setup will be hardened against everything from automated bots to targeted attacks.

Prerequisites

A Linux VPS (Ubuntu 22.04/24.04 or Debian 12) with root or sudo access
SSH access already working (don't lock yourself out before setting up alternatives)
A second terminal/session open as a safety net while making changes

Warning: Always keep a second SSH session open when modifying SSH config. If you make a mistake, the existing session stays connected. Test your new config in a new connection before closing the old one.

1. Switch to Key-Based SSH Authentication

Password authentication is the weakest link. Even a strong password can be brute-forced given enough time. SSH keys are cryptographically stronger and immune to dictionary attacks.

Generate a Key Pair (on your local machine)

ssh-keygen -t ed25519 -C "your_email@example.com"

Ed25519 is the modern default — faster and more secure than RSA. If you need RSA compatibility (some older systems), use:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

You'll be prompted for a passphrase. Use one. The passphrase encrypts the private key on disk. If someone steals your key file, the passphrase is the last line of defense.

Copy the Public Key to Your Server

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip

Or manually:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Test Key-Based Login

Open a new terminal (keep the old one open) and test:

ssh user@your-server-ip

If it logs in without asking for a password (or asks for your key passphrase instead), key auth is working.

2. Harden the SSH Configuration

The main SSH server config lives at /etc/ssh/sshd_config. Every change below goes in this file. After editing, restart SSH to apply:

sudo systemctl restart sshd

Disable Password Authentication

Once key-based auth works, disable passwords entirely:

PasswordAuthentication no

This single change eliminates brute-force password attacks completely. Bots can hammer port 22 all day — without the private key, they're not getting in.

Disable Root Login

PermitRootLogin no

Even with key auth, there's no reason to allow direct root login. Use a regular user and sudo for privilege escalation. This adds a layer — an attacker needs both the SSH key and knowledge of which user has sudo access.

Change the Default Port

Port 2222

Changing from port 22 won't stop a determined attacker, but it eliminates 99% of automated bot traffic. Most botnets only scan port 22. This is security through obscurity — not a defense by itself, but it reduces noise in your logs dramatically.

After changing the port, update your firewall:

sudo ufw allow 2222/tcp comment "SSH custom port"
sudo ufw delete allow 22/tcp

And connect with:

ssh -p 2222 user@your-server-ip

Disable Empty Passwords

PermitEmptyPasswords no

This should already be the default, but explicitly set it.

Limit Authentication Attempts

MaxAuthTries 3

After 3 failed attempts, the connection is dropped. Combined with Fail2Ban, this makes brute-force attacks impractical.

Set a Login Grace Time

LoginGraceTime 30

The server waits 30 seconds for authentication before disconnecting. The default is 120 seconds — that's too generous. Reduce it to limit resource consumption from idle connections.

Disable X11 Forwarding

X11Forwarding no

Unless you're running graphical applications over SSH (unlikely on a server), disable this. It's an unnecessary attack surface.

Disable TCP Forwarding (if not needed)

AllowTcpForwarding no

If you don't use SSH tunnels, disable forwarding. If you use SSH tunnels for things like database access, leave it enabled or restrict to specific users.

Restrict SSH to Specific Users

AllowUsers yourusername

This is a whitelist. Only the listed users can log in via SSH. Everyone else is rejected before authentication even starts.

Use Strong Ciphers and Key Exchange Algorithms

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

This disables weak algorithms (3DES, SHA1, diffie-hellman-group1). Modern clients support all of these. If you have very old clients that can't connect after this change, they need upgrading — not your server weakening its crypto.

3. Complete Hardened sshd_config

Here's the full set of changes in one block. Add or modify these lines in /etc/ssh/sshd_config:

# Network
Port 2222
AddressFamily inet                    # IPv4 only (set to 'any' if you use IPv6)
ListenAddress 0.0.0.0

# Authentication
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 30

# Access control
AllowUsers yourusername

# Security
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no

# Crypto
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Logging
LogLevel VERBOSE

# Misc
ClientAliveInterval 300
ClientAliveCountMax 2
MaxSessions 3
Banner none

Validate the config before restarting:

sudo sshd -t

If there are no errors, restart:

sudo systemctl restart sshd

Test in a new terminal before closing your current session.

4. Set Up Fail2Ban for SSH

Fail2Ban monitors your auth logs and temporarily bans IPs that fail authentication too many times. Even with key-based auth, it reduces log noise and blocks scanners.

Install Fail2Ban:

sudo apt update && sudo apt install fail2ban -y

Create a local config (don't edit the main config — it gets overwritten on updates):

sudo tee /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600
banaction = ufw
EOF

This bans an IP for 1 hour after 3 failed attempts within 10 minutes. Start and enable Fail2Ban:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Check the status:

sudo fail2ban-client status sshd

You'll see the number of currently banned IPs and total bans since startup.

5. Add Two-Factor Authentication (Optional)

For maximum security, add TOTP (Time-based One-Time Password) as a second factor. You'll need both your SSH key and a code from your authenticator app.

Install the Google Authenticator PAM module:

sudo apt install libpam-google-authenticator -y

Run the setup as your regular user (not root):

google-authenticator

Answer the prompts:

Time-based tokens: yes
Update .google_authenticator file: yes
Disallow multiple uses: yes
Rate limiting: yes

Scan the QR code with your authenticator app (Google Authenticator, Authy, or any TOTP app). Save the emergency codes in a secure location.

Configure PAM. Edit /etc/pam.d/sshd:

# Add at the end:
auth required pam_google_authenticator.so

Update sshd_config to require both key and TOTP:

AuthenticationMethods publickey,keyboard-interactive
ChallengeResponseAuthentication yes

Restart SSH:

sudo systemctl restart sshd

Now login requires: SSH key → TOTP code. Two factors, both under your control.

Warning: If you enable 2FA, make sure you have your emergency codes saved somewhere physically secure. Losing access to your authenticator app AND your emergency codes means you're locked out.

6. Monitor SSH Access

Hardening is only half the job. You also need to know who's connecting and when.

Check Active Sessions

who
w

Review Recent Logins

last -20

Watch Failed Attempts in Real Time

sudo tail -f /var/log/auth.log | grep "Failed\|Accepted"

Set Up Login Notifications

Add this to /etc/profile.d/ssh-notify.sh to get notified on every successful login:

#!/bin/bash
if [ -n "$SSH_CONNECTION" ]; then
    IP=$(echo "$SSH_CONNECTION" | awk '{print $1}')
    echo "SSH login: $(whoami) from $IP at $(date)" | \
        mail -s "SSH Login Alert: $(hostname)" your@email.com 2>/dev/null
fi

Make it executable:

sudo chmod +x /etc/profile.d/ssh-notify.sh

This sends you an email every time someone logs in via SSH. If you see a login you don't recognize, investigate immediately.

Security Considerations

Key rotation. Rotate your SSH keys annually. Generate a new pair, add the new public key, verify it works, then remove the old one from authorized_keys.
Agent forwarding risks. If you enable SSH agent forwarding (-A), anyone with root on the intermediate server can use your agent to authenticate to other servers. Use ProxyJump instead of agent forwarding where possible.
Authorized keys audit. Periodically check ~/.ssh/authorized_keys on all users. Remove any keys you don't recognize.
SSH config on the client side. Create ~/.ssh/config entries for your servers to avoid typing ports and usernames:

Host byteguard
    HostName your-server-ip
    User yourusername
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Then connect with ssh byteguard.

Troubleshooting

Problem: Locked out after disabling password auth.
Cause: Key-based auth wasn't properly configured before disabling passwords.
Fix: Access your server through your hosting provider's console (Hetzner has a web console). Re-enable PasswordAuthentication yes, restart SSH, and fix your key setup.

Problem: Connection refused after changing the port.
Cause: Firewall doesn't allow the new port, or you forgot to update the SSH config.
Fix: Connect via console, check ufw status, and ensure the new port is allowed. Verify sshd_config has the right port.

Problem: "Too many authentication failures" error.
Cause: SSH agent is offering multiple keys before the right one.
Fix: Specify the key explicitly: ssh -i ~/.ssh/id_ed25519 -p 2222 user@server. Or set IdentitiesOnly yes in your SSH client config.

Problem: 2FA prompt doesn't appear.
Cause: PAM module not loaded or sshd_config not updated.
Fix: Verify auth required pam_google_authenticator.so is in /etc/pam.d/sshd. Verify ChallengeResponseAuthentication yes and AuthenticationMethods publickey,keyboard-interactive in sshd_config. Restart SSH.

Problem: Fail2Ban not banning IPs.
Cause: Wrong log path or port in jail config.
Fix: Check sudo fail2ban-client status sshd for errors. Verify logpath matches your system (/var/log/auth.log on Ubuntu/Debian). Verify the port matches your custom SSH port.

Conclusion

SSH is the front door to your server. Every hardening step here stacks — key-based auth eliminates password attacks, Fail2Ban blocks scanners, a custom port reduces noise, and 2FA adds a second factor even if your key is compromised.

If you haven't done the basics yet, start with my VPS hardening guide — it covers UFW, unattended upgrades, and user setup alongside basic SSH config. For protecting other services, check out the Fail2Ban setup guide and Docker security best practices.

Your server is only as secure as its weakest entry point. Make SSH a strong one.

🚨 cPanel auth bypass affects ALL supported versions, patched today. Fix: update to 11.110.0.97, 11.118.0.63, 11.126.0.54, or 11.132.0.29 depending on your branch. If you're running cPanel and haven't patched, assume the panel is exposed. #CyberSecurity

byteguard — Wed, 29 Apr 2026 15:11:35 +0000

Top 10 Self-Hosted Alternatives to SaaS Tools

byteguard — Sun, 26 Apr 2026 15:40:09 +0000

Top 10 Self-Hosted Alternatives to SaaS Tools

The average person pays for 5-10 SaaS subscriptions. Notion, Google Drive, LastPass, Slack, Trello — the monthly total adds up fast. Worse, your data lives on servers you don't control, subject to terms of service that change without notice and companies that can shut down, get acquired, or jack up prices any time.

Self-hosted alternatives let you run the same functionality on your own server. You own the data, you control the access, and the only recurring cost is your VPS. I've tested all of these on my Hetzner box — some I use daily, others I evaluated specifically for this list.

Here's my top 10, ranked by usefulness and ease of deployment.

Quick Comparison Table

SaaS Tool	Self-Hosted Alternative	Category	Docker?	RAM Usage
LastPass / 1Password	Vaultwarden	Passwords	Yes	~30MB
Google Drive / Dropbox	Nextcloud	Cloud Storage	Yes	~256MB
Notion	Outline	Wiki/Docs	Yes	~200MB
Slack / Teams	Matrix (Element)	Chat	Yes	~300MB
Trello	Planka	Project Mgmt	Yes	~150MB
Google Analytics	Umami	Analytics	Yes	~100MB
Mailchimp	Listmonk	Newsletters	Yes	~50MB
GitHub	Gitea	Git Hosting	Yes	~100MB
Pingdom	Uptime Kuma	Monitoring	Yes	~80MB
Plex	Jellyfin	Media Server	Yes	~200MB

Total if you ran all 10: roughly 1.5GB RAM. A single VPS handles the lot.

1. Vaultwarden — Replace LastPass / 1Password

What it does: Full Bitwarden-compatible password manager. Works with all Bitwarden apps — browser extensions, mobile, desktop, CLI.

Why self-host it: After the LastPass breaches, trusting a third party with your passwords is a harder sell. Vaultwarden encrypts everything client-side with your master password. Even if your server is compromised, the vault data is encrypted.

services:
  vaultwarden:
    image: vaultwarden/server:latest
    volumes:
      - vw_data:/data
    ports:
      - "127.0.0.1:8080:80"
    environment:
      - SIGNUPS_ALLOWED=false
    restart: unless-stopped

I wrote a full Vaultwarden setup guide with backups and security hardening.

Verdict: This is the first thing I'd self-host. Everyone needs a password manager, and Vaultwarden is lightweight, reliable, and battle-tested.

2. Nextcloud — Replace Google Drive / Dropbox

What it does: Cloud storage, file sync, calendar, contacts, document editing, and more. It's the Swiss Army knife of self-hosting.

Why self-host it: Google scans your Drive files for ad targeting. Dropbox has a 3-device limit on the free tier. Nextcloud gives you unlimited storage (limited only by your disk), unlimited devices, and zero data mining.

services:
  nextcloud:
    image: nextcloud:latest
    volumes:
      - nc_data:/var/www/html
    ports:
      - "127.0.0.1:8081:80"
    environment:
      - MYSQL_HOST=db
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=<SECURE_PASSWORD>
    restart: unless-stopped

Heads up: Nextcloud can be resource-hungry, especially with many users. Give it at least 512MB RAM and enable Redis caching for a responsive experience. I'll have a dedicated Nextcloud guide covering the full stack with MariaDB and performance tuning.

Verdict: Essential if you want to own your files. The mobile apps and desktop sync clients are solid.

3. Outline — Replace Notion

What it does: A fast, beautiful wiki and knowledge base. Markdown-based, real-time collaboration, search, and nested document trees.

Why self-host it: Notion stores everything on their servers in a proprietary format. Exporting is possible but lossy. Outline uses plain Markdown — your documents are portable by default.

services:
  outline:
    image: docker.getoutline.com/outlinewiki/outline:latest
    environment:
      - DATABASE_URL=postgres://outline:pass@db:5432/outline
      - REDIS_URL=redis://redis:6379
      - URL=https://wiki.yourdomain.com
      - SECRET_KEY=<GENERATE_WITH_openssl_rand_-hex_32>
    depends_on:
      - db
      - redis
    restart: unless-stopped

Heads up: Outline requires PostgreSQL and Redis — it's not as lightweight as some tools on this list. It also needs an auth provider (Google, Slack, OIDC, or email).

Verdict: Best Notion alternative I've tested. The editor is fast, the search is excellent, and the API is well-documented.

4. Matrix (Element) — Replace Slack / Teams

What it does: Decentralized, encrypted chat. Matrix is the protocol; Element is the most popular client. Supports rooms, DMs, threads, file sharing, voice/video calls, and bridges to other platforms (Slack, Discord, Telegram).

Why self-host it: Slack's free tier limits message history. Teams requires Microsoft 365. Matrix gives you unlimited history, end-to-end encryption, and federation — your server can talk to other Matrix servers.

services:
  synapse:
    image: matrixdotorg/synapse:latest
    volumes:
      - synapse_data:/data
    environment:
      - SYNAPSE_SERVER_NAME=chat.yourdomain.com
      - SYNAPSE_REPORT_STATS=no
    ports:
      - "127.0.0.1:8008:8008"
    restart: unless-stopped

Heads up: Synapse (the reference server) is RAM-hungry — expect 300MB+ even with few users. For a lighter alternative, check out Conduit (written in Rust, much lower resource usage but less mature).

Verdict: Excellent for teams and communities. The bridge system lets you consolidate all your messaging into one client.

5. Planka — Replace Trello

What it does: Kanban boards with lists, cards, labels, due dates, attachments, and user management. Clean UI, fast, and does exactly what Trello does without the feature bloat.

Why self-host it: Trello's free tier now limits attachments, Power-Ups, and board views. Planka has no artificial limits.

services:
  planka:
    image: ghcr.io/plankanban/planka:latest
    volumes:
      - planka_data:/app/public/user-avatars
      - planka_attachments:/app/private/attachments
    ports:
      - "127.0.0.1:1337:1337"
    environment:
      - DATABASE_URL=postgresql://planka:pass@db:5432/planka
      - SECRET_KEY=<YOUR_SECRET>
      - BASE_URL=https://tasks.yourdomain.com
    restart: unless-stopped

Verdict: If you use Trello just for kanban boards (and most people do), Planka is a drop-in replacement. Lightweight and clean.

6. Umami — Replace Google Analytics

What it does: Privacy-focused web analytics. Page views, referrers, devices, countries — all the metrics that matter, without tracking cookies or personal data.

Why self-host it: Google Analytics collects far more data than you need and raises GDPR concerns. Umami is GDPR-compliant by default because it doesn't use cookies or collect personal data. No cookie banners required.

services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      - DATABASE_URL=postgresql://umami:pass@db:5432/umami
      - APP_SECRET=<YOUR_SECRET>
    restart: unless-stopped

Verdict: I switched to Umami for ByteGuard. The dashboard is beautiful, the tracking script is 2KB, and it tells me everything I need to know without the guilt of tracking my readers.

7. Listmonk — Replace Mailchimp

What it does: Self-hosted newsletter and mailing list manager. Subscriber management, email templates, campaigns, analytics, and bounce handling.

Why self-host it: Mailchimp's free tier keeps shrinking. Listmonk handles thousands of subscribers with a single binary and PostgreSQL database. Pair it with Amazon SES or a transactional email service for sending.

services:
  listmonk:
    image: listmonk/listmonk:latest
    ports:
      - "127.0.0.1:9000:9000"
    environment:
      - LISTMONK_app__address=0.0.0.0:9000
      - LISTMONK_db__host=db
      - LISTMONK_db__port=5432
      - LISTMONK_db__user=listmonk
      - LISTMONK_db__password=<YOUR_PASSWORD>
      - LISTMONK_db__database=listmonk
    restart: unless-stopped

Verdict: Best self-hosted newsletter tool by far. The UI is clean, the templating engine is powerful, and the performance is outstanding.

8. Gitea — Replace GitHub

What it does: Lightweight Git hosting with pull requests, issues, CI/CD (Gitea Actions), container registry, and package management.

Why self-host it: GitHub is great, but your code is on Microsoft's servers. For private projects, internal tools, or just principle — self-hosted Git gives you full control.

services:
  gitea:
    image: gitea/gitea:latest
    volumes:
      - gitea_data:/data
    ports:
      - "127.0.0.1:3001:3000"
      - "2222:22"
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: unless-stopped

Verdict: Gitea is what I'd recommend over GitLab for most self-hosters. GitLab needs 4GB+ RAM. Gitea runs on 100MB. For small teams and personal projects, it's perfect.

9. Uptime Kuma — Replace Pingdom / UptimeRobot

What it does: Monitors your services and alerts you when they go down. HTTP, TCP, DNS, ping, Docker container, and more. Beautiful dashboard and public status pages.

Why self-host it: UptimeRobot's free tier limits you to 50 monitors with 5-minute intervals. Uptime Kuma has no limits and checks as frequently as every 20 seconds.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    volumes:
      - kuma_data:/app/data
    ports:
      - "127.0.0.1:3002:3001"
    restart: unless-stopped

I run Uptime Kuma at status.byte-guard.net — I'll have a full setup guide covering notifications, status pages, and advanced monitors.

Verdict: One of the best self-hosted tools, period. Setup takes 2 minutes, the UI is gorgeous, and notifications work reliably.

10. Jellyfin — Replace Plex

What it does: Media server for movies, TV shows, music, and photos. Streams to your devices with transcoding support.

Why self-host it: Plex increasingly pushes a paid "Plex Pass" and ad-supported content. Jellyfin is fully free, open-source, and doesn't phone home.

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    volumes:
      - jellyfin_config:/config
      - jellyfin_cache:/cache
      - /path/to/media:/media:ro
    ports:
      - "127.0.0.1:8096:8096"
    restart: unless-stopped

Heads up: Transcoding is CPU-intensive. If you plan to stream outside your network, consider a VPS with decent CPU or pass through a GPU. For local network streaming, any hardware works.

Verdict: If you have a media collection, Jellyfin is the way to go. The clients are available on every platform, and the community is active.

Where to Host All This

You'll need a VPS with at least 4GB RAM to run several of these simultaneously. I use Hetzner — the CPX22 gives you 4 vCPU, 8GB RAM, and 80GB SSD for about €5/month. Check my VPS comparison if you're shopping around.

A reverse proxy handles SSL and routing for all your services. I use Nginx Proxy Manager — one proxy host per service, all on the same server.

Follow Docker security best practices when running this many containers. Isolate networks, run as non-root where possible, and keep images updated.

Troubleshooting

Problem: Container can't connect to the database.
Cause: The database container isn't on the same Docker network, or the credentials don't match.
Fix: Put all services in the same Docker Compose file or use an external Docker network. Double-check usernames and passwords match between app and database configs.

Problem: Service works locally but not through the reverse proxy.
Cause: Proxy forwarding to wrong port or hostname.
Fix: Use the container name as the hostname and the container's internal port (not the mapped host port).

Problem: Running out of RAM with multiple services.
Cause: Too many services for your VPS tier.
Fix: Check usage with docker stats. Prioritize — not everything needs to run 24/7. Consider upgrading your VPS or splitting services across two servers.

Conclusion

Self-hosting isn't all-or-nothing. Start with one or two tools that replace paid subscriptions, and expand from there. Vaultwarden and Uptime Kuma are my "install on every server" picks. Nextcloud and Gitea come next if you want file storage and Git.

The total cost of running all 10 is one VPS bill — less than a single Notion team subscription.

What did I miss? If there's a self-hosted tool you swear by, I'd love to hear about it.

How to Self-Host Vaultwarden with Docker

byteguard — Sun, 26 Apr 2026 15:39:12 +0000

How to Self-Host Vaultwarden with Docker

Everyone needs a password manager. If you're still reusing passwords or storing them in a browser's built-in manager, you're one data breach away from a very bad week. Bitwarden is the best open-source option, but the official server is heavy — it needs MSSQL and multiple containers.

Vaultwarden solves this. It's a lightweight, community-built server that's fully compatible with all Bitwarden clients — browser extensions, mobile apps, desktop apps, CLI. It runs in a single Docker container, uses SQLite by default, and needs about 30MB of RAM. I self-host Vaultwarden with Docker on the same VPS that runs this blog, and it handles my entire password vault without breaking a sweat.

By the end of this guide, you'll have a working Vaultwarden instance with SSL, auto-backups, and all the security settings configured properly.

Prerequisites

A Linux VPS with Docker and Docker Compose (here's how I set mine up)
A domain name pointed at your server (e.g., vault.yourdomain.com)
A reverse proxy with SSL — Nginx Proxy Manager or similar
SSH access to your server (hardened, ideally)

Deploy Vaultwarden with Docker Compose

Create a directory for Vaultwarden:

sudo mkdir -p /opt/vaultwarden
cd /opt/vaultwarden

Generate an admin token. This secures the admin panel:

openssl rand -base64 48

Save that token — you'll need it in the compose file.

Create the compose file:

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    environment:
      - DOMAIN=https://vault.yourdomain.com
      - ADMIN_TOKEN=<YOUR_GENERATED_TOKEN>
      - SIGNUPS_ALLOWED=false
      - INVITATIONS_ALLOWED=true
      - SHOW_PASSWORD_HINT=false
      - ROCKET_LIMITS={json=10485760}
      - LOG_FILE=/data/vaultwarden.log
      - LOG_LEVEL=warn
    volumes:
      - vw_data:/data
    ports:
      - "127.0.0.1:8080:80"
    restart: unless-stopped

volumes:
  vw_data:

Key environment variables explained:

DOMAIN — Must match your actual domain with https://. Required for WebSocket notifications and email links.
ADMIN_TOKEN — Protects the /admin panel. Without this, anyone can access admin settings.
SIGNUPS_ALLOWED=false — Disables public registration. You'll create your account first, then lock it down.
SHOW_PASSWORD_HINT=false — Password hints are a security risk. Disable them.
ROCKET_LIMITS — Increases the upload limit to 10MB for file attachments.

Note: The container binds to 127.0.0.1:8080, not 0.0.0.0. This means it's only accessible from localhost — your reverse proxy handles external traffic and SSL.

Start the container:

docker compose up -d

Set Up the Reverse Proxy

You need SSL for Vaultwarden — the Bitwarden clients refuse to connect over plain HTTP, and you should never send passwords unencrypted.

Using Nginx Proxy Manager

Log into your NPM dashboard
Add a new Proxy Host:
- Domain: vault.yourdomain.com
- Forward Hostname: vaultwarden (or 127.0.0.1 if not on the same Docker network)
- Forward Port: 80
- Enable SSL: Yes, request a new Let's Encrypt certificate
- Force SSL: Yes
- WebSocket Support: Yes (required for live sync)

Using Caddy

Add to your Caddyfile:

vault.yourdomain.com {
    reverse_proxy vaultwarden:80
}

Caddy handles SSL automatically.

Create Your Account

With signups still technically allowed (we'll disable them after), open https://vault.yourdomain.com in your browser. Click "Create Account" and set up your master password.

Choose your master password carefully. This is the one password you need to memorize. Make it long (4+ random words), unique, and never used anywhere else. Vaultwarden encrypts your vault with this password on the client side — even if someone compromises the server, they can't read your passwords without the master password.

After creating your account, immediately disable signups. Edit the compose file and verify SIGNUPS_ALLOWED=false, then restart:

docker compose down && docker compose up -d

If you need to add family members or team members later, use the admin panel to send invitations.

Configure the Admin Panel

Access the admin panel at https://vault.yourdomain.com/admin and enter your admin token.

Here you can:

Manage users — delete accounts, disable accounts, verify email addresses
Configure SMTP — for email verification and password reset (optional but recommended)
Adjust security settings — 2FA enforcement, password length requirements
View diagnostics — server version, database size, environment status

Optional: SMTP for Email

If you want email verification and password reset capability, configure SMTP in the admin panel or via environment variables:

environment:
  - SMTP_HOST=smtp.example.com
  - SMTP_FROM=vault@yourdomain.com
  - SMTP_PORT=587
  - SMTP_SECURITY=starttls
  - SMTP_USERNAME=<YOUR_SMTP_USER>
  - SMTP_PASSWORD=<YOUR_SMTP_PASSWORD>

Set Up Automatic Backups

Your password vault is critical data. Losing it would be catastrophic. Set up automated backups with a simple cron job.

Create the backup script:

sudo tee /opt/vaultwarden/backup.sh << 'SCRIPT'
#!/bin/bash
BACKUP_DIR="/opt/vaultwarden/backups"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
mkdir -p "$BACKUP_DIR"

# Copy the SQLite database (safely, with WAL checkpoint)
docker exec vaultwarden sqlite3 /data/db.sqlite3 ".backup '/data/backup_${TIMESTAMP}.sqlite3'"
docker cp vaultwarden:/data/backup_${TIMESTAMP}.sqlite3 "${BACKUP_DIR}/db_${TIMESTAMP}.sqlite3"
docker exec vaultwarden rm "/data/backup_${TIMESTAMP}.sqlite3"

# Copy attachments and other data
docker cp vaultwarden:/data/attachments "${BACKUP_DIR}/attachments_${TIMESTAMP}" 2>/dev/null

# Compress
tar -czf "${BACKUP_DIR}/vaultwarden_${TIMESTAMP}.tar.gz" \
    -C "$BACKUP_DIR" "db_${TIMESTAMP}.sqlite3" "attachments_${TIMESTAMP}" 2>/dev/null

# Cleanup loose files
rm -f "${BACKUP_DIR}/db_${TIMESTAMP}.sqlite3"
rm -rf "${BACKUP_DIR}/attachments_${TIMESTAMP}"

# Keep only last 7 backups
ls -t "${BACKUP_DIR}"/vaultwarden_*.tar.gz | tail -n +8 | xargs rm -f 2>/dev/null

echo "Backup completed: vaultwarden_${TIMESTAMP}.tar.gz"
SCRIPT
chmod +x /opt/vaultwarden/backup.sh

Schedule it to run daily:

sudo crontab -e

Add:

0 3 * * * /opt/vaultwarden/backup.sh >> /var/log/vaultwarden-backup.log 2>&1

Note: Use SQLite's .backup command, not a raw file copy. Copying a SQLite database while it's being written to can produce a corrupted backup. The .backup command handles this safely.

Connect Your Devices

Browser Extension

Install the Bitwarden browser extension (Chrome, Firefox, Safari, Edge). Before logging in:

Click the gear icon in the extension
Under "Self-hosted environment," enter https://vault.yourdomain.com
Save and log in with your credentials

Mobile App

Install the Bitwarden app (iOS/Android). Tap the gear icon on the login screen, enter your self-hosted URL, save, and log in.

Desktop App

Download from bitwarden.com/download. Same process — set the server URL before logging in.

CLI

npm install -g @bitwarden/cli
bw config server https://vault.yourdomain.com
bw login

The CLI is useful for scripting — you can generate passwords, export vaults, and manage entries programmatically.

Enable Two-Factor Authentication

After logging in to your web vault, go to Settings → Security → Two-step Login. Enable at least one method:

Authenticator app (TOTP) — works with any authenticator app. This should be your minimum.
YubiKey — hardware key support. Best security if you have one.
Email — sends a code to your email. Better than nothing, but TOTP is preferred.

Warning: If you lose your 2FA device and your recovery code, you're locked out of your vault permanently. Vaultwarden encrypts everything client-side — there's no "forgot my 2FA" reset. Save your recovery code in a physically secure location.

Security Considerations

Self-hosting a password manager means the security is entirely your responsibility.

Keep Vaultwarden updated. Check for new releases monthly: docker compose pull && docker compose up -d. Security patches in a password manager are critical.
Restrict admin panel access. Consider disabling the admin panel entirely after initial setup by removing the ADMIN_TOKEN variable. Or restrict it by IP using your reverse proxy.
Don't expose port 8080. The compose file binds to 127.0.0.1 specifically so the container isn't directly accessible. All traffic should go through your SSL-terminating reverse proxy.
Server-side encryption isn't the whole picture. Vaultwarden stores your vault encrypted with your master password. The server never sees the plaintext. But if someone gets root on your server, they could modify the Vaultwarden binary to capture passwords as you type them. Keep your server hardened and Docker locked down.
Offline access. Bitwarden clients cache an encrypted copy of your vault locally. If your server goes down, you can still access passwords. But new entries won't sync until the server is back.

Troubleshooting

Problem: Bitwarden client says "Unable to connect to server."
Cause: Wrong server URL, SSL issue, or Vaultwarden isn't running.
Fix: Verify the URL includes https:// and matches exactly. Check docker compose logs vaultwarden for errors. Test with curl -I https://vault.yourdomain.com.

Problem: "Not a valid Bitwarden server" error.
Cause: The DOMAIN environment variable doesn't match the URL you're accessing.
Fix: Ensure DOMAIN in docker-compose.yml matches the URL in your client settings, including the protocol (https://).

Problem: WebSocket notifications not working (items don't sync instantly).
Cause: Your reverse proxy isn't forwarding WebSocket connections.
Fix: In NPM, enable "WebSocket Support" for the proxy host. In Caddy, it works automatically. In Nginx manually, add proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade";.

Problem: Attachments fail to upload.
Cause: Default request body size limit in your reverse proxy.
Fix: Increase the limit. In NPM, add client_max_body_size 25M; to custom Nginx configuration. In Caddy, it's unlimited by default.

Problem: Admin panel returns 404.
Cause: ADMIN_TOKEN is not set or was removed.
Fix: Add ADMIN_TOKEN to your environment variables and restart the container.

Conclusion

You now have a self-hosted, Bitwarden-compatible password manager running on your own server. No subscription fees, no data on someone else's infrastructure, and full control over your security.

The total resource usage is minimal — about 30MB of RAM and negligible CPU. It runs comfortably alongside other services on even a small VPS.

From here, I'd recommend:

Setting up Uptime Kuma to monitor your Vaultwarden instance (it's critical infrastructure now)
Reviewing my Docker security practices to lock down the container
Adding Fail2Ban to protect against brute-force login attempts

If you need a VPS for this, I run my entire stack on Hetzner — check my VPS comparison for options.

Setting Up WireGuard VPN on Your Own Server

byteguard — Sun, 26 Apr 2026 15:39:11 +0000

Setting Up WireGuard VPN on Your Own Server

Most commercial VPN providers promise "no logs" and "military-grade encryption" while routing your traffic through servers you don't control. You're trusting a marketing claim with your entire internet activity. There's a better option: run your own VPN.

A WireGuard VPS setup gives you full control over your traffic, your logs, and your encryption keys. WireGuard is faster than OpenVPN, easier to configure than IPSec, and the entire codebase is around 4,000 lines — small enough to audit. I run WireGuard on the same Hetzner VPS that hosts this blog, and the setup took me about 15 minutes.

By the end of this post, you'll have a working WireGuard VPN server with client configs for your phone and laptop.

Prerequisites

A Linux VPS with a public IP (I use Hetzner — here's how I set mine up)
SSH access to your server (hardened, ideally)
Docker and Docker Compose installed
A device to connect from (Linux, macOS, Windows, iOS, or Android)

Why WireGuard Over OpenVPN?

I ran OpenVPN for years before switching. Here's why WireGuard wins for self-hosters:

Feature	WireGuard	OpenVPN
Codebase	~4,000 lines	~100,000 lines
Protocol	UDP only	TCP or UDP
Speed	Near wire speed	20-30% overhead
Connection time	~100ms	5-10 seconds
Config complexity	Simple key pairs	Certificates + PKI
Kernel integration	Built into Linux 5.6+	Userspace

WireGuard is in the Linux kernel since 5.6. It's not a third-party module — it's part of the operating system. That matters for performance and long-term support.

Install WireGuard with Docker Compose

You could install WireGuard directly on the host, but I prefer Docker for consistency with the rest of my stack. The linuxserver/wireguard image handles key generation and config templating automatically.

Create a directory for your WireGuard config:

sudo mkdir -p /opt/wireguard
cd /opt/wireguard

Create the compose file:

# docker-compose.yml
services:
  wireguard:
    image: lscr.io/linuxserver/wireguard:latest
    container_name: wireguard
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Helsinki
      - SERVERURL=<YOUR_SERVER_IP>
      - SERVERPORT=51820
      - PEERS=laptop,phone,tablet
      - PEERDNS=1.1.1.1
      - INTERNAL_SUBNET=10.13.13.0
      - ALLOWEDIPS=0.0.0.0/0
    volumes:
      - ./config:/config
      - /lib/modules:/lib/modules
    ports:
      - 51820:51820/udp
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

Replace <YOUR_SERVER_IP> with your VPS's public IP address. The PEERS variable creates client configs automatically — one for each name you list.

Start the container:

docker compose up -d

WireGuard generates all the keys and configs on first boot. Check the logs to confirm:

docker compose logs wireguard

You should see lines like [#] ip link add wg0 type wireguard and config generation for each peer.

Configure Your Firewall for WireGuard

If you followed my VPS hardening guide, you have UFW running. You need to allow WireGuard's UDP port:

sudo ufw allow 51820/udp comment "WireGuard VPN"

You also need IP forwarding enabled. Check if it's already on:

sysctl net.ipv4.ip_forward

If the output is 0, enable it permanently:

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.d/99-wireguard.conf
sudo sysctl -p /etc/sysctl.d/99-wireguard.conf

Note: The Docker container sets src_valid_mark via sysctls, but IP forwarding must be enabled on the host. Without it, traffic enters the VPN tunnel but never leaves.

Grab Your Client Configs

The container auto-generated configs for each peer you listed. Find them in the config directory:

ls /opt/wireguard/config/peer_laptop/
ls /opt/wireguard/config/peer_phone/

Each peer folder contains:

peer_laptop.conf — the full WireGuard config file
peer_laptop.png — a QR code for mobile setup

View the laptop config:

cat /opt/wireguard/config/peer_laptop/peer_laptop.conf

Expected output:

[Interface]
Address = 10.13.13.2/32
PrivateKey = <auto-generated-private-key>
ListenPort = 51820
DNS = 1.1.1.1

[Peer]
PublicKey = <server-public-key>
PresharedKey = <auto-generated-psk>
Endpoint = <YOUR_SERVER_IP>:51820
AllowedIPs = 0.0.0.0/0

Connect Your Devices

Linux

Install the WireGuard client:

sudo apt install wireguard

Copy the config file to your client machine:

scp user@<YOUR_SERVER_IP>:/opt/wireguard/config/peer_laptop/peer_laptop.conf /etc/wireguard/wg0.conf

Start the tunnel:

sudo wg-quick up wg0

Verify you're connected:

curl ifconfig.me

This should return your VPS IP, not your home IP. To disconnect:

sudo wg-quick down wg0

To start WireGuard automatically on boot:

sudo systemctl enable wg-quick@wg0

macOS and Windows

Download the official WireGuard app from wireguard.com/install. Import the .conf file and click "Activate." That's it.

iOS and Android

Install the WireGuard app from the App Store or Play Store. Then scan the QR code directly from your terminal:

docker exec wireguard /app/show-peer phone

This displays the QR code in your terminal. Scan it with the mobile app and toggle the connection on.

Adding More Peers Later

Need to add a new device? Update the PEERS environment variable:

environment:
  - PEERS=laptop,phone,tablet,work-laptop

Then restart the container:

docker compose down && docker compose up -d

WireGuard generates the new peer config without touching existing ones. Your current devices stay connected.

Split Tunnel vs Full Tunnel

The config above routes all traffic through the VPN (AllowedIPs = 0.0.0.0/0). This is a full tunnel — everything goes through your server.

For a split tunnel (only route specific traffic), edit the client config:

[Peer]
AllowedIPs = 10.13.13.0/24, 192.168.1.0/24

This only routes traffic to your VPN subnet and home network through the tunnel. Everything else uses your local internet connection. Split tunneling is better for performance when you only need access to services on your server.

Security Considerations

WireGuard is secure by design, but your setup can still have weak points:

Key management. The private keys in /opt/wireguard/config/ are the keys to your VPN. If someone gets them, they're on your network. Protect this directory: chmod 700 /opt/wireguard/config/.
DNS leaks. The config sets DNS to 1.1.1.1 (Cloudflare). If you want full privacy, run your own DNS resolver (Pi-hole or Unbound) and point PEERDNS at your server's WireGuard IP instead.
Exposed UDP port. Port 51820 is visible to scanners. WireGuard is silent by design — it doesn't respond to unauthenticated packets — but you can change the port to something less obvious if you prefer.
Container capabilities. The NET_ADMIN and SYS_MODULE capabilities are required for WireGuard to create network interfaces. This is more permissive than a typical container — review the Docker security best practices to lock down the rest of your stack.

Troubleshooting

Problem: Client connects but can't reach the internet.
Cause: IP forwarding is disabled on the host.
Fix: Run sysctl net.ipv4.ip_forward=1 and make it permanent in /etc/sysctl.d/.

Problem: Connection times out.
Cause: UDP port 51820 is blocked by your firewall or hosting provider.
Fix: Check sudo ufw status and your Hetzner firewall rules in the cloud console. Both must allow 51820/udp.

Problem: QR code doesn't display in terminal.
Cause: Terminal doesn't support the character encoding.
Fix: Use a modern terminal emulator, or copy the .conf file manually instead.

Problem: Handshake completes but no data flows.
Cause: NAT or routing issue on the server. The src_valid_mark sysctl isn't set.
Fix: Verify with sysctl net.ipv4.conf.all.src_valid_mark — should return 1. The Docker compose file sets this, but check it's applied.

Problem: Existing peers break after adding new ones.
Cause: You recreated the container without preserving the config volume.
Fix: The configs are stored in ./config which is bind-mounted. As long as you don't delete that directory, existing peers survive restarts. If you lost them, clients need new configs.

Conclusion

You now have a self-hosted WireGuard VPN that you fully control. No subscription fees, no trust-me-bro logging policies, and connection speeds that barely dip below your raw bandwidth.

From here, consider:

Adding Pi-hole behind WireGuard for ad-blocking on all your devices
Using a split tunnel for accessing your self-hosted services remotely
Setting up Fail2Ban to monitor your server logs
Reviewing your overall VPS hardening if you haven't already

If you need a VPS to run this on, I use Hetzner for all my projects — solid performance, fair pricing, and Helsinki data center latency is great for Europe.

Nginx Proxy Manager vs Traefik vs Caddy: Which Reverse Proxy Should You Pick in 2026?

byteguard — Thu, 23 Apr 2026 20:17:44 +0000

Every self-hosted stack needs a reverse proxy. It's the front door — it terminates SSL, routes traffic to the right container, and keeps your services from fighting over port 443. But which one should you pick?

I've used all three. Nginx Proxy Manager runs this blog. I've deployed Traefik on client projects. And Caddy has quietly become my favorite for small stacks. This comparison covers the differences that actually matter: setup time, Docker integration, SSL handling, and the learning curve.

If you're choosing a reverse proxy for your self-hosting setup, this post will help you make the right call.

Quick Comparison

Feature	Nginx Proxy Manager	Traefik	Caddy
Config style	Web UI	Labels / YAML	Caddyfile / JSON
Auto SSL	Yes (Let's Encrypt)	Yes (Let's Encrypt)	Yes (Let's Encrypt + ZeroSSL)
Docker integration	Manual (UI)	Native (labels)	API / Caddyfile
Web dashboard	Full GUI	Read-only dashboard	None (API only)
Learning curve	Low	High	Medium
Performance	Excellent (Nginx core)	Good	Good
Wildcard certs	Yes (DNS challenge)	Yes (DNS challenge)	Yes (DNS challenge)
Active community	Large	Very large	Growing
Config as code	No (DB-backed)	Yes	Yes
Resource usage	~50MB RAM	~80MB RAM	~30MB RAM

Nginx Proxy Manager — The Visual Approach

Nginx Proxy Manager (NPM) wraps Nginx in a web interface. You click through forms to add proxy hosts, and it generates the Nginx config behind the scenes. I chose it for the ByteGuard stack because I wanted to get Ghost, Uptime Kuma, and the blog itself online in an afternoon.

Setup with Docker Compose

services:
  npm:
    image: jc21/nginx-proxy-manager:latest
    container_name: npm
    ports:
      - "80:80"
      - "443:443"
      - "81:81"  # Admin UI
    volumes:
      - npm_data:/data
      - npm_letsencrypt:/etc/letsencrypt
    restart: unless-stopped

volumes:
  npm_data:
  npm_letsencrypt:

Start it with docker compose up -d, open http://<YOUR_IP>:81, and log in with the default credentials (admin@example.com / changeme). From there, adding a proxy host is four fields: domain, forward hostname (container name), forward port, and a toggle for SSL.

Pros

Fastest time to first proxy. If you've never touched Nginx config files, NPM gets you from zero to SSL-terminated proxy in under five minutes.
Visual certificate management. You can see every certificate, its expiry date, and renewal status in one screen.
Access lists and custom Nginx config. The UI supports basic auth, IP restrictions, and raw Nginx directives for advanced users.

Cons

Not config-as-code. The config lives in a SQLite database. You can't version-control your proxy rules or reproduce the setup from a file. If the database corrupts, you're rebuilding from scratch.
Port 81 exposure. The admin UI runs on a separate port. You need to either firewall it or put it behind itself (which is awkward).
Docker-unaware. NPM doesn't know about your Docker containers. When you add a new service, you manually create a proxy host. It won't auto-discover anything.

Who Should Use NPM

You want a working reverse proxy today and don't care about infrastructure-as-code. You're running a small stack (under 10 services) and prefer clicking over editing YAML. This is where most self-hosters start, and honestly, many never need to leave.

Traefik — The Docker-Native Option

Traefik was built for containerized environments. Instead of editing config files or clicking through a UI, you define routing rules as Docker labels on your containers. Traefik watches the Docker socket, detects new containers, and configures itself automatically.

Setup with Docker Compose

services:
  traefik:
    image: traefik:v3.0
    container_name: traefik
    command:
      - "--api.dashboard=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.letsencrypt.acme.email=you@example.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - traefik_letsencrypt:/letsencrypt
    restart: unless-stopped

volumes:
  traefik_letsencrypt:

Now, instead of configuring the proxy separately, you add labels to your application containers:

services:
  ghost:
    image: ghost:5
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.ghost.rule=Host(`blog.example.com`)"
      - "traefik.http.routers.ghost.entrypoints=websecure"
      - "traefik.http.routers.ghost.tls.certresolver=letsencrypt"
      - "traefik.http.services.ghost.loadbalancer.server.port=2368"

Deploy the container, and Traefik picks it up automatically. No manual proxy host creation. No UI interaction. Remove the container, and the route disappears.

Pros

True auto-discovery. Add a container with the right labels, and it's proxied. No extra step.
Config as code. Everything is in your Docker Compose files. Version-control the whole stack, docker compose up -d on a new server, and you have an identical setup.
Middleware ecosystem. Rate limiting, basic auth, header manipulation, circuit breakers — all configured as labels. No custom Nginx snippets.
Scales well. Traefik handles Docker Swarm, Kubernetes, and multi-provider setups out of the box.

Cons

Steep learning curve. The concepts (entrypoints, routers, middlewares, services, providers) take time to internalize. The documentation is comprehensive but dense.
Docker socket exposure. Traefik needs read access to the Docker socket (/var/run/docker.sock). This is a security risk — a compromised Traefik container could inspect and manipulate all your containers. Mitigate this with a Docker socket proxy or follow the guidelines in my Docker security post.
Verbose labels. A single service might need 5-8 labels. Multiply that by 10 services and your compose file gets noisy.

Who Should Use Traefik

You're running 10+ services, you add and remove containers frequently, and you want everything defined in code. You're comfortable reading documentation and debugging label syntax. Traefik pays back the learning investment when your stack grows.

Caddy — The Quiet Winner

Caddy is a web server written in Go that does automatic HTTPS by default. No config required for SSL — it requests and renews certificates for every domain you define. The config format (Caddyfile) is the simplest of the three.

Setup with Docker Compose

services:
  caddy:
    image: caddy:2
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

Create a Caddyfile:

blog.example.com {
    reverse_proxy ghost:2368
}

status.example.com {
    reverse_proxy uptime-kuma:3001
}

That's the entire reverse proxy config. Two lines per service. SSL happens automatically — Caddy requests certificates from Let's Encrypt (or ZeroSSL) on first request, stores them in /data, and renews them before expiry. No certresolver config. No toggle. It's the default behavior.

Pros

Automatic HTTPS with zero config. This is Caddy's killer feature. Every site gets SSL by default. No ACME setup, no certificate resolver blocks, no toggles.
Minimal config. A Caddyfile for 10 services is maybe 30 lines. Compare that to 80+ lines of Traefik labels or 10 manual proxy hosts in NPM.
Low resource usage. Caddy consistently uses less RAM than Traefik and comparable CPU to NPM.
Config as code. The Caddyfile is a plain text file. Version control it, template it, ship it.
Hot reload. caddy reload applies config changes without dropping connections. No container restart needed.

Cons

No web UI. If you want a dashboard, you're looking at the Caddyfile in a text editor. There's an admin API, but no official GUI.
Smaller community. Fewer Stack Overflow answers and fewer blog posts compared to Nginx or Traefik. When you hit an edge case, you might be reading source code.
Docker integration isn't native. Unlike Traefik, Caddy doesn't watch Docker labels out of the box. You edit the Caddyfile and reload. There are third-party plugins for Docker integration, but they're not first-party.

Who Should Use Caddy

You want the simplest possible config, you're comfortable editing text files, and you don't need a GUI. Caddy is perfect for stacks under 20 services where you don't add/remove containers hourly. It's also excellent as a dev proxy on your local machine.

My Pick: It Depends (Honestly)

I hate cop-out answers, so here's my actual decision tree:

First self-hosted project, want it running today? → Nginx Proxy Manager. The GUI removes all friction. I used it for this very blog and it's been rock-solid.
Growing stack, everything in Docker Compose, want auto-discovery? → Traefik. The learning curve is real, but the payoff at scale is worth it.
Want the simplest config with automatic SSL and don't need a GUI? → Caddy. If I were starting ByteGuard from scratch today, I'd probably pick Caddy.

The good news: switching later isn't hard. Your application containers don't change — only the proxy layer does. Pick the one that matches your comfort level now.

Security Considerations

Whichever proxy you choose, keep these in mind:

TLS versions. Disable TLS 1.0 and 1.1. All three support TLS 1.2+ by default, but verify your config. Caddy enforces TLS 1.2+ out of the box.
HTTP to HTTPS redirect. All three support automatic redirects. Make sure it's enabled — you don't want any service accessible over plain HTTP.
Docker socket access. Only Traefik needs it. If you use Traefik, mount the socket read-only (:ro) and consider a socket proxy. NPM and Caddy don't need socket access at all.
Admin interfaces. NPM exposes port 81, Traefik has an optional dashboard. Restrict access with firewall rules or put them behind authentication. Caddy's admin API listens on localhost only by default.
Rate limiting. Traefik has built-in rate limiting middleware. For NPM, you'd add custom Nginx directives. For Caddy, use the rate_limit plugin. All three can do it, but Traefik makes it easiest.

Troubleshooting

Problem: SSL certificate not issuing.
Cause: Port 80 is blocked, DNS doesn't point to your server, or you've hit Let's Encrypt rate limits.
Fix: Verify dig +short yourdomain.com returns your server IP and port 80 is open (sudo ufw allow 80/tcp). Check rate limits at letsencrypt.org/docs/rate-limits.

Problem: 502 Bad Gateway.
Cause: The proxy can't reach the backend container. Wrong hostname or port.
Fix: Ensure the proxy and backend are on the same Docker network. Use container names as hostnames (e.g., ghost, not localhost).

Problem: Traefik labels are ignored.
Cause: exposedbydefault=false is set but you forgot traefik.enable=true.
Fix: Add the traefik.enable=true label to every container you want proxied.

Problem: Caddy shows "default" page instead of your site.
Cause: The domain in your Caddyfile doesn't match the request's Host header.
Fix: Verify the domain is spelled correctly and DNS resolves to your server.

Conclusion

All three are solid choices. NPM gets you started fast with a GUI. Traefik scales best for dynamic container environments. Caddy gives you the cleanest config with automatic SSL.

I wrote a full walkthrough of the NPM setup when I built ByteGuard from scratch, and the Docker security post covers how to lock down whichever proxy you choose. If you're still deciding on a platform, my Ghost vs WordPress comparison might help too.

Ghost vs WordPress in 2026: Which Is Better for Technical Blogs?

byteguard — Mon, 20 Apr 2026 10:39:03 +0000

Every technical blogger eventually faces this decision: Ghost or WordPress? WordPress powers 43% of the internet and has a plugin for everything. Ghost is the lean, fast alternative that was literally built for publishing. Both can be self-hosted. Both are open source. Both will run a perfectly good technical blog.

I chose Ghost for byte-guard.net, and I've been running it in production for two weeks on a self-hosted Hetzner VPS. Before that, I spent time with WordPress on various projects. This isn't a theoretical comparison — it's what I've actually experienced using both platforms for technical content with code blocks, tutorials, and long-form writing.

Here's the honest breakdown to help you decide which one fits your workflow.

Prerequisites

This comparison assumes you're a technical user who:

Wants to write tutorials, how-to guides, or technical articles
Is comfortable self-hosting (or at least considering it)
Cares about performance, SEO, and writing experience
Doesn't need e-commerce, forums, or complex multi-author workflows

If you need a full-featured CMS with WooCommerce, LMS plugins, and 50 contributors — WordPress wins by default. That's not the comparison I'm making here.

Quick Comparison

Feature	Ghost	WordPress
Built for	Publishing & newsletters	Everything (CMS, e-commerce, forums...)
Core language	Node.js	PHP
Database	SQLite or MySQL	MySQL/MariaDB
Editor	Native block editor (Koenig)	Gutenberg block editor
Code blocks	Built-in with syntax highlighting	Requires plugin (SyntaxHighlighter, Prisma)
Themes	~100 official/community	10,000+
Plugins/Extensions	None (by design)	60,000+
Built-in newsletters	Yes (native)	No (requires Mailchimp, etc.)
Membership/subscriptions	Native, with Stripe integration	Requires plugins
REST API	Content + Admin API	REST + GraphQL (via plugin)
Self-hosting difficulty	Docker Compose, one file	LAMP/LEMP stack or Docker
Managed hosting cost	$9-199/month (Ghost Pro)	$3-50/month (shared hosting)
Self-hosted cost	Free + VPS (~$5-9/month)	Free + VPS (~$5-9/month)
RAM usage (idle)	~350 MB	~80-150 MB (depends on plugins)
Page speed (default theme)	95-100 Lighthouse	60-85 Lighthouse (varies wildly)

Writing Experience

Ghost

Ghost's editor (Koenig) is clean, fast, and distraction-free. It feels like writing in a modern document editor — you type, the text appears, and there's nothing between you and the content. No sidebars, no widget panels, no "would you like to install Yoast?" prompts.

For technical writing specifically, Ghost handles code blocks natively. You type `, pick a language, and get syntax-highlighted code that renders correctly on publish. No plugin needed. No configuration. It works out of the box.

Markdown support is first-class. You can write in Ghost's visual editor or paste raw markdown — it converts seamlessly. For a technical writer who thinks in markdown (and if you're writing tutorials, you probably do), this is a genuine workflow advantage.

What Ghost's editor doesn't do: custom layouts, multi-column content, or complex media embeds beyond the basics (images, video, audio, galleries, bookmarks, and code). If you need a full page builder, Ghost isn't it.

WordPress

Gutenberg (WordPress's block editor) is more powerful but also more complex. You can build elaborate page layouts, embed custom HTML, use reusable block patterns, and install editor plugins that add new block types.

For code blocks, you need a plugin. The default code block exists but doesn't do syntax highlighting. Most technical bloggers install something like SyntaxHighlighter Evolved, Prisma, or Code Block Pro. Each comes with its own settings page, its own CSS, and its own maintenance burden. They work fine — but it's configuration you don't have to do on Ghost.

The WordPress editor has improved dramatically since the early Gutenberg days, but it still carries the weight of being a general-purpose CMS editor. Writing a technical tutorial in WordPress feels like using a Swiss Army knife to tighten a screw — it works, but you're carrying tools you don't need.

Performance

This is where the gap is most obvious.

Ghost with the default Casper theme scores 95-100 on Google Lighthouse for performance. The pages are small, the JavaScript is minimal, and the server-side rendering is fast. My byte-guard.net homepage loads in under 1 second with a cold cache.

WordPress with a default theme (Twenty Twenty-Five) scores reasonably well — mid-80s to low-90s. But the moment you install plugins, add analytics scripts, enable comment systems, and load a third-party theme, that score drops fast. A typical WordPress blog with 10-15 plugins and a premium theme scores 60-75 on Lighthouse.

The difference isn't WordPress itself — it's the ecosystem. WordPress's strength (plugins for everything) is also its performance weakness. Every plugin adds database queries, CSS files, and JavaScript. Ghost avoids this entirely by not having plugins.

Real numbers from my stack:

Ghost on a Hetzner CPX22 (3 vCPUs, 8 GB RAM):

Idle memory: ~350 MB (Ghost + Node.js)
Time to first byte: ~80ms
Full page load: ~0.8s

A comparable WordPress install (PHP-FPM + MySQL + a popular theme):

Idle memory: ~80-150 MB (PHP itself is lighter, but MySQL adds overhead)
Time to first byte: ~200-400ms (depends heavily on caching plugin)
Full page load: ~1.5-3s (without caching plugin, much worse)

Ghost is faster out of the box. WordPress can match Ghost's speed, but you need a caching plugin (WP Super Cache, W3 Total Cache, or LiteSpeed Cache), an image optimizer, and careful plugin management. It's achievable — it's just not the default.

SEO

Both platforms can rank well. The question is how much work it takes to get there.

Ghost includes SEO essentials by default:

Clean URLs with configurable slugs
Meta titles and descriptions on every post
Automatic XML sitemap
Structured data (JSON-LD) for articles
Open Graph and Twitter Card meta tags
Canonical URL support
Fast page speed (which Google cares about)

You don't install anything. It's all there from the first post.

WordPress needs Yoast, Rank Math, or All in One SEO to get the same feature set. These plugins are excellent — Yoast in particular is arguably the best SEO tool available for any platform — but they're plugins you have to install, configure, and keep updated. Without them, WordPress's built-in SEO is bare-bones.

If you're serious about SEO, WordPress with Yoast or Rank Math gives you more control than Ghost (content analysis, keyword tracking, redirect management, schema markup customization). Ghost covers the fundamentals well, but power users will miss the granularity.

My take: Ghost's built-in SEO is enough for a technical blog that focuses on writing good content. If SEO is your primary growth strategy and you want tools that analyze your content as you write, WordPress + Rank Math is hard to beat.

Self-Hosting

Both are open source and free to self-host. The experience differs significantly.

Ghost Self-Hosting

Ghost runs on Node.js and can use SQLite (the default for small sites) or MySQL. The simplest way to self-host Ghost in 2026 is Docker Compose:

`yaml services: ghost: image: ghost:5 ports: - "2368:2368" environment: url: https://blog.yourdomain.com volumes: - ghost_data:/var/lib/ghost/content `

That's a working Ghost instance. Add a reverse proxy (like Nginx Proxy Manager) for SSL, and you have a production blog. The entire ByteGuard stack — Ghost, NPM, Uptime Kuma — runs on a single $9/month VPS.

Ghost's update process is also simple: docker compose pull && docker compose up -d. No database migration scripts, no plugin compatibility checks.

WordPress Self-Hosting

WordPress needs PHP, a web server (Nginx or Apache), and MySQL/MariaDB. You can Docker-ize it, but the typical setup has more moving parts:

`yaml
services:
wordpress:
image: wordpress:latest
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wp
WORDPRESS_DB_PASSWORD: ${WP_DB_PASS}
volumes:
- wp_data:/var/www/html

db:
image: mariadb:11
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASS}
MYSQL_DATABASE: wordpress
MYSQL_USER: wp
MYSQL_PASSWORD: ${WP_DB_PASS}
volumes:
- db_data:/var/lib/mysql
`

Two containers minimum (WordPress + database). Updates are more complex — WordPress core updates through the admin panel, plugins update independently, and theme updates can break if you've customized PHP templates. The "update everything and pray" experience is real.

WordPress is not harder to self-host. It's just more to manage over time.

Membership and Newsletters

Ghost has native membership and newsletter support built in. You can gate content behind free or paid tiers, collect email subscribers, send newsletters, and process payments via Stripe — all without a single plugin or third-party integration.

For a technical blog, this means you can offer a free newsletter (like a weekly security roundup) and optionally add paid-only content later. The subscriber management, email templates, and analytics are all inside Ghost's admin panel.

WordPress needs plugins for all of this. Mailchimp, ConvertKit, or Buttondown for newsletters. MemberPress or Restrict Content Pro for memberships. WooCommerce Subscriptions for payments. Each plugin has its own dashboard, its own settings, and its own subscription cost.

If newsletters and memberships are part of your plan, Ghost saves you significant setup time and ongoing plugin management.

Customization and Extensibility

This is WordPress's strongest advantage and it's not close.

WordPress: 60,000+ plugins. 10,000+ themes. Custom post types, taxonomies, hooks, filters. You can build almost anything — an LMS, a job board, a social network, a SaaS dashboard. The ecosystem is massive.

Ghost: No plugins. Around 100 themes. You can inject custom code via the admin panel (header/footer), build custom themes with Handlebars templates, and use the Content API to build a headless frontend. But the customization ceiling is intentionally lower — Ghost is a publishing platform, not a general-purpose CMS.

For a technical blog, you rarely need WordPress's full extensibility. You need good code blocks, clean layouts, fast rendering, and maybe a newsletter. Ghost covers all of that. But if you want to add a forum, a course platform, a custom tool, or interactive widgets — WordPress gives you an ecosystem that Ghost simply doesn't have.

Pricing

Self-hosted (both free):

Ghost: free + VPS cost ($5-9/month for a small blog)
WordPress: free + VPS cost ($5-9/month for a small blog)

Managed hosting:

Ghost Pro: $9/month (Starter) to $199/month (Business). Includes hosting, email, CDN.
WordPress.com: $4-45/month. Or use shared hosting (Bluehost, SiteGround) at $3-15/month.

If you self-host, the cost is identical — just the VPS. If you go managed, WordPress hosting is significantly cheaper at the low end. Ghost Pro's $9/month starter plan includes features (newsletters, membership) that would cost extra as WordPress plugins.

Who Should Use Ghost

Technical bloggers who want to write and publish without managing plugins
Solo creators who want built-in newsletters and memberships
Self-hosters who value simplicity (one container, SQLite, done)
Anyone who prioritizes page speed and doesn't want to fight for Lighthouse scores
Writers who think in markdown

Who Should Use WordPress

Teams with multiple authors and complex editorial workflows
Sites that need e-commerce, forums, LMS, or custom post types
Anyone who needs a specific plugin that only exists in the WordPress ecosystem
Bloggers on a tight budget who want $3/month shared hosting
Developers who want to build custom functionality with PHP hooks and filters

My Pick

I run Ghost on byte-guard.net and I'd make the same choice again. For a technical blog focused on writing tutorials, comparisons, and security content, Ghost removes friction that WordPress adds. The editor is faster, the default performance is better, code blocks work without plugins, and the admin panel doesn't ask me to update 12 plugins every time I log in.

WordPress is the better choice if you need its ecosystem — and many people genuinely do. But for "I want to write technical posts and have them load fast," Ghost is the more focused tool.

If you want to try self-hosting Ghost, here's how I set up the entire stack from scratch on a Hetzner VPS. Once it's running, harden the server and lock down the containers.

Need a VPS? I run everything on Hetzner — here's how the major providers compare.

Troubleshooting

"Ghost uses too much RAM for my small VPS"

Cause: Node.js has a larger memory footprint than PHP. Ghost idles at ~350 MB.
Fix: Use a VPS with at least 2 GB RAM for Ghost. On 1 GB plans, Ghost will run but leave little room for anything else. WordPress is lighter on RAM if you're on a very small server.

"WordPress is slow even with caching"

Cause: Too many plugins, unoptimized images, or a heavy theme.
Fix: Audit plugins (disable what you don't need), install an image optimizer (ShortPixel or Imagify), and switch to a lightweight theme (GeneratePress, Astra). Run Lighthouse and fix what it flags.

"Ghost doesn't have a plugin I need"

Cause: Ghost intentionally doesn't support plugins.
Fix: Check if you can achieve it with Ghost's code injection (header/footer scripts), a custom integration via the API, or an external service (Zapier, n8n). If the functionality is core to your site, WordPress is the better fit.

"I want to migrate from WordPress to Ghost"

Cause: You've decided Ghost is the better fit.
Fix: Ghost has a built-in WordPress importer. Export your WordPress content as XML, upload it in Ghost Admin > Labs > Import. Posts, tags, and images transfer. Custom fields, shortcodes, and plugin-specific content won't — you'll need to clean those up manually.

"I can't decide"

Fix: Spin up both on a cheap VPS and write three posts on each. The writing experience will tell you more than any comparison article — including this one.

Docker Security Best Practices for Self-Hosters in 2026

byteguard — Sat, 18 Apr 2026 11:29:06 +0000

Docker makes self-hosting feel effortless. Pull an image, write a compose file, run docker compose up -d, and you have a production service in minutes. That's exactly how I built the entire ByteGuard stack — Ghost, Nginx Proxy Manager, and Uptime Kuma on a single Hetzner VPS.

But here's what most "how to self-host X" guides never tell you: the defaults are not secure. Docker out of the box runs containers as root, puts every container on the same network, exposes ports to the entire internet, and gives containers more Linux capabilities than they need. If you hardened your VPS at the OS level but left Docker wide open, you locked the front door and left the windows up.

This post covers 10 Docker security practices I use on the same Hetzner box that runs this blog. Every snippet is real, every recommendation is tested.

Prerequisites

Before you start, you should have:

A Linux VPS with Docker and Docker Compose v2 installed (here's how I set mine up)
Basic familiarity with docker-compose.yml syntax
SSH access to your server (hardened, ideally)
A running Docker stack you want to secure (even a single container counts)

1. Never Run Containers as Root

This is the single highest-impact change you can make. By default, the process inside a Docker container runs as root — UID 0. If an attacker exploits a vulnerability in your application and escapes the container, they land on the host as root. Game over.

The fix is straightforward. In your docker-compose.yml, set the user field:

services:
  ghost:
    image: ghost:5
    user: "1000:1000"
    volumes:
      - ghost_data:/var/lib/ghost/content

This tells Docker to run the Ghost process as UID 1000 instead of root. The container still starts, Ghost still works — but a compromised process now has unprivileged access.

A few things to watch for:

File permissions on volumes. If your volume data was created by root, a non-root container can't write to it. Fix this with chown 1000:1000 on the host directory before switching.
Some images expect root. Official Nginx, for example, needs root to bind to port 80. Inside a compose stack where a reverse proxy handles external traffic, your backend containers don't need to bind privileged ports at all.
Rootless Docker mode goes further — the Docker daemon itself runs without root. This is a bigger architectural change and adds complexity around networking and storage drivers. For most self-hosters, running containers as non-root (the user: field) gives you 90% of the security benefit with 10% of the friction.

2. Use Read-Only Filesystems

A container with a writable filesystem lets an attacker drop binaries, modify config files, install tools, and persist across restarts. Remove that option entirely:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    read_only: true
    tmpfs:
      - /tmp
    volumes:
      - kuma_data:/app/data

With read_only: true, the container's root filesystem is mounted read-only. The container can only write to explicitly mounted volumes and tmpfs mounts. If an attacker gets code execution, they can't modify the application, can't install packages, can't drop a reverse shell binary into /usr/local/bin.

The tmpfs mount for /tmp gives the application a writable scratch space in memory — many apps need this for temporary files, PID files, or socket files. It disappears on container restart, so nothing persists.

Most self-hosted applications work fine with read-only filesystems once you identify which directories actually need writes. Ghost needs /var/lib/ghost/content. Uptime Kuma needs /app/data. NPM needs its data and letsencrypt directories. Everything else can be locked down.

3. Set Resource Limits

Without resource limits, a single misbehaving container can consume all available RAM and CPU, taking down every other service on your VPS. This isn't theoretical — a memory leak, a log file growing without bounds, or a fork bomb in a compromised container will OOM-kill your entire host.

services:
  ghost:
    image: ghost:5
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
    pids_limit: 100

Here's what each limit does:

memory: 512M — the container gets killed if it tries to use more than 512 MB of RAM. Docker sends a SIGKILL, not a gentle shutdown.
cpus: "1.0" — the container can use at most one CPU core. Prevents a single container from starving everything else.
pids_limit: 100 — caps the number of processes inside the container. This is your fork bomb insurance.

For reference, here's what the ByteGuard stack actually uses on our Hetzner CPX22 (8 GB RAM):

Service	Typical RAM	Suggested Limit
Ghost	~350 MB	512M
Nginx Proxy Manager	~120 MB	256M
Uptime Kuma	~80 MB	256M

Note: Set limits based on observation, not guesswork. Run docker stats for a few days to see what your containers actually consume, then set the limit at roughly 1.5x the peak.

4. Manage Secrets Properly

Secrets in Docker stacks are one of those things everyone knows they should handle correctly and almost nobody does. Here's the hierarchy from worst to best:

Worst — hardcoded in docker-compose.yml:

# DON'T DO THIS
environment:
  - database__connection__password=mysecretpassword123

This password is in your compose file, probably in a git repo, possibly public.

Better — .env file:

# docker-compose.yml
environment:
  - database__connection__password=${GHOST_DB_PASSWORD}

# .env
GHOST_DB_PASSWORD=a-real-strong-password-here

The .env file keeps secrets out of the compose file. But it's still plaintext on disk. Lock it down:

chmod 600 .env
chown root:root .env

Add .env to your .gitignore and .dockerignore so it never ends up in a repo or inside an image.

Note: Environment variables set this way are visible via docker inspect. Anyone with access to the Docker socket can read every environment variable in every running container.

Best for single-host self-hosting: The .env approach with proper file permissions is honestly fine for most self-hosters. Docker Secrets (the swarm-mode feature) adds encryption and mounts secrets as files inside containers, but it requires swarm mode — overhead most single-server setups don't need. A locked-down .env file is the pragmatic choice.

5. Scan Your Images

Every time you pull a Docker image, you're running code that someone else built. You trust that ghost:5 is safe because it's an official image — but official images contain operating system packages, and those packages have CVEs.

Docker Scout (built into Docker CLI):

docker scout cves ghost:5

This scans the image and lists known CVEs by severity.

Trivy (open source, more thorough):

# Install
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# Scan
trivy image ghost:5

Pin your image versions. This is as much a security practice as a reliability one:

# Don't do this — you get whatever "latest" means today
image: ghost:latest

# Do this — you know exactly what you're running
image: ghost:5.118.0

Pinned versions mean you choose when to update. latest means Docker pulls whatever the maintainer pushed most recently — and if that image has a supply-chain compromise, you've auto-deployed it.

6. Isolate Your Docker Networks

Docker's default bridge network puts every container on the same subnet. Any container can reach any other container by IP. If an attacker compromises one service, they pivot to everything else without touching the external network.

Create purpose-specific networks and only connect containers that need to talk to each other:

services:
  ghost:
    image: ghost:5
    networks:
      - frontend

  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    networks:
      - frontend
    ports:
      - "80:80"
      - "443:443"

  uptime-kuma:
    image: louislam/uptime-kuma:1
    networks:
      - monitoring

networks:
  frontend:
    driver: bridge
  monitoring:
    driver: bridge
    internal: true

Key patterns:

Only the reverse proxy exposes ports. Ghost doesn't need port 2368 open to the internet — NPM proxies traffic to it internally.

Bind to localhost when you need host access:

ports:
  - "127.0.0.1:3001:3001"  # Only accessible from the host

Warning: Docker manipulates iptables directly, which means UFW and firewalld rules don't apply to Docker-published ports. You can have a perfectly configured firewall and Docker will punch right through it. Binding to localhost is the reliable fix.

internal: true creates a network with no outbound internet access. Use this for backend services that have no reason to make outbound connections.

7. Keep Docker and Images Updated

Docker itself — the engine, containerd, runc — has had serious CVEs. CVE-2024-21626 (runc container escape) and CVE-2024-23651 (BuildKit race condition) are recent examples where an unpatched Docker installation was directly exploitable.

Update the Docker engine:

sudo apt update && sudo apt upgrade docker-ce docker-ce-cli containerd.io

Update your images manually:

# Pull new versions
docker compose pull

# Recreate containers with new images
docker compose up -d

# Clean up old images
docker image prune -f

Watchtower automates image updates:

services:
  watchtower:
    image: containrrr/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_SCHEDULE=0 0 4 * * *

The convenience is real, but so is the risk: Watchtower will auto-deploy a broken update at 4 AM while you're asleep. For a personal blog, that's probably fine. For anything you can't afford downtime on, update manually. At minimum, pin major versions (ghost:5 not ghost:latest) so you get patch updates but not breaking major bumps.

8. Limit Container Capabilities

Linux capabilities split root's power into pieces like NET_BIND_SERVICE (bind to ports below 1024), SYS_ADMIN (mount filesystems), and NET_RAW (use raw sockets). Docker grants about 14 capabilities by default. Most containers don't need most of them.

Drop everything and add back only what's required:

services:
  ghost:
    image: ghost:5
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - SETUID
      - SETGID
    security_opt:
      - no-new-privileges:true

cap_drop: ALL removes every capability.
cap_add gives back only what the application needs. You find out which ones by dropping all and reading the error messages.
no-new-privileges: true prevents any process inside the container from gaining additional privileges through setuid binaries. One of the highest-value single lines you can add.

Warning: Never mount the Docker socket (/var/run/docker.sock) into a container unless you absolutely must. Access to the Docker socket is equivalent to root access on the host. If you must mount it (Watchtower requires it), treat that container as part of your trusted computing base.

9. Configure Logging and Monitoring

If a container gets compromised and you have no logs, you'll never know. Docker's default logging driver (json-file) writes to JSON files on the host — until those files grow unbounded and fill your disk.

Configure log rotation:

services:
  ghost:
    image: ghost:5
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

This caps each container's log at 30 MB total. You can also set this globally in /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Add health checks so you monitor application health, not just port availability:

services:
  ghost:
    image: ghost:5
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:2368/ghost/api/admin/site/"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s

This pings Ghost's API every 30 seconds. If it fails three times, Docker marks the container as unhealthy. Uptime Kuma can then alert you based on health status rather than just TCP connectivity.

Watch container events for anything unexpected:

docker events --filter type=container

On a self-hosted VPS where you're the only operator, any container event you didn't initiate is worth investigating.

10. The Compose Security Checklist

Here's everything above condensed into a checklist for every new service you deploy:

□ Container runs as non-root (user: field or USER in Dockerfile)
□ Filesystem is read-only (read_only: true + explicit volume mounts)
□ Memory and CPU limits set (deploy.resources.limits)
□ PID limit set (pids_limit)
□ Capabilities dropped and selectively added (cap_drop: ALL)
□ no-new-privileges enabled (security_opt)
□ Secrets in .env with 600 permissions, not in compose file
□ Image version pinned (tag, not :latest)
□ Image scanned for CVEs (docker scout or trivy)
□ Container on a purpose-specific network, not default bridge
□ Only necessary ports exposed, bound to 127.0.0.1 if host-only
□ Log rotation configured (max-size + max-file)
□ Health check defined
□ Docker socket NOT mounted (unless required and justified)

A fully hardened compose service looks like this:

services:
  myapp:
    image: myapp:1.2.3
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp
    volumes:
      - app_data:/data
    environment:
      - SECRET_KEY=${APP_SECRET_KEY}
    networks:
      - backend
    deploy:
      resources:
        limits:
          memory: 256M
          cpus: "0.5"
    pids_limit: 50
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 15s

networks:
  backend:
    driver: bridge
    internal: true

Compare that to the typical self-hosting tutorial compose file — image, ports, volumes, done. The difference is about 15 lines of YAML and a dramatically smaller attack surface.

Troubleshooting

Container won't start after adding user: "1000:1000"

Cause: The volume data is owned by root and the non-root user can't write to it.
Fix: Run sudo chown -R 1000:1000 /path/to/volume on the host before restarting.

Container crashes with read_only: true

Cause: The application tries to write to a directory that isn't mounted as a volume or tmpfs.
Fix: Check the container logs (docker logs <container>) for "read-only file system" errors. Add the needed path as a tmpfs mount or a named volume.

cap_drop: ALL breaks the application

Cause: The app needs specific Linux capabilities you haven't added back.
Fix: Start with cap_drop: ALL, then add capabilities one at a time based on the error messages. Common ones: CHOWN, SETUID, SETGID, NET_BIND_SERVICE.

Docker bypasses UFW — port is open despite firewall rules

Cause: Docker manipulates iptables directly, bypassing UFW/firewalld.
Fix: Bind ports to localhost (127.0.0.1:3001:3001 instead of 3001:3001), or configure Docker to respect iptables by setting "iptables": false in /etc/docker/daemon.json (but this breaks Docker networking unless you add manual rules).

Health check keeps failing

Cause: The health check command runs inside the container, which may not have curl installed.
Fix: Use wget -q --spider instead of curl, or for minimal images use a language-native health endpoint check.

Conclusion

Docker security isn't a separate project — it's a layer in the same stack you're already building. If you hardened your Linux VPS with SSH keys, firewalls, and automatic updates, these ten practices are the natural next step: lock down the containers that actually run your services.

Start with the three highest-impact changes:

Run containers as non-root — eliminates the most dangerous default.
Isolate your networks — stops lateral movement between services.
Scan your images — catches known vulnerabilities before they're running in production.

The stack powering this blog — the same one from Post #1 — runs with these practices in place. It's not paranoia. It's the difference between self-hosting and self-pwning.

If you're setting up a new Docker stack and need a VPS, I run all my projects on Hetzner — here's how the three major providers compare.

How to Harden Your Linux VPS in 10 Minutes

byteguard — Sun, 12 Apr 2026 12:55:49 +0000

The moment you spin up a fresh Linux VPS, the clock starts ticking. Within hours — sometimes minutes — your IP shows up in scanner logs and bots begin trying default credentials, common SSH usernames, and known web exploits. I've watched a brand-new server log over four thousand brute-force SSH attempts in its first 24 hours of life.

Most of those attacks are stoppable in 10 minutes of work. Here's the no-fluff checklist I run on every new VPS — the same one I used when I built byte-guard.net itself.

What You'll Need

A fresh VPS running Ubuntu 22.04+ or Debian 11+ (most steps work on any modern distro)
Root SSH access — ideally a just-provisioned server, before you've done anything else
10 minutes
An SSH key on your local machine (we'll generate one if you don't have it)

Note: these commands assume apt-based distros. If you're on Rocky, Alma, or RHEL, swap apt for dnf and ufw for firewalld — the principles are identical.

Step 1 — Update Everything

Bots love unpatched systems. The first thing to do on any new server is apply outstanding updates:

apt update && apt upgrade -y

This pulls down the package index and installs every available update. On a fresh VPS this typically takes 1-2 minutes.

Step 2 — Create a Non-Root User

You should never SSH in as root for daily work. If your root account gets compromised, you've handed an attacker complete control. A regular user with sudo access gives you the same power but keeps an audit trail and adds a small barrier between mistakes and disaster.

adduser amine
usermod -aG sudo amine

Replace amine with your username. adduser will prompt you for a password — make it strong (a passphrase from pwgen -s 32 1 is excellent), but you'll mostly be using SSH keys after the next step.

Step 3 — Set Up SSH Key Authentication

Passwords get brute-forced. Ed25519 SSH keys don't, in any practical sense. If you don't have one yet, generate it on your local machine, not the server:

ssh-keygen -t ed25519 -C "your_email@example.com"

Why ed25519 over rsa? It's faster, smaller, and more modern. The default rsa 3072-bit key is also fine, but ed25519 is the current best practice.

Then copy it to the server, replacing the placeholder with your user and IP:

ssh-copy-id amine@your-server-ip

Now test it from a new terminal:

ssh amine@your-server-ip

You should log in without being asked for a password. If that works, you're ready to lock down SSH itself.

Step 4 — Lock Down SSH

This is the single biggest security win. Open the SSH server config:

sudo vim /etc/ssh/sshd_config

Find and change these lines (uncomment them if needed):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM no

What each does:

PermitRootLogin no — root cannot SSH in at all
PasswordAuthentication no — only SSH keys work, no passwords
PubkeyAuthentication yes — explicitly enable SSH keys (usually default but be explicit)
ChallengeResponseAuthentication no and UsePAM no — close fallback authentication paths

Don't close your current session yet. Test that you can log in via key from a new terminal first. If you've made a config mistake, you'll need that working session to fix it.

Save and reload SSH:

sudo systemctl reload sshd

Open a brand new terminal and SSH in as your user. If it works, your server is now key-only. Now you can safely close the old root session.

Step 5 — Set Up UFW (the Firewall)

ufw is Ubuntu's user-friendly firewall. It ships with most modern distros and just needs to be enabled with a sensible default policy:

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

Verify the rules:

sudo ufw status verbose

You should see only port 22 (SSH) open. If you're running a web server, also allow:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Don't allow ports you're not actually using. Every open port is a potential attack surface.

Step 6 — Install fail2ban

Even with key-only SSH, your logs will fill up with rejected brute-force attempts. fail2ban watches the auth log and bans IPs that repeatedly fail to authenticate:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

Out of the box, the default config protects SSH. Check that the SSH jail is active:

sudo fail2ban-client status sshd

You should see something like:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

To tighten the defaults (out of the box: 5 attempts, 10-minute ban), create a local override:

sudo vim /etc/fail2ban/jail.local

Add:

[sshd]
enabled = true
maxretry = 3
findtime = 10m
bantime = 1h

Then reload:

sudo systemctl restart fail2ban

Three failed attempts in 10 minutes now earns a one-hour ban. Aggressive enough to deter bots, lenient enough that you can recover from your own typos.

Step 7 — Enable Unattended Upgrades

Security patches matter most when they actually get installed. Unattended upgrades automatically apply security updates so you don't have to remember to log in and apt upgrade:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Choose Yes when prompted. This installs a systemd timer that runs daily and applies security updates only — not feature upgrades, so you won't get surprise breaking changes.

Verify it's running:

sudo systemctl status unattended-upgrades

You should see active (running).

Step 8 — Sanity Check

Run these to verify everything is in place:

# SSH config — both should say "no"
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"

# Firewall — should show only the ports you opened
sudo ufw status

# fail2ban — should show the sshd jail as active
sudo fail2ban-client status sshd

# Unattended upgrades — should be active
sudo systemctl is-active unattended-upgrades

If everything checks out, your VPS is hardened against the most common automated attacks.

Bonus — Change the SSH Port (Optional)

Moving SSH off port 22 doesn't add real security (it's security through obscurity), but it does massively cut log noise from drive-by scanners. Edit /etc/ssh/sshd_config:

Port 2222

Then update UFW:

sudo ufw delete allow OpenSSH
sudo ufw allow 2222/tcp
sudo systemctl reload sshd

Connect with ssh -p 2222 amine@your-server-ip. Add it to your ~/.ssh/config so you never type the port again:

Host my-vps
    HostName your-server-ip
    User amine
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Now you can just type ssh my-vps.

What This Does NOT Cover

10 minutes gets you the essentials. It does not cover:

Application-layer security — if you're running a web app, you still need to harden Nginx, your reverse proxy, your CMS, and so on
Intrusion detection — tools like AIDE or Wazuh for filesystem integrity and behavioral monitoring
Centralized logging — shipping logs to a separate server so an attacker who lands on the box can't quietly cover their tracks
Backups — hardening means nothing if you can't restore after an incident

I'll cover those in future posts. For now, you've blocked the overwhelming majority of automated attacks that hit any new VPS.

What's Next

If you're spinning up a VPS for self-hosting, check out the full build: How I Built byte-guard.net from Scratch on a Hetzner VPS. It uses every step in this post and adds Docker, a reverse proxy, and monitoring on top.

I also wrote a deep dive on Docker Security Best Practices — the container-level companion to this guide.

Quick recap — the 10-minute checklist:

apt update && apt upgrade
Create non-root user with sudo
SSH key auth set up
Root login + password auth disabled in sshd_config
UFW firewall enabled, only the ports you need
fail2ban watching the SSH jail
Unattended security updates running

Run this on every new server you build. After a few times you'll be doing it in closer to 5 minutes than 10.

Originally published on byte-guard.net