Reverse proxy Caddy care trimite trafic HTTPS catre containere Docker pe un VPS

Self-hosting

Reverse proxy Caddy cu Docker: HTTPS automat pe VPS

Orice aplicatie self-hosted incepe la fel: pornesti un container, el asculta pe un port oarecare, 3001 sau 8080, si deschizi http://ip-ul-tau:3001 in browser. Merge, dar nu e ceva ce poti da unui client si nici nu e placut de folosit zi de zi: fara lacatel, cu un numar ciudat in adresa, si cu inca o usa deschisa catre tot internetul pentru fiecare aplicatie noua. Solutia e un reverse proxy, o singura usa de intrare care raspunde pe porturile web standard, se ocupa de HTTPS pentru toate domeniile si trimite discret fiecare cerere catre containerul potrivit. In ghidul asta construim exact asta cu Caddy, iar partea cea mai buna e ca certificatele se administreaza singure.

Caddy este un server web open source scris in Go, publicat sub licenta Apache 2.0, cu site-ul oficial la caddyserver.com si codul pe github.com/caddyserver/caddy . Functia lui de baza e HTTPS-ul automat: scrii un nume de domeniu in fisierul de configurare, iar Caddy obtine un certificat gratuit de la Let’s Encrypt, il instaleaza, redirectioneaza HTTP catre HTTPS si il reinnoieste inainte sa expire. Fara cron job-uri, fara Certbot, fara fisiere de chei mutate de mana. La final vei avea domeniile indreptate catre VPS, doua aplicatii exemplu care ruleaza in spatele lui Caddy pe o retea Docker comuna, certificate valide pe amandoua si niciun port de aplicatie accesibil din internet.

Ce este un reverse proxy si de ce Caddy

Hai sa lamurim intai cativa termeni, pentru ca tot restul se bazeaza pe ei.

Un port este o “usa” numerotata a unui server. O masina are o singura adresa IP, dar mai multe programe pot asculta pe ea in acelasi timp, fiecare pe portul lui. Browserele folosesc implicit portul 80 pentru HTTP simplu si portul 443 pentru HTTPS, de aceea nu le scrii niciodata in adresa. Sesiunea ta SSH foloseste portul 22.

Un container este un pachet izolat care contine o aplicatie plus tot ce ii trebuie ca sa ruleze (biblioteci, runtime, configurare). Docker ruleaza containere, iar Docker Compose iti permite sa descrii unul sau mai multe containere intr-un fisier compose.yaml si sa le pornesti cu o singura comanda.

Un reverse proxy este un program asezat in fata aplicatiilor tale. Primeste toate cererile pe porturile 80 si 443, se uita la numele de domeniu cerut de vizitator (de exemplu status.example.com) si paseaza cererea aplicatiei corespunzatoare din spate. Vizitatorul vorbeste doar cu proxy-ul. Aplicatiile nu trebuie sa stea niciodata direct in internet.

TLS este criptarea din spatele HTTPS. Pentru el, un site are nevoie de un certificat, un fisier mic si semnat care dovedeste browserelor ca serverul chiar detine domeniul. Let’s Encrypt este o autoritate de certificare gratuita, non-profit, iar ACME este protocolul prin care programele cer si reinnoiesc automat certificate de la ea.

De ce Caddy si nu Nginx cu Certbot

Nginx e excelent si folosim mult. Dar pentru un VPS mic cu cateva aplicatii Docker, varianta clasica cu Nginx inseamna un server block pentru fiecare site, instalarea Certbot, rularea lui pentru fiecare domeniu, verificarea ca timer-ul de reinnoire functioneaza si reload la Nginx dupa fiecare reinnoire. Se poate, dar fiecare pas e o ocazie sa uiti ceva.

Cu Caddy, un reverse proxy complet cu HTTPS pentru un site inseamna trei randuri de configurare. Cererea de certificat, redirectul HTTP catre HTTPS, OCSP stapling, HTTP/2 si HTTP/3 sunt active implicit. WebSocket-urile, folosite de multe dashboard-uri moderne pentru actualizari live, trec prin proxy fara nicio directiva in plus. Pentru scenariul “vreau doar ca aplicatiile mele sa aiba HTTPS ca lumea”, simplitatea asta e exact ce conteaza.

