Nginx Proxy Manager op een VPS: een review en installatiehandleiding

NPM vs Caddy vs Traefik: welke reverse proxy past bij je VPS

De drie tools verschillen op vier assen die de keuze bepalen: hoe je ze configureert, hoe ze HTTPS afhandelen, hoe ze schalen met het aantal services en hoeveel RAM ze in rust gebruiken. Hier is de vergelijking.

De cijfers voor RAM in rust zijn benaderende waarnemingen uit één vergelijking uit 2026, geen vaste vereisten. Het werkelijke gebruik varieert per imageversie, ingeschakelde functies, verkeer en logging.

De criteria om over te stappen volgen rechtstreeks uit die tabel. Als je een dashboard wilt en een handvol services draait die niet vaak veranderen, is NPM de juiste tool. Als je de voorkeur geeft aan configuratie als code, de kleinste footprint wilt, of Caddy's automatische HTTPS-provisioning en -verlenging zonder ACME-configuratie, gebruik dan Caddy. Ik grijp zelf naar Caddy bij single-site-implementaties omdat de SSL-afhandeling automatisch is en de Caddyfile kort is. Als je vaak containers toevoegt, verwijdert of opnieuw implementeert, betekent de op labels gebaseerde auto-discovery van Traefik dat je niet langer elke nieuwe host handmatig hoeft te registreren.

Er is ook kaal Nginx met Certbot, waar sommige beheerders de voorkeur aan geven voor precieze controle of niet-Docker-implementaties. Certbot kan certificaatverlenging automatiseren, maar je beheert de virtualhostroutering en Nginx-configuratie nog steeds zelf. Als je belangrijkste reden om NPM te overwegen het vermijden van handmatige proxyconfiguratie is, is kaal Nginx waarschijnlijk niet de betere keuze.

Een kanttekening bij de keuze: de vergelijking van byte-guard komt uit op Caddy als de lichtste optie in die vergelijking, en voor een verse single-host-opzet in 2026 is dat een redelijke keuze. Caddy wint doordat het lichter is dan NPM, maar als je specifiek een GUI wilt, is het niet je beste keuze.

Voor een diepere vergelijking van de onderliggende engines, zie de vergelijking van Caddy vs Nginx op een VPS.

Vereisten: wat je nodig hebt

Zorg dat je deze zaken klaar hebt voordat je implementeert. Dit is een korte lijst, maar sla je een item over, dan mislukt de certificaatstap later.

• Een VPS met Docker en Docker Compose geïnstalleerd (Ubuntu 22.04 LTS of Debian 12 is prima).
• Een domeinnaam, met een DNS A-record (en AAAA als je IPv6 gebruikt) dat naar het publieke IP van je VPS verwijst.
• SSH-toegang tot de VPS.
• Poort 80 en 443 open naar het internet op je firewall.
• Poort 81 alleen door jou bereikbaar, niet open voor het publiek (behandeld in de beveiligingssectie).

Nginx Proxy Manager op je VPS instellen met Docker Compose

Deze sectie implementeert NPM met Docker Compose. Zodra je DNS-records naar de VPS resolven, is de containeropzet zelf snel, hoewel DNS-propagatie en certificaatuitgifte langer kunnen duren.

De opzet gebruikt één Docker Compose-bestand en een eenmalig commando om een gedeeld Docker-netwerk aan te maken. Maak een map aan, maak het netwerk aan, voeg het onderstaande docker-compose.yml bestand toe en start de container.

Maak eerst het gedeelde Docker-netwerk aan:

docker network create proxy

Maak vervolgens het volgende docker-compose.yml bestand:

# docker-compose.yml
services:
  npm:
    image: 'jc21/nginx-proxy-manager:<PATCHED_VERSION>'
    restart: unless-stopped
    ports:
      - '80:80'                 # public HTTP
      - '443:443'               # public HTTPS
      - '127.0.0.1:81:81'       # admin UI, reachable only from the VPS itself
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    networks:
      - proxy
networks:
  proxy:
    external: true

Koppel elke backendcontainer die NPM op servicenaam moet bereiken aan hetzelfde externe proxy netwerk. Zo kan NPM de container op zijn servicenaam resolven zonder de poort van de backendapplicatie op de VPS te publiceren.

Maak van beide een back-up, ./data en ./letsencrypt vóór upgrades. De datamap bevat de database en gegenereerde configuratie van NPM, terwijl de Let's Encrypt-map het certificaatmateriaal bevat.

Een paar dingen over dit bestand. De image gebruikt standaard een SQLite-database die is opgeslagen in het ./data volume. Dat is de standaardbackend en die is juist voor de meeste single-VPS-implementaties. Als je een externe database nodig hebt, ondersteunt NPM MariaDB/MySQL en PostgreSQL, wat betekent dat je een databaseservice en de bijbehorende omgevingsvariabelen toevoegt. Voor één VPS is SQLite nog steeds de eenvoudigste standaard, tenzij je een duidelijke reden hebt om de database uit het datavolume te halen. Het restart: unless-stopped beleid betekent dat NPM weer opstart als de VPS herstart, wat je wilt voor een service die vóór al het andere staat.

Start het en bevestig dat het draait:

docker compose up -d
docker compose ps

