Guides

These guides are written for a typical “home server on a Raspberry Pi” setup: a dynamic DNS hostname, a router you control, and a mix of apps that should not be public. They assume you want the smallest possible public surface area, with clear separation between content pages and admin/control screens.

DDNS and Exposure Reverse Proxy Authentication Backups Maintenance

DDNS and Port Exposure (What to Open)

With a DDNS hostname, it is tempting to expose multiple ports: one for a dashboard, one for a file manager, one for an API, and so on. That is usually the fastest way to get compromised. The safer pattern is to expose only one public port: HTTPS (443). Everything else should be internal only, reachable via local network, VPN, or a strict allowlist.

Treat “admin” as a different security class from “public content”. If a page can delete files, reboot services, edit configuration, upload plugins, or run commands, it should not be reachable on the open internet. If you must access it remotely, put it behind VPN or strong authentication plus additional restrictions (rate limit, IP allowlist, and audit logs).

Router rules: simple and reviewable

Forward only `443/tcp` to your reverse proxy.
Do not forward SSH directly (use VPN, or at minimum a high port + keys + allowlist).
Disable UPnP so devices cannot silently open ports.

Reverse Proxy (One Front Door)

A reverse proxy gives you one place to do HTTPS, redirects, security headers, caching, and access control. It also lets you keep internal services on non-public ports and networks. Even if you only run one app today, this is worth doing early: it prevents the “random ports everywhere” problem later.

What “good” looks like

One certificate manager (Let’s Encrypt or equivalent) renewing automatically.
One access log to answer “what hit my server?”
Per-path rules: public pages are public, admin pages require auth.

Security headers (baseline)

Exact headers depend on your apps, but you generally want a restrictive default and then loosen per application if needed.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()

Authentication (Separate Public and Private)

The biggest conceptual mistake is treating everything on your server as “one website”. In practice you have: public pages (that can be indexed), private apps (that are useful but not public), and admin endpoints (that should never be public). Use that classification to decide where ads belong and where they do not.

Public content: fine to monetize if it is original and useful.
Private apps: keep private (and typically do not monetize).
Admin screens: keep private; do not place ad code here.

Practical controls

HTTP auth for small sensitive endpoints.
App-level login for user apps (strong passwords, rate limits).
VPN for admin access (preferred).

Backups (Prove You Can Restore)

Backups fail quietly. A directory fills up, a retention job stops, or you discover that you backed up the wrong files. The only reliable approach is to practice restore. A monthly restore drill can be small: a single folder and a config file. The point is to confirm that your backup format and your notes are enough to rebuild.

What to include

App configs (compose files, Nginx/Caddy configs, systemd units).
Databases (or their volumes) with a documented restore command.
Secrets location (and how they are rotated) without publishing them publicly.

Restore drill (example)

1) Restore to a separate folder or spare machine
2) Start only one service
3) Verify login + a basic workflow
4) Write down what you forgot and fix the notes

Maintenance (Keep It Boring)

The best home server is the one that does not need weekly attention. That means: schedule updates, check disk space, and keep logs. Avoid “mystery dependencies” by writing down how a service is deployed and where its data lives.

Pick one day per month for updates (and take a snapshot/backup first).
Watch disk usage and journal size to prevent sudden outages.
Remove old test apps that are no longer used.