How do you handle SSL certs and internet access in your setup?

I have NPM running as “gateway” between my LAN and the Internet and let handle it all of my vertificates using the built-in Let’s Encrypt features. None of my hosted applications know anything about certificates in their Docker containers.

As for your questions:

1. You can and should – it makes managing the applications much easier. You should use some containerization. Subdomains and correct routing will be done by the reverse proxy. You basically tell the proxy “when a request for foo.example.com comes in, forward it to myserver.local, port 12345” where 12345 is the port the container communicates over.
2. 100% depends on your use case. I purchased a domain because I host stuff for external access, too. I just have my setup to report it’s external IP address to my domain provider. It basically is some dynamic DNS service but with a “real domain”. If you plan to just host for yourself and your friends, some generic subdomain from a dynamic DNS service would do the trick. (Using NPMs Let’s Encrypt configuration will work with that, too.)
3. You can’t. Every georestricting can be circumvented. If you want to restrict access, use HTTP basic auth. You can set that up using NPM, too. So users authenticate against NPM and only when it was successful,m the routing to the actual content will be done.
4. You might want to look into Cloudflare Tunnel to hide your real IP address and protect against DDoS attacks.
5. No 🙂

I’ve tried 3 times so far in Python/gradio/Oobabooga and never managed to get certs to work or found a complete visual reference guide that demonstrates a complete working example like what I am looking for in a home network. (Only really commenting to subscribe to watch this post develop, and solicit advice:)

DO NOT FORGET, you must give certbot read write permissions in the docker-compose.yml file which isn't shown in this tutorial
-----EXAMPLE, NOT PRODUCTION CODE----

    nginx:
        container_name: nginx
        restart: unless-stopped
        image: nginx
        depends_on:
            - helloworld
        ports:
            - 80:80
            - 443:443
        volumes:
            - ./nginx/nginx.conf:/etc/nginx/nginx.conf
            - ./certbot/conf:/etc/letsencrypt:ro
            - ./certbot/www:/var/www/certbot:ro

    certbot:
      image: certbot/certbot
      container_name: certbot
      volumes: 
        - ./certbot/conf:/etc/letsencrypt:rw
        - ./certbot/www:/var/www/certbot:rw
      command: certonly --webroot -w /var/www/certbot --keep-until-expiring --email *email* -d *domain1* -d *domain2* --agree-tos

Caddy with cloudflare support in a docker container.

I use nginx manager in its own docker container on my unraid server. Was pretty simple to set up all things considered. I would call myself better with hardware than software but not a complete newb and I got it running with minimal headache.

I use nginx proxy manager and let’s encrypt with a porkbun domain, was very easy to set up for me. Never tried caddy/traefik/etc though. Geo blocking happens on my OPNsense with the built in tools.

1. I got started with a guide from these guys back in 2020. I still use traefik as my reverse proxy and Authelia for authentication and it has worked great all this time. As someone else said, everything is in containers on the one host and it is super easy this way. It all runs on a single box using containers for separation. I should probably look into a secondary server as a live backup, but that’s a lot of work / expense. I have a Cloudflare dynamic DNS container running for that.
2. I would definitely advocate for owning your own domain, for the added use case of owning your own email addresses. I can now switch email providers and don’t have to worry about losing anything. This would also lean towards a more memorable domain, or at least a second domain that is memorable. Stay away from the country TLDs or “cute” generic TLDs and stay with a tried and true .com or .net (which may take some searching).
3. I don’t bother with this, I just run my server behind Cloudflare, and let them protect my server. Some might disagree, but it’s easy for me and I like that.
4. Containers, containers, containers! Probably Docker since it’s easy, but Podman if you really want to get fancy / extra secure. Also, make sure you have a git repo for your compose files, and a solid backup strategy from the start (so much easier than going back and doing it later). I use Backblaze for my backups and it’s $2/month for some peace of mind.
5. Do it!!!

or a domain with a random string of characters so no one could reasonably guess it? Does it matter?

That does not work. As soon as you get SSL certificates, expect the domain name to be public knowledge, especially with Let’s Encrypt and all other certificate authorities with transparency logs. As a general rule, don’t rely on something to be hidden from others as a security measure.

A fairly common setup is something like this:

Internet -> nginx -> backend services.

nginx is the https endpoint and has all the certs. You can manage the certs with letsencrypt on that system. This box now handles all HTTPS traffic to and within your network.

The more paranoid will have parts of this setup all over the world, connected through VPNs so that “your IP is safe”. But it’s not necessary and costs more. Limit your exposure, ensure your services are up-to-date, and monitor logs.