Verwachte uitvoer: de npm container met status Up, poort 80 en 443 publiek gemapt, en poort 81 alleen gebonden aan 127.0.0.1. De eerste start duurt een paar minuten terwijl NPM een JWT-sleutel genereert, de database initialiseert en de standaard admin-gebruiker aanmaakt. De officiële installatiedocumentatie beschrijft deze eerste-startsequentie.

Maak een SSH-tunnel vanaf je lokale computer voordat je de beheerinterface opent:

ssh -L 8181:127.0.0.1:81 user@your-vps

Open vervolgens http://127.0.0.1:8181 in je browser. Log bij een verse installatie in met [email protected] en changeme, vervang vervolgens direct het standaard e-mailadres en wachtwoord. Maak het dashboard niet publiek bereikbaar zolang de standaardinloggegevens actief zijn.

Zodra je de admininloggegevens hebt gewijzigd, voeg je je eerste proxyhost toe:

1. Ga in het dashboard naar Hosts, dan Proxy Hosts, dan Add Proxy Host.
2. Stel in Domain Name op je subdomein (bijvoorbeeld cloud.example.com).
3. Instellen Forward Hostname / IP op de naam of het IP van de backendcontainer, en Forward Port op de poort waarop deze luistert.
4. Opslaan. De proxyhost verschijnt in de lijst en verkeer naar dat subdomein bereikt nu je container.

Als je hiernaast een Docker-beheer-UI draait, geldt hetzelfde patroon: verwijs op dezelfde manier een subdomein naar de containerbeheertool en doe hetzelfde voor een monitoringstack van Prometheus en Grafana die je achter de proxy wilt plaatsen.

Automatische HTTPS configureren voor een subdomein

Deze sectie levert je een geldig, automatisch verlengend Let's Encrypt-certificaat voor je subdomein. De vereiste waar mensen op stuklopen: het DNS A-record voor dat subdomein moet al naar je VPS verwijzen en poort 80 moet bereikbaar zijn vanaf het internet, omdat Let's Encrypt het domein verifieert door er verbinding mee te maken.

Nu de proxyhost is aangemaakt, vraag je het certificaat aan:

1. Bewerk de proxyhost, open het SSL tabblad.
2. Onder SSL-certificaatkies Request a new SSL Certificate.
3. Inschakelen Force SSL en HTTP/2 Support. Schakel HSTS pas in nadat je hebt bevestigd dat HTTPS correct werkt, omdat browsers het beleid kunnen cachen en herstel van een fout in het certificaat of de proxyconfiguratie moeilijker kunnen maken.
4. Ga akkoord met de Let's Encrypt-voorwaarden en sla op.

Standaard gebruikt NPM de HTTP-01-challenge voor niet-wildcardnamen, waarbij elke aangevraagde hostnaam via poort 80 wordt gevalideerd. Een certificaat kan meerdere niet-wildcardnamen bevatten, maar HTTP-01 kan geen wildcardcertificaten uitgeven. Wildcardnamen zoals *.example.com vereisen de DNS-01-challenge met een ondersteunde DNS-provider. Voor een normale opzet met één subdomein per service is HTTP-01 alles wat je nodig hebt en verlopen verlengingen automatisch.

Je VPS dimensioneren voor Nginx Proxy Manager

NPM zelf is licht; de dimensioneringsvraag gaat eigenlijk over NPM plus de services die erachter zitten. De footprint van de proxy in rust is zelden de beperkende factor. Een Nextcloud-instantie of Ghost-blog gebruikt meer resources dan de proxy zelf.

Zo pakken de niveaus in de praktijk uit:

• Minimale praktische ondergrens: 1 GB RAM, 1 vCPU en 10 GB opslag. Eén dimensioneringsgids van derden gebruikt dezelfde ondergrens, maar behandel die als planningsadvies in plaats van een officiële NPM-vereiste. Het is genoeg voor NPM, het besturingssysteem en een paar lichte services, maar laat weinig speelruimte.
• Comfortabel: 2 GB RAM, 1 vCPU, 20 GB opslag. NPM plus drie tot vijf services met ruimte om te ademen. Dit is de ideale balans voor de meeste self-hosters.
• Een stap hoger: 4 GB RAM, 2 vCPU. Voor acht tot twaalf services, of een opzet met noemenswaardig verkeer waarbij je CPU-speelruimte wilt voor TLS-terminatie.

Het getal waarop je dimensioneert is de som van de geproxyde apps, niet NPM. Tel de RAM-footprints op van de services die je wilt draaien, tel de kleine overhead van de proxy in rust erbovenop, en kies het niveau daarboven met marge.

De server dimensioneren is het makkelijke deel. NPM draaiend krijgen betekent nog steeds de VPS provisioneren, Docker installeren, de image ophalen en die eerste-startopzet doorlopen. Als je de provisioningstappen liever overslaat, heeft de marketplace van Cloudzy een one-click Nginx Proxy Manager-implementatie op een NVMe-VPS. Het zet de container op een verse server neer, zodat je direct naar het dashboard en je eerste proxyhost gaat. Hoe dan ook, de bovenstaande dimensioneringsniveaus zijn waar je op provisioneert.

Veelgestelde vragen