Selfhosted

For my server, secure enough. Just the basic recommendations, non-standard ssh port, default deny on firewall, fail2ban, etc. It doesn't need a lot of security because its just a static website. For most projects this is enough.

I will say, a honeypot can be useful and I'm getting one set up but its a low priority for me.

Secrets

• Encrypted secrets file. All repo-managed credentials live in secrets/secrets.yaml, encrypted with SOPS/age.
• Encrypted OpenTofu state. State and plans are encrypted client-side (PBKDF2 + AES-GCM) with a passphrase from TF_VAR_state_passphrase.

Network perimeter

• Default-drop firewall on the router. I use a hand-written nftables ruleset with policy drop on both input and forward. Only lo, lan0 and wg0 are trusted. WAN accepts only established traffic, WireGuard UDP and HTTP/HTTPS.
• No SSH from the WAN. sshd on the router is not exposed to the internet at all.
• WireGuard for remote access.
• Forced DNS. NAT redirects all LAN and VPN port-53 traffic to the router's AdGuard. AdGuard uses Quad9 over DoT upstream, with blocklists and safe search.
• Second-level ACL in nginx. Private .home vhosts and Grafana carry allow LAN; allow VPN; deny all;.
• TLS everywhere. Every public vhost sets forceSSL with recommendedTlsSettings. Certificates come from ACME DNS-01, so issuance needs no inbound port 80. Cloudflare is DNS-only with no proxy, so no third party sees plaintext.

Host access

• SSH hardening. Password and keyboard-interactive auth are off, PermitRootLogin = "no", and logins are key-only.
• Dedicated deployer system user. It uses a CI-only keypair, separate from the interactive keys. Everything it does through sudo is logged with LOG_INPUT/LOG_OUTPUT to /var/log/sudo-deployer.log.

I'm a little paranoid, so this is my security set up.

SSH, blocked at firewall level, only allowing specific local IP to access port 22. Also authentication is done by key, with password disabled.

Most services are local only and I access them through wireguard VPN when I'm outside my home.

For services that need a domain name and be public facing, I use a reverse proxy, with the following protections:

• Very restrictive geoIP block, only my country can access.
• Restrictive rate limiting.
• Crodwsec, with community lists, a pluging for open lists, community rules and my own very restrictive set of rules for banning attackers. (For instance as soon as the requested path contains ".env" that's an instant ban, no second chances).
• Monitoring through grafana.
• Some complex services that need a valid tls handshake but I only want to use them myself have a setup when they are technically open to the net, to get let's encrypt, but the server rejects every IP request but mine.

Recently I also reduced some noise, surface attack, deleting the A register from my second level domain and using an obscured target for the CNAME records. I also want to delete the www subdomain as it gets a lot of uneeded noise.

it's so secure not even I, the owner can get in
(I forgot the password to truenas scale)

I run an AI Agent as root and let it manage everything

My stuff is only accessible from my LAN (because I haven't figured out how to set up a tunnel or reverse proxy yet).

It's more difficult to steal my data when it's only stored in a single place without backups.

Reverse proxy for services for friends and family

Tailscale for my remote services

Basically everything is in docker containers.

My setup is airgapped (everything is wireless).

Nothing to protect if you don't expose it.

Plain and simple - Wireguard.

All services run as separate services user in rootless podman containers.

Only one nginx exposed to the open internet acting as reverse proxy to stuff where Wireguard requirement would be too inconvenient to be useful (shared calendar).

If you're talking about remote access specifically, I use tiers.

"Public" is open, but goes through crowdsec and anubis, and is on a DMZ network. This is my website, blog, Fediverse, etc.

"Private" is either secured with mtls or wireguard. This is stuff that's only for me or family, like media or home assistant.

"Sensitive" is wireguard only. This is infrastructure management, Paperless, etc.

Seperate servers (with different locations - one in LAN,one with Hetzner, one with OVH) that provide intranet (only available in the HomeLAN or via Wireguard), extranet("public" services as in "to friends and family") and Backup/Monitoring services.

Everything behind OPNsenses, with strict firewall rules, crowdsec and acting as a reverse proxy. Additionally certain things are locked down via hosting provider based firewalls (as I have the luxury to have a static IP at home I can easily do limit ingress for some extranet services)

VLAN seperation both within HomeLAN and Proxmox. Proxmox firewall rules to limit intra VLAN access. Unpriviliged LXC containers - seperated per service. Anything needing docker runs in rootless podman within an unpriv. LXC. (If it does not run like that it won't run. End of discussion) Authentik for OIDC. If it does not do OIDC/SAML is does not run. (Only exception is LDAP in HomeNet as I am running free IPA anyway) Also acts as Jumpserver via VNC/RDP.

As I am using ansible/Terraform (via Semaphore) for everything I also strictly enforce fail2ban and certain monitoring components. (Namely Zabbix and Wazuh)

It's powered off.

I have a few practices, technologies that I leverage across my systems, network for selfhosting.

First, the principles I follow:

• Least access — Limit exposure of ports, services to as limited an audience as possible.
• Don't put all your eggs in one basket — Spread your service deployments out across different machines, or at least different users on the same machine. Group relevant services together as seen fit, but don't deploy everything in the same place.
• Security through obscurity is bad — What I mean is make your process for deploying and maintaining applications easy to read and understand the context. Software versions, customizations, and other tweaks should be easy to find and understand.
• Mind your secrets — Seriously, don't engage in practices that may lead to exposed secrets. Keep files that may have them out of your git repos. Read your logs before pasting them or feeding them to another application. If it can be done, automate secret deployments where possible.
• Understand your tech — Learning stuff in the context of LAN is perfectly fine and I encourage doing so. For anything that you plan to bring to any wider network though, please do the recommended reading about each component you are using. Security mistakes often come from glossing over something that wasn't apparent, but was important. Yes, this will slow down your work to a crawl if you're used to just pulling Docker images and deploying at-will. I still recommend to take the hit in speed in order to do things as right as possible the first time.

Now, onto the actual technologies and practices I use:

First off, as hinted above, I make heavy use of containerized applications. OCI (commonly referred to as Docker) containers are a convenient way for developers to package their applications, but also offer some affordances in security if you leverage the tools well. I personally use Podman as my tool of choice for many reasons, but one of them being the relatively sane rootless setup that is ready to use out of the box. This means that can be started up at user-level (without root permissions and with user-level restrictions), which is great in case of an exploit to escape the sandbox occurs. Combine this with pairing relevant applications together on different users, and an actual semblance of a security model starts to form in mitigating the potential disaster from a rogue container. If you use multiple users on a system, make sure they are isolated users who should not be able to even read another user's files; don't give users free sudoers access. I also utilize multiple different machines for different processes, which works as well.

Secondly, I utilize Quadlets, a way to write podman container, pod, network definitions as SystemD units, and be able to hook them in with other SystemD units. I love this approach for many reasons, including having declarative definitions of most of my deployment stack. Certainly makes redeployments, migration, and restoration a breeze when tracked with git. More importantly for security, an easy-to-read set of config files makes managing selfhosting significantly more predictable and boring, which is how it should be. Any question I might have about how something is setup I can find within a minute every time. Less guessing, less searching, more informed decisions; which is crucial to making less mistakes that could have security implications. Practically speaking, there are more than just Quadlets: Docker compose, Kubernetes definitions, Helm charts, and others all exist with their various strengths and weaknesses. Pick what works for you.

With actually exposing stuff to the internet (or at least a broader network), I do limit my machines' reach where possible. I have the capability to, but do not directly port forward anything from my home router. I rent a small VPS with minimal latency to my location that I use as a forwarding proxy for public services. I have a wireguard tunnel on my home router to the VPS that I let access specific IP ranges that contain my static IP server IPs only, with firewall rules on the router to back the access grant in the tunnel config. From there, I forward traffic to the VPS's public IP with FirewallD on the edge, or have traffic sit behind a reverse proxy on said VPS.

With most traffic though (especially with services I don't completely trust to leave exposed), I restrict who and what may gain access to said services. If the model works for you, Zero Trust Tunneling / Mesh Network solutions like Tailscale, Netbird, or Netmaker are of high recommendation. For many of these, they allow you to connect end-user devices and serving devices together over a dynamic Wireguard tunnel (or similar) to share services that normally wouldn't be as suitable sitting on the open internet. I personally run a selfhosted instance of Headscale which also sits on the edge VPS, and acts as my Tailscale control server and sole traffic relay for connections that can't be direct peer to peer. Most of my services sit behind the requirement of being in the virtual network, while some I configure dual-offering. I should note that using Tailscale and others that offer direct peer-to-peer will directly expose your devices' public IPs to others in the network that can interact.

Lastly, I can note that while there have been many efforts with various solutions to try and make selfhosting as mindlessly easy as possible, I don't recommend running many of them for a very specific reason. Much like how I hate people using LLM chatbots in place of their own brains to try and solve problems, having some container management platform take the initial setup out of selfhosted applications and attempt to abstract away as much of finer details as possible can lead to a fast initial deployment, but certainly not a secure one long-term. I do believe there are many practices and details one should learn about their selfhosting setup (such as networking, firewalls, what each app depends on, how best to upgrade them, when to pin application versions, etc.). Having a platform take that away in the beginning will only lead to problems later down the line when those funny little details start to become more important. Only learning about those details when the problems start to occur becomes a much more monumental hurdle to cross than simply learning the details as you set things up for the first time.

Final Notes

This comment is quite large, even by my standards. Yet, I am sure I have missed something somewhere. I will be happy to reply to any specifics about either technology or practice if I missed anything.

Every Service is in its own VM and everything thats publicly accessible sits in its own network sepperated from everything else. I do daily backups in case anything goes wrong

I don't have anyone to share it with, so it's not open.

Wireguard VPN. I actually have a public hosted Oracle server that when authentic opens port 443 for that source IP temporary so no VPN will be needed. Computer visit free pub Oracle VM. Android Phone scan QR, start Wireguard and auth that user. Computer can now reach my home server on port 443 and 22 for 24 hours as the source IP is allowed.

I do this instead of crowdsec etc. I expect zero days vulnerabilities that someone will utilize so dont trust nginx and ssh to be wide open.

Secure enough I suppose.

f2b at the FW, auth with MFA for anything exposed, anything local only has restricted access at the FW level, with exposed (via proxy) and local-only (separate proxy) on different vlans. Each service is (typically, with some exceptions) an LXC, with additional rules and templated out based on use case. The few cases where docker is involved is local-only and that has its own vlan with additional rules.

User process makes sense, but login shell is probably limited value. If your service gets pwn'd the attacker will spin up a reverse shell, and that isn't protected by the login shell. You ideally want to use selinux/apparmor to prevent execution, or containers to limit the available execution environment.

I operate SSH, nginx, and uvicorn like this:

SSH

• pubkey auth only
• not on default port
• AllowUsers var in sshd.conf is set

nginx

• runs as its own user
• serves static files or forwards to uvicorn
• rate limits are set
• returns 444 on requests that aren't in sitemap.xml (nonsense and probing)

uvicorn

• runs as its own user

and a firewall runs on top of everything in a hardened kernel. I'm self taught, so I could be missing something obvious and this setup has been reliable for me for a few years.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

[Thread #105 for this comm, first seen 16th Sep 2026, 06:30] [FAQ] [Full list] [Contact] [Source code]

Walking to the setup you would stub your small toe a few times, that alarm is enough.

Everything runs through fully hardened/restricted systemd units, as separate user with minimal access rights for everything

You'd need to escape the software, restrictions and get root to do anything meaningful, while avoiding detection

I tend to go overboard on security, or so I've been told.

https://lemmy.world/post/43533409

Rootless LXC containers, TLS. In my case, I have both VPS and my own hardware, so every sensitive data is hosted on the hardware only.