Cum functioneaza HTTPS-ul automat

Cand Caddy porneste si gaseste un domeniu in configurare, contacteaza Let’s Encrypt si cere un certificat. Let’s Encrypt raspunde cu o provocare: “dovedeste ca tu controlezi domeniul”. Apoi se conecteaza la domeniul tau pe portul 80 (provocarea HTTP-01) sau 443 (provocarea TLS-ALPN-01) si verifica raspunsul. Caddy raspunde singur la provocare, certificatul e emis si salvat pe disc. De aceea doua lucruri sunt obligatorii: domeniul trebuie sa arate catre VPS-ul tau, iar porturile 80 si 443 trebuie sa fie accesibile din internet.

Caddy cere, valideaza, salveaza si reinnoieste certificatele singur. Treaba ta e doar un DNS corect si porturile 80 si 443 deschise.

Certificatele Let’s Encrypt sunt in prezent valabile 90 de zile, iar Caddy le reinnoieste cu aproximativ 30 de zile inainte de expirare. Industria merge spre certificate cu durata tot mai scurta, si exact de aceea conteaza automatizarea: o reinnoire facuta de mana e o reinnoire pe care o vei uita la un moment dat.

Arhitectura pe care o construim

Iata imaginea completa. Doar Caddy publica porturi catre internet. Fiecare aplicatie intra intr-o retea Docker comuna numita proxy, unde Caddy o gaseste dupa numele containerului. Certificatele stau intr-un volum Docker, ca sa supravietuiasca restarturilor si actualizarilor.

Configuratia tinta: o singura intrare publica (Caddy pe 80/443), aplicatii accesibile doar prin reteaua interna proxy, date pastrate in volume.

De ce ai nevoie

Un VPS cu Debian 13 sau Ubuntu 24.04, ideal KVM. Caddy e foarte mic, deci cel mai mic plan ajunge pentru proxy plus cateva aplicatii usoare.
Un utilizator cu drepturi sudo, conectat prin SSH.
Docker Engine cu pluginul Compose, instalat din repository-ul oficial Docker, dupa instructiunile de pe docs.docker.com/engine/install . Verifici cu docker compose version; ar trebui sa vezi ceva de genul Docker Compose version v2.x.
Utilizatorul tau in grupul docker (sudo usermod -aG docker $USER, apoi te deconectezi si te reconectezi), altfel pune sudo in fata comenzilor docker de mai jos.
Un nume de domeniu la care poti edita inregistrarile DNS.
Nimic altceva care sa asculte pe porturile 80 si 443, de exemplu un Apache sau Nginx preinstalat.

Inainte de toate, aduce sistemul la zi:

sudo apt update && sudo apt upgrade -y

Pe Ubuntu, daca dupa upgrade exista fisierul /var/run/reboot-required, s-a instalat un kernel nou sau o biblioteca de baza si e bine sa dai sudo reboot. Debian nu creeaza fisierul asta in mod sigur, asa ca pe Debian fa reboot pur si simplu daca upgrade-ul a instalat un pachet linux-image nou.

O nota pentru clientii cu LXC: Docker intr-un container LXC neprivilegiat are nevoie de nesting activat, iar ufw s-ar putea sa nu poata incarca modulele de kernel de care are nevoie. Daca Docker refuza sa porneasca sau ufw enable da erori, scrie echipei de suport sau foloseste un VPS KVM, care se comporta ca un server obisnuit pentru tot ce facem aici.

Iata procedura pe scurt. Fiecare numar corespunde unui titlu “Pasul” de mai jos.

Cei sapte pasi ai ghidului, identici cu Pasul 1 pana la Pasul 7 de mai jos: DNS-ul primul, verificarea la final.

Pasul 1: Indreapta domeniile catre VPS