fail2ban can give some peace-of-mind for SSH scanning and the like. If you’re using certs to authenticate rather than passwords though you’ll be okay either way.

Update your servers daily. Automate it so you don’t need to remember. Even a simple “doupdates” script that just does “apt-get update && apt-get upgrade && reboot” will be fine (though you can make it more smart about when it needs to reboot). Have its output mailed to you so that you see if there are failures.

You can register a cheap domain pretty easily, and then you can sub-domain the different services. nginx can point “x.example.com” to backend service X and “y.example.com” to backend service Y based on the hostname requested.

I use a central nginx container to redirect to all my other services using a wildcard let’s encrypt cert for my internal domain from acme.sh and I access it all externally using a tailscale exit node. The only publicly accessible service that I run is my Lemmy instance. That uses a cloudflare tunnel and is isolated in it’s own vlan.

TBH I’m still not really happy having any externally accessible service at all. I know enough about security to know that I don’t know enough to secure against much anything. I’ve been thinking about moving the Lemmy instance to a vps so it can be someone else’s problem if something bad leaks out.

I use this github.com/ZoeyVid/NPMplus. I use unifi for goe-blocking.

5). Hey OP, don’t worry, this can seem kind of scary at first, but it is not that difficult. I’ve skimmed some of the other comments and there are plenty of good tips here.

2). Yes, you will want your own domain and there is no fear of other people “knowing it” if you have everything set up correctly.

1b). Any cheap VPS will do and you don’t need to worry about it being virtualized rather than dedicated. What you really care about is bandwidth speed and limits because a reverse proxy is typically very light on resources. You would be surprised how little CPU/memory it needs.

1a). I use a cheap VPS from RackNerd. Once you have access to your VPS, just install your proxy directly into the OS or in Docker. Whichever is easier. The most important thing for choosing a reverse proxy is automatic TLS/Let’s Encrypt. I saw a comment from you about certbot… don’t bother with all that nonsense. Either Traefik, Caddy, or Nginx Proxy Manager (not vanilla Nginx) will do all this for you–I personally use Traefik unless for some reason I can’t. Way less headaches. The second most important thing to decide is how your VPS in the cloud will connect back to your home securely… I personally use Tailscale for that and it works perfectly fine.

3). Honestly, I think Fail2Ban and geo restrictions are overdoing it. Fail2ban has never gotten me any lift because any sort of modern brute force attack will come from a botnet that has 1000s of unique IPs… never triggering Fail2ban because no repeat offenders. Just ensure your VPS has a firewall enabled and you know what ports you are exposing from Docker and you should be good. If your services don’t natively support authentication, look into something like Authelia or Authentik. Rather than Fail2Ban and/or geo restrictions, I would be more inclined to suggest a WAF like Caddy WAF before I reached for geo restrictions. Again, assuming your concern is security, a WAF would do way more for you than IP restrictions which are easily circumvented.

4). Have fun!

EDIT: formatting

On my home network I have nginxproxymanager running let’s encrypt with my domain for https, currently only for vaultwarden (I’m testing it for a bit for rolling it out or migrating wholly over to https). My domain is a ######.xyz that’s cheap.

For remote access I use Tailscale. For friends and family I give them a relay [raspberry pi with nginx which proxys them over tailscale] that sits on their home network, that way they need “something they have”[the relay] and “something they know” [login credentials] to get at my stuff. I won’t implement biometrics for “something they are”. This is post hoc justification though, and nonesense to boot. I don’t want to expose a port and a VPS has low WAF and I’m not installing tailscale on all of their devices so s relay is an unhappy compromise.

For bonus points I run pihole to pretty up the domain names to service.swirl and run a homarr instance so no-one needs to remember anything except home.swirl, but if they do remember immich.swirl that works too.

If there are many ways to skin a cat I believe I chose to use a spoon, don’t be like me. Updating each dockge instance is a couple minutes and updating diet pi is a few minutes more which, individually, is not a lot on my weekly/monthly maintence respectfully. But on aggregate… I have checklists. One day I’ll write a script that will ssh into a machine > update/upgrade the os > docker compose pull/rebuild/purge> move on to the next relay… That’ll be my impetus to learn how to write a script.

#!/bin/bash

cd /path/to/scripts/docker-compose.yml
docker compose pull && docker compose up -d
docker image prune -f

# runs script at 1am on the first of every month
0 1 1 * * /path/to/scripts/docker-updates.sh

#!/bin/bash

apt update -y && apt upgrade -y
reboot now

# runs script at 12am on the first of every month
0 0 1 * * /path/to/scripts/os-updates.sh

It doesn’t improve security much to host your reverse proxy outside your network, but it does hide your home IP if you care.

