Self-hosting su un mini PC con Docker + Cloudflare Tunnel
Come esporre in sicurezza più servizi web da un solo mini PC di casa. HTTPS con Cloudflare Tunnel senza aprire porte, e tutto in esecuzione con Docker Compose.
In sintesi
Avvii i servizi sul mini PC con Docker Compose e con Cloudflare Tunnel (cloudflared) colleghi dominio e HTTPS senza aprire porte. Niente configurazione del router, niente IP statico, niente rinnovo dei certificati.
In questa pagina
Le bollette del cloud, per i piccoli progetti, pesano più di quanto sembri. Io faccio girare alcuni servizi, incluso questo blog, su un solo mini PC che ho a casa. Ecco come.
Perché un mini PC
- È sempre acceso e l'elettricità costa pochi euro al mese
- Con Docker l'ambiente di deploy è identico al cloud
- Se il traffico cresce, migri in quel momento
Il problema è uno solo: "come esporre in sicurezza la rete di casa verso l'esterno?"
Non aprire porte
Il metodo tradizionale è port forwarding sul router + DDNS + rinnovo dei certificati. È macchinoso e, di fatto, apre la tua rete domestica a internet: rischioso.
Al suo posto si usa Cloudflare Tunnel. Sul mini PC, cloudflared apre una connessione in uscita verso Cloudflare, e il traffico entra attraverso quel tunnel. Le porte inbound aperte verso l'esterno sono 0.
사용자 → Cloudflare(HTTPS) → 터널 → 미니 PC 의 컨테이너
- Niente IP pubblico né port forwarding
- I certificati HTTPS li gestisce Cloudflare in automatico
- L'IP dinamico non è un problema
Raggruppare i servizi con Docker Compose
Ogni servizio gira in un container. Per un'app Next.js, la si builda con output: "standalone" per ottenere un'immagine leggera.
services:
blog:
build:
context: .
dockerfile: apps/blog/Dockerfile
container_name: why-next-blog
restart: unless-stopped
networks: [api]
networks:
api:
external: true # cloudflared 와 같은 네트워크
Il punto chiave è metterlo nella stessa rete Docker di cloudflared. Solo così il tunnel raggiunge il servizio tramite il nome del container.
Collegare il dominio
Nella dashboard di Cloudflare (o nella configurazione del tunnel) si aggiunge un Public Hostname.
blog.example.com → http://why-next-blog:3001
E questo è tutto. Dopo un docker compose up -d --build, in pochi minuti il sito è raggiungibile dal dominio.
In sintesi
- Mini PC + Docker = deploy economico e identico al cloud
- Cloudflare Tunnel per HTTPS e dominio senza aprire porte
- Container nella stessa rete di cloudflared
- Public Hostname per mappare
dominio → container:porta
Per servizi piccoli, questa combinazione basta e avanza a lungo. Anch'io faccio girare così diverse app e continuo ad ampliare le cose che costruisco.
Domande frequenti
Il mio IP di casa è dinamico, va bene lo stesso?
Sì. Con Cloudflare Tunnel è il mini PC ad aprire una connessione in uscita verso Cloudflare, quindi non servono IP pubblico, port forwarding né DDNS.
Ci sono costi?
Cloudflare Tunnel in sé è gratuito. Basta il costo del dominio per iniziare.
Articoli correlati
- 💻 Sviluppo
Se un bucket ha due proprietari, vince l'ultimo che fa apply
Ho aggiunto una regola lifecycle a S3 e terraform apply è fallito. La causa: due risorse possedevano ciascuna la configurazione lifecycle dello stesso bucket. Il lifecycle di S3 non funziona per singola regola ma per documento intero, quindi l'ultimo vincitore cancella in silenzio le regole dell'altro.
- 💻 Sviluppo
I test erano verdi, ma le notifiche non erano mai partite
Il codice che accodava i job falliva sempre, fin dal primo giorno. L'errore veniva inghiottito e i test restavano verdi grazie ai mock. La storia di come un singolo due punti ha ucciso in silenzio tre funzionalità.
- 💻 Sviluppo
È arrivata la notifica che il DB era morto. Il DB non è mai morto
In una sola giornata si sono accumulati quattro alert CRITICAL. 504, Prisma P2028, un 500 sull'admin e 'servizio DATABASE down'. Ho aperto per prime le metriche RDS: per 21 ore filate la CPU era arrivata al massimo al 19.7%, tutto tranquillo. A essere lento non era il DB, ma un andirivieni che attraversava l'Atlantico venticinque volte, e l'alert di 'down' se l'era fabbricato da solo l'health check.