Certificatele se pot emite doar pentru nume care deja arata catre serverul tau, deci DNS-ul vine primul. Gasesti IP-ul public al VPS-ului in panoul de client sau direct pe server:

ip -brief address

Cauta interfata cu adresa publica (de obicei eth0 sau ens3). In ghid folosim 203.0.113.10 ca IP de exemplu si example.com ca domeniu.

La furnizorul de DNS, creeaza cate o inregistrare A pentru fiecare subdomeniu de aplicatie, toate catre adresa IPv4 a VPS-ului:

hello -> 203.0.113.10
status -> 203.0.113.10

Adauga inregistrari AAAA (IPv6) doar daca VPS-ul are chiar o adresa IPv6 functionala. Let’s Encrypt prefera IPv6 cand exista o inregistrare AAAA, asa ca o inregistrare AAAA veche sau gresita e unul dintre cele mai dese motive pentru care emiterea certificatului esueaza.

Asteapta cateva minute, apoi verifica propagarea de pe VPS. Utilitarul dig e in acelasi pachet pe ambele distributii:

sudo apt install -y bind9-dnsutils
dig +short hello.example.com A
dig +short status.example.com A

Fiecare comanda trebuie sa afiseze exact IP-ul VPS-ului. Daca nu afiseaza nimic sau o adresa veche, mai asteapta inainte sa treci mai departe. Daca DNS-ul e la un furnizor cu functie de proxy (stilul “norisor portocaliu”), pune inregistrarile pe “DNS only” cat timp configurezi; poti reveni asupra lor mai tarziu.

Pasul 2: Deschide porturile 80 si 443 in firewall

Folosim ufw, o interfata prietenoasa pentru firewall-ul din Linux. Ubuntu 24.04 il are instalat, dar inactiv; Debian 13 nu il include, asa ca acolo trebuie instalat intai (comanda nu strica nimic pe Ubuntu):

sudo apt install -y ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 443/udp
sudo ufw enable
sudo ufw status verbose

Permite intotdeauna SSH (portul 22 sau portul tau SSH personalizat) inainte de ufw enable, altfel te blochezi singur pe dinafara. Portul 80 e necesar pentru provocarea HTTP-01 si pentru redirectul vizitatorilor catre HTTPS, 443/tcp transporta HTTPS, iar 443/udp e pentru HTTP/3. In output ar trebui sa vezi cele patru reguli ca ALLOW IN de la Anywhere.

Exista un comportament Docker pe care orice incepator trebuie sa-l stie: porturile publicate de Docker ocolesc ufw. Cand un container are ports: - "3001:3001", Docker scrie propriile reguli de firewall, evaluate inaintea celor din ufw, deci portul e deschis catre toata lumea chiar daca ufw spune altceva. Acesta e motivul principal pentru toata configuratia: doar Caddy publica porturi, iar aplicatiile nu publica niciunul.

Pasul 3: Creeaza reteaua Docker comuna

Containerele din aceeasi retea Docker definita de utilizator se pot gasi intre ele dupa nume, datorita DNS-ului intern al Docker. Cream o retea in care vor intra Caddy si toate aplicatiile:

docker network create proxy
docker network ls

Prima comanda afiseaza un ID lung de retea. A doua listeaza retelele, si ar trebui sa vezi proxy cu driverul bridge. O cream de mana, in afara oricarui fisier Compose, ca proiectele independente (proxy-ul, fiecare aplicatie) sa se poata conecta la ea fara sa depinda unul de altul.

Pasul 4: Scrie Caddyfile-ul

Caddyfile este fisierul de configurare al lui Caddy. Il tinem intr-un folder conf si montam tot folderul in container. Conteaza sa montezi folderul, nu fisierul singur: unele editoare salveaza inlocuind fisierul, iar o montare de fisier unic ar arata containerului in continuare versiunea veche.

mkdir -p ~/proxy/conf
cd ~/proxy
nano conf/Caddyfile

Lipeste continutul de mai jos, cu emailul si domeniile tale:

{
	email admin@example.com
}

hello.example.com {
	reverse_proxy hello-web:80
}

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

Ce face fiecare parte:

Blocul dintre acolade de la inceput contine optiunile globale. email e asociat contului tau ACME; Let’s Encrypt a renuntat in 2025 la emailurile de avertizare privind expirarea, dar adresa ramane utila pentru contul tau si pentru emitentul de rezerva pe care Caddy il poate folosi.
Fiecare bloc de site incepe cu un nume de domeniu. Doar numele asta declanseaza HTTPS-ul automat pentru el.
reverse_proxy hello-web:80 trimite traficul catre containerul numit hello-web, pe portul lui intern 80. Folosesti portul pe care asculta aplicatia in container, nu un port de pe host.

Prin conventie, indentarea in Caddyfile se face cu tab-uri. Salvezi cu Ctrl+O, Enter, iesi cu Ctrl+X.

Pasul 5: Porneste Caddy cu Docker Compose

Acum fisierul Compose pentru Caddy:

nano ~/proxy/compose.yaml

services:
  caddy:
    image: caddy:2.10
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./conf:/etc/caddy
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - proxy

volumes:
  caddy_data:
  caddy_config:

networks:
  proxy:
    external: true

Cateva alegeri explicate. Fixam caddy:2.10 ca actualizarile sa ramana in aceeasi versiune minora si sa nu se schimbe nimic fara stirea ta; verifica pe pagina oficiala a imaginii care e versiunea curenta si treci la una noua constient. caddy:2 ar urma automat orice versiune 2.x, comod dar mai putin previzibil, iar latest e cel mai putin previzibil dintre toate. Volumul caddy_data contine certificatele si cheile private si nu trebuie sters la intamplare. external: true ii spune lui Compose sa foloseasca reteaua proxy creata la Pasul 3, in loc sa faca una noua.

Porneste-l si urmareste log-urile:

cd ~/proxy
docker compose up -d
docker compose ps
docker compose logs -f caddy

docker compose ps trebuie sa arate containerul caddy ca running. In log-uri, in cateva secunde, ar trebui sa apara linii JSON cu "msg":"certificate obtained successfully" si "identifier":"hello.example.com", apoi la fel pentru status.example.com. Apasa Ctrl+C ca sa nu mai urmaresti log-urile; Caddy ramane pornit.

Aplicatiile inca nu exista, si e in regula. Caddy raspunde singur la provocarea ACME, deci primeste certificatele oricum; vizitatorii ar vedea doar un 502 Bad Gateway pana pornim aplicatiile.

Pasul 6: Conecteaza aplicatiile fara sa publici porturi

Fiecare aplicatie primeste folderul si fisierul Compose propriu, intra in reteaua proxy si nu are sectiune ports:. Setam explicit container_name, ca numele din Caddyfile sa fie stabil si sa nu se bata cap in cap cu servicii din alte proiecte.

Un site de test simplu cu Nginx:

mkdir -p ~/apps/hello && cd ~/apps/hello
nano compose.yaml

services:
  web:
    image: nginx:1.27-alpine
    container_name: hello-web
    restart: unless-stopped
    networks:
      - proxy

networks:
  proxy:
    external: true

docker compose up -d

Si o aplicatie reala, Uptime Kuma, un monitor de uptime self-hosted:

mkdir -p ~/apps/uptime-kuma && cd ~/apps/uptime-kuma
nano compose.yaml

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - kuma_data:/app/data
    networks:
      - proxy

volumes:
  kuma_data:

networks:
  proxy:
    external: true

docker compose up -d

Uptime Kuma isi actualizeaza dashboard-ul prin WebSocket, iar Caddy le trimite prin proxy din prima, fara configurare suplimentara.

Pentru aplicatiile care vin cu baza de date, tine baza de date in afara retelei proxy. Da stack-ului o retea privata proprie si conecteaza la proxy doar containerul web:

services:
  app:
    image: example/app:1.0
    container_name: myapp
    networks:
      - proxy
      - internal
  db:
    image: postgres:17
    networks:
      - internal

networks:
  proxy:
    external: true
  internal:

Asa, Caddy ajunge la myapp, dar nimic din afara stack-ului nu poate vorbi cu PostgreSQL. (Numele de imagini sunt orientative; o baza de date reala are nevoie si de variabile de mediu si de un volum.)

Cand adaugi urmatoarea aplicatie, bucla e mereu aceeasi: pornesti containerul in proxy, adaugi un bloc de site in ~/proxy/conf/Caddyfile, creezi inregistrarea DNS, apoi formatezi, validezi si reincarci Caddy fara downtime:

cd ~/proxy
docker compose exec -w /etc/caddy caddy caddy fmt --overwrite
docker compose exec -w /etc/caddy caddy caddy validate
docker compose exec -w /etc/caddy caddy caddy reload

fmt aranjeaza indentarea, validate trebuie sa se termine cu Valid configuration, iar reload aplica noua configurare elegant, pastrand conexiunile existente.

Pasul 7: Verifica HTTPS-ul si reinnoirea automata

De pe VPS sau de pe calculatorul tau, cere header-ele site-ului:

curl -I https://hello.example.com

Te astepti la HTTP/2 200, un header via: 1.1 Caddy care arata ca cererea a trecut prin proxy si un header alt-svc: h3=":443" care anunta HTTP/3. Apoi verifica redirectul automat:

curl -I http://hello.example.com

Ar trebui sa primesti HTTP/1.1 308 Permanent Redirect cu Location: https://hello.example.com/. Ca sa vezi cine a emis certificatul si cand expira:

echo | openssl s_client -connect hello.example.com:443 -servername hello.example.com 2>/dev/null | openssl x509 -noout -issuer -dates

Linia issuer trebuie sa contina O = Let's Encrypt cu un intermediar precum CN = R12 sau CN = E7, iar notAfter sa fie la aproximativ 90 de zile distanta.

La final, confirma ca niciun port de aplicatie nu e expus:

docker ps --format 'table {{.Names}}\t{{.Ports}}'

Doar caddy trebuie sa aiba mapari de porturi (0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp si asa mai departe). hello-web arata 80/tcp, iar uptime-kuma arata 3001/tcp, fara sageata, adica “deschis doar in interiorul Docker”. Pentru reinnoire nu faci nimic: Caddy verifica periodic certificatele si le reinnoieste in fundal, iar evenimentul apare in docker compose logs caddy.

Tipare utile in Caddyfile

Protejarea unui panou cu basic auth

Pentru unelte care nu au login propriu, Caddy poate adauga o cerere de parola. Genereaza un hash bcrypt (ti se cere parola de doua ori):

cd ~/proxy
docker compose exec caddy caddy hash-password

Apoi folosesti hash-ul in blocul de site:

tools.example.com {
	basic_auth {
		admin $2a$14$INLOCUIESTE_CU_HASH_UL_TAU
	}
	reverse_proxy tools-app:8080
}

Din Caddy 2.8 directiva se numeste basic_auth; vechiul basicauth inca merge, dar scrie un avertisment de depreciere in log.

Header-e de securitate si compresie cu un snippet

Snippet-urile iti permit sa definesti setarile o data si sa le importi in fiecare site:

(common) {
	encode zstd gzip
	header {
		Strict-Transport-Security "max-age=31536000"
		X-Content-Type-Options "nosniff"
		Referrer-Policy "strict-origin-when-cross-origin"
		-Server
	}
}

hello.example.com {
	import common
	reverse_proxy hello-web:80
}

Definitiile de snippet stau dupa blocul de optiuni globale. encode comprima raspunsurile, iar -Server elimina header-ul care anunta ce software ruleaza in spatele site-ului.

Redirect de la www la domeniul simplu

www.example.com {
	redir https://example.com{uri} permanent
}

Caddy obtine certificat si pentru www.example.com, deci redirectul merge pe HTTPS fara avertismente.