If your app can exploited over the web and through a proxy it doesn’t matter if that proxy is on the same machine or over the network.

The biggest reason to use VPN is that some ISPs may take issue with you running a web server over a residential service when they see incoming HTTP requests to your IP. If you don’t want to require VPN, then Cloudflare tunnels are perfect for this and they also solve the need for dynamic DNS if you want to use static domain because your domain points to the Cloudflare edge servers and they route it to you wherever your tunnel endpoint is running.

Past that, Traefik is a great reverse proxy that can manage getting LetsEnrcypt SSL certificates for you even with wildcard domains and would still work fine with dynamic DNS.

Tailscale is completely transparent on any devices I’ve used it on. Install, set up, and never look at it again because unless it gets turned off, it’s always on.

Nginx Proxy Manager + LetsEncrypt.

Cloudflare

I used to do a reverse proxy setup with caddy , but now I self host a Wireguard VPN. It has access to Nextcloud on the same machine, Home Assistant and Kodi on another. On our phones, Wireguard only has access to certain apps the rest of the network traffic is normal, so a nice simple setup.

Either tailscale or cloudflare tunnels are the most adapted solution as other comments said.

For tailscale, as you already set it up, just make sure you have an exit node where your services are. I had to do a bit of tinkering to make sure that the ips were resolved : its just an argument to the tailscale command.

But if you dont want to use tailscale because its to complicated to your partner, then cloudlfare tunnels is the other way to go.

How it works is by creating a tunnel between your services and cloudlare, kind of how a vpn would work. You usually use the cloudlfared CLI or directly throught Cloudflare’s website to configure the tunnel. You should have a DNS imported to cloudflare by the way, because you have to do a binding such as : service.mydns.com -> myservice.local Cloudlfare can resolve your local service and expose it to a public url.

Just so you know, cloudlfare tunnels are free for some of that usage, however cloudlfare has the keys for your ssl traffic, so they in theory could have a look at your requests.

best of luck for the setup !

If security is one of your concerns, search for “HTTP client side certificates”. TL;DR: you can create certificates to authenticate the client and configure the server to allow connections only from trusted devices. It adds extra security because attackers cannot leverage known vulnerabilities on the services you host since they are blocked at http level.

It is a little difficult to find good and updated documentation but I managed to make it work with nginx. The downside is that Firefox mobile doesn’t support them, but Firefox PC and Chrome have no issues.

Of course you want also a server side certificate, the easiest way is to get it from Let’s Encrypt

nixos with nginx services does all proxying and ssl stuff, fail2ban is there as well

{ pkgs, modulesPath, ... }:

{
  imports = [
    (modulesPath + "/virtualisation/proxmox-lxc.nix")
  ];

  security.pki.certificateFiles = [ "/etc/ssl/certs/ca-certificates.crt" ];

  system.stateVersion = "23.11";
  system.autoUpgrade.enable = true;
  system.autoUpgrade.allowReboot = true;

  nix.gc = {
    automatic = true;
    dates = "weekly";
    options = "--delete-older-than 14d";
  };

  networking.firewall.allowedTCPPorts = [ 80 443 ];

  services.openssh = {
    enable = true;
    settings.PasswordAuthentication = true;
  };

  users.users.XXXXXX = {
    isNormalUser = true;
    home = "/home/XXXXXX";
    extraGroups = [ "wheel" ];
    shell = pkgs.zsh;
  };

  programs.zsh.enable = true;

  security.acme = {
    acceptTerms = true;
    defaults.email = "XXXXXX@yahoo.com";
  };

  services.nginx = {
    enable = true;

    virtualHosts._ = {
      default = true;
      extraConfig = "return 500; server_tokens off;";
    };

    virtualHosts."XXXXXX.dynu.net" = {
      enableACME = true;
      addSSL = true;

      locations."/_matrix/federation/v1" = {
        proxyPass = "http://192.168.10.131:8008";
        extraConfig = "client_max_body_size 300M;" +
          "proxy_set_header X-Forwarded-For $remote_addr;" +
          "proxy_set_header Host $host;" +
          "proxy_set_header X-Forwarded-Proto $scheme;";
      };

      locations."/" = {
        extraConfig = "return 302 https://element.XXXXXX.dynu.net;";
      };

      extraConfig = "proxy_http_version 1.1;";
    };

    virtualHosts."matrix.XXXXXX.dynu.net" = {
      enableACME = true;
      addSSL = true;

      extraConfig = "proxy_http_version 1.1;";

      locations."/" = {
        proxyPass = "http://192.168.10.131:8008";
        extraConfig = "cli

{ pkgs, modulesPath, ... }:

{

  imports = [
    (modulesPath + "/virtualisation/proxmox-lxc.nix")
  ];

  security.pki.certificateFiles = [ "/etc/ssl/certs/ca-certificates.crt" ];

  system.stateVersion = "23.11";
  system.autoUpgrade.enable = true;
  system.autoUpgrade.allowReboot = false;

  nix.gc = {
    automatic = true;
    dates = "weekly";
    options = "--delete-older-than 14d";
  };

  services.openssh = {
    enable = true;
    settings.PasswordAuthentication = true;
  };

  users.users.XXXXXX = {
    isNormalUser = true;
    home = "/home/XXXXXX";
    extraGroups = [ "wheel" ];
    shell = pkgs.zsh;
  };

  programs.zsh.enable = true;

  environment.etc = {
    "fail2ban/filter.d/matrix-synapse.local".text = pkgs.lib.mkDefault (pkgs.lib.mkAfter ''
      [Definition]
      failregex = .*POST.* - <HOST> - 8008.*\n.*\n.*Got login request.*\n.*Failed password login.*
                  .*POST.* - <HOST> - 8008.*\n.*\n.*Got login request.*\n.*Attempted to login as.*\n.*Invalid username or password.*
    '');
  };

  services.fail2ban = {
    enable = true;
    maxretry = 3;
    bantime = "10m";
    bantime-increment = {
      enable = true;
      multipliers = "1 2 4 8 16 32 64";
      maxtime = "168h";
      overalljails = true;
    };
    jails = {
      matrix-synapse.settings = {
        filter = "matrix-synapse";
        action = "%(known/action)s";
        logpath = "/srv/logs/synapse.json.log";
        backend = "auto";
        findtime = 600;
        bantime  = 600;
        maxretry = 2;
      };
    };
  };

  virtualisation.oci-containers = {
    containers = {

      postgres = {
        autoStart = false;
        environment = {
          POSTGRES_USER = "XXXXXX"

Tailscale is very popular among people I know who have similar problems. Supposedly it’s pretty transparent and easy to use.

If you want to do it yourself, setting up dyndns and a wireguard node on your network (with the wireguard udp port forwarded to it) is probably the easiest path. The official wireguard vpn app is pretty good at least for android and mac, and for a linux client you can just set up the wireguard thing directly. There are pretty good tutorials for this iirc.

Some dns name pointing to your home IP might in theory be an indication to potential hackers that there’s something there, but just having an alive IP on the internet will already get you malicious scans. Wireguard doesn’t respond unless the incoming packet is properly signed so it doesn’t show up in a regular scan.

Geo-restriction might just give a false sense of security. Fail2ban is probably overkill for a single udp port. Better to invest in having automatic security upgrades on and making your internal network more zero trust

I came here to upvote the post that mentions haproxy, but I can’t see it, so I’m resorting to writing one!

Haproxy is super fast, highly configurable, and if you don’t have the config nailed down just right won’t start so you know you’ve messed something up right away :-)

It will handle encryption too, so you don’t need to bother changing the config on your internal server, just tweak your firewall rules to let whatever box you have haproxy running on (you have a DMZ, right?) see the server, and you are good to go.

Google and stackexchange are your friends for config snippets. And I find the actual documentation is good too.

Configure it with certificates from let’s encrypt and you are off to the races.

For point number 2, security through obscurity is not security.
Besides, all issued certificates are logged publicly. You can search them here crt.sh

Nginx Proxy Manager is easy to set up and will do LE acme certs, has a nice GUI to manage it.

If it’s just access to your stuff for people you trust, use tailscale or wireguard (or some other VPN of your choice) instead of opening ports to the wild internet.
Much less risk

Why is it too much asking your partner to use wireguard? I installed wireguard for my wife on her iPhone, she can access everything in our home network like she was at home, and she doesn’t even know that she is using VPN.

Why do so many people do this incorrectly. Unless you are actually serving a public then you don’t need to open anything other than a WireGuard tunnel. My phone automatically connects to WireGuard as soon as I disconnect from my home WiFi so I have access to every single one of my services and only have to expose one port and service.

If you are going through setting up caddy or nginx proxy manager or anything else and you’re not serving a public… you’re dumb.

if you know/use docker, the solution that has been the most straightforward for me is SWAG. the setup process is fairly easy when combined with registering your domain with Porkbun, as they allow free API access needed for obtaining top-level (example.com) as well as wildcard (*.example.com) SSL certificates.

along with that, exposing a new service is fairly easy with the plethora of already included nginx configs for services like Nextcloud, Syncthing, etc.

I use traefik with a wildcard domain pointing to a Tailscale IP for services I don’t want to be public. For the services I want to be publicly available I use cloudflare tunnels.