Aplicatii care au nevoie de IP-ul real al vizitatorului

Caddy trimite automat header-ele X-Forwarded-For, X-Forwarded-Proto si X-Forwarded-Host. Multe aplicatii le ignora pana le spui sa aiba incredere in proxy. Afli intervalul retelei cu docker network inspect proxy (cauta Subnet, de obicei ceva de genul 172.18.0.0/16) si il treci in setarea de “trusted proxies” a aplicatiei. Seteaza si URL-ul public al aplicatiei pe https://..., altfel poate genera linkuri http://.

Cat RAM consuma Caddy?

Foarte putin. Pe un VPS mic, reverse proxy-ul ar trebui sa fie partea cea mai ieftina din stack, iar Caddy se potriveste bine. Graficul de mai jos arata memoria aproximativa in repaus pentru variantele populare de reverse proxy care servesc cateva site-uri; valorile reale variaza dupa trafic, module si configurare.

Memorie aproximativa in repaus: Nginx singur e mai suplu, dar Caddy include automatizarea certificatelor; managerele de proxy cu interfata grafica costa vizibil mai mult.

Nginx simplu e mai usor, dar nu administreaza singur certificatele, deci adaugi Certbot peste el. Caddy iti da automatizarea asta intr-un singur binar mic.

Probleme frecvente si greseli de evitat

Certificatul nu se emite niciodata. Ruleaza docker compose logs caddy si citeste eroarea. Aproape mereu e una dintre: inregistrarea DNS nu arata inca spre VPS (verifica din nou cu dig), o inregistrare AAAA gresita, portul 80 sau 443 blocat de un firewall sau de proxy-ul furnizorului DNS, ori o greseala de scriere in domeniu. Cat timp experimentezi, adauga acme_ca https://acme-staging-v02.api.letsencrypt.org/directory in blocul de optiuni globale: certificatele de staging nu sunt acceptate de browsere, dar staging-ul are limite mult mai generoase. Scoate linia cand totul merge si fa reload.

“address already in use” la pornirea lui Caddy. Ceva de pe host asculta deja pe portul 80 sau 443. Il gasesti cu:

sudo ss -tlnp | grep -E ':(80|443)\s'

Daca e un Apache sau Nginx preinstalat de care nu ai nevoie, opreste-l si dezactiveaza-l, de exemplu sudo systemctl disable --now apache2.

502 Bad Gateway. Caddy merge, dar nu ajunge la aplicatie. Verifica daca containerul aplicatiei ruleaza, daca e conectat la reteaua proxy (docker network inspect proxy), daca numele din Caddyfile se potriveste cu container_name si daca ai folosit portul intern. Poti testa din interiorul lui Caddy:

docker compose exec caddy wget -qO- http://hello-web:80

Daca apare HTML, drumul prin retea e in regula si problema e in Caddyfile.

Modificarile din Caddyfile sunt ignorate. Caddy nu urmareste fisierul. Ruleaza comanda de reload de la Pasul 6 si asigura-te ca ai montat folderul conf, nu fisierul singur.

Erori de rate limit. Let’s Encrypt limiteaza validarile esuate si certificatele duplicate pe saptamana. Metoda clasica de a le atinge e sa stergi repetat volumul caddy_data in timp ce testezi, ceea ce forteaza certificate noi de fiecare data. Pastreaza volumul si foloseste CA-ul de staging pentru experimente.

Bucle de redirect in spatele unui CDN. Daca activezi mai tarziu proxy-ul unui furnizor DNS, seteaza modul SSL pe criptare completa cu validarea certificatului (de multe ori numit “Full (strict)”), nu pe un mod “flexible” care vorbeste HTTP simplu cu serverul tau.

Note de securitate

Nu publica niciodata porturile aplicatiilor. Tine minte ca Docker ocoleste ufw. Daca ai nevoie temporar de acces direct pentru depanare, leaga portul doar de localhost, de exemplu "127.0.0.1:8080:80", si foloseste un tunel SSH.
Grupul docker echivaleaza cu root. Oricine e in el poate controla host-ul, deci adauga doar conturi de administrator de incredere.
Nu expune API-ul de administrare al lui Caddy. El asculta pe localhost:2019 in interiorul containerului, de aceea functioneaza caddy reload. Nu publica niciodata portul 2019.
Protejeaza si fa backup la caddy_data. Contine cheile private ale certificatelor. Include volumul in backup-uri si restrange cine le poate citi.
Tine imaginile la zi. La cateva saptamani, ruleaza docker compose pull && docker compose up -d in fiecare folder de proiect, si citeste notele de versiune inainte sa schimbi o versiune minora fixata.
Atentie la HSTS. Odata ce browserele vad Strict-Transport-Security, refuza HTTP simplu pentru domeniul respectiv pe toata durata max-age. Incepe cu o valoare mica daca nu esti sigur ca toate subdomeniile vor ramane pe HTTPS.
Parole doar pe HTTPS. Basic auth trimite datele de autentificare la fiecare cerere; HTTPS-ul automat al lui Caddy face asta acceptabil, dar foloseste oricum parole lungi si unice.

Deci, e Caddy reverse proxy-ul potrivit pentru tine?

Daca rulezi cateva aplicatii self-hosted pe un VPS si vrei ca fiecare sa aiba domeniul ei cu HTTPS valid, Caddy e cam cel mai scurt drum: un Caddyfile scurt, un singur container, certificate care se reinnoiesc singure si un model de securitate curat, in care doar porturile 80 si 443 dau spre internet. Daca ai nevoie de load balancing foarte avansat sau echipa ta stie deja Nginx in profunzime, Nginx ramane o alegere foarte buna; daca preferi rutarea definita prin label-uri pe containere, uita-te la Traefik. Pentru majoritatea configuratiilor mici insa, Caddy e cel pe care il configurezi o data si apoi il uiti.

Poti urma ghidul pe un VPS de la noi in mai putin de o jumatate de ora, sau lasa echipa noastra de administrare servere sa-ti configureze Caddy, Docker, DNS-ul si aplicatiile, inclusiv backup-uri si actualizari.

Intrebari frecvente

Costa ceva Caddy sau Let’s Encrypt?

Nu. Caddy e open source sub licenta Apache 2.0, iar certificatele Let’s Encrypt sunt gratuite. Nici macar nu trebuie sa-ti faci cont manual; Caddy isi inregistreaza unul automat la prima pornire.

Poate Caddy sa faca proxy catre o aplicatie care ruleaza direct pe host, in afara Docker?

Da. Adauga extra_hosts: - "host.docker.internal:host-gateway" la serviciul Caddy si foloseste reverse_proxy host.docker.internal:8080. Aplicatia trebuie sa asculte pe o adresa accesibila din bridge-ul Docker (nu doar pe 127.0.0.1), si s-ar putea sa ai nevoie de o regula ufw care permite trafic din subnet-ul Docker catre portul respectiv.

Ce se intampla daca VPS-ul e oprit exact cand trebuie reinnoit certificatul?

Nimic dramatic. Caddy incepe reinnoirea cu circa 30 de zile inainte de expirare si tot reincearca, asa ca cateva ore sau chiar zile de indisponibilitate nu duc la un certificat expirat.

Pot obtine un certificat wildcard, de genul *.example.com?

Da, dar wildcard-urile necesita provocarea DNS, care cere o versiune de Caddy cu plugin pentru furnizorul tau de DNS. Construiesti o imagine proprie cu imaginea oficiala caddy:2.10-builder si xcaddy. Pentru cateva subdomenii cu nume fix, certificatele separate din ghid sunt mai simple.

Merge pe un VPS LXC?

De multe ori da, cu conditia ca nesting-ul sa fie activat pentru Docker. In containerele LXC neprivilegiate unele functii de firewall pot fi limitate, asa ca daca dai de erori, un VPS KVM e cea mai simpla cale sa urmezi tutorialul exact.