Auto-hébergement sur mini PC avec Docker + Cloudflare Tunnel
Comment exposer plusieurs services web en toute sécurité avec un seul mini PC à la maison. HTTPS via Cloudflare Tunnel sans ouvrir de port, et tout tourne avec Docker Compose.
L'essentiel
Lancez vos services avec Docker Compose sur un mini PC, puis branchez domaine et HTTPS via Cloudflare Tunnel (cloudflared) sans ouvrir le moindre port. Ni config du routeur, ni IP fixe, ni renouvellement de certificat.
Sur cette page
Les factures cloud pèsent plus qu'on ne le croit sur les petits projets. Moi, je fais tourner plusieurs services, y compris ce blog, sur un seul mini PC à la maison. Je partage la méthode.
Pourquoi un mini PC
- Toujours allumé, pour quelques euros d'électricité par mois
- Avec Docker, l'environnement de déploiement est identique au cloud
- Si le trafic explose, on migrera à ce moment-là
Il ne reste qu'un seul problème : « comment exposer son réseau domestique vers l'extérieur en toute sécurité ».
N'ouvrez pas de ports
La méthode traditionnelle : redirection de ports sur le routeur + DDNS + renouvellement de certificats. C'est fastidieux, et cela revient à ouvrir son réseau domestique directement sur Internet. Risqué.
À la place, on utilise Cloudflare Tunnel. Sur le mini PC, cloudflared ouvre une connexion sortante vers Cloudflare, et le trafic entre par ce tunnel. Nombre de ports entrants ouverts vers l'extérieur : 0.
사용자 → Cloudflare(HTTPS) → 터널 → 미니 PC 의 컨테이너
- Pas besoin d'IP publique ni de redirection de ports
- Cloudflare gère automatiquement les certificats HTTPS
- Une IP dynamique ne pose aucun problème
Regrouper les services avec Docker Compose
Chaque service tourne dans un conteneur. Pour une appli Next.js, on la construit avec output: "standalone" pour obtenir une image légère.
services:
blog:
build:
context: .
dockerfile: apps/blog/Dockerfile
container_name: why-next-blog
restart: unless-stopped
networks: [api]
networks:
api:
external: true # cloudflared 와 같은 네트워크
L'essentiel est de placer le conteneur sur le même réseau Docker que cloudflared. C'est ainsi que le tunnel retrouve le service par son nom de conteneur.
Brancher le domaine
Dans le tableau de bord Cloudflare (ou la config du tunnel), on ajoute un Public Hostname.
blog.example.com → http://why-next-blog:3001
Et c'est tout. Un docker compose up -d --build, et quelques minutes plus tard le site s'ouvre sur votre domaine.
En résumé
- Mini PC + Docker = déploiement bon marché, identique au cloud
- Cloudflare Tunnel pour HTTPS et domaine sans ouvrir de port
- Placer les conteneurs sur le même réseau que cloudflared
- Un Public Hostname pour mapper
domaine → conteneur:port
Pour de petits services, cette combinaison tient largement la route. C'est comme ça que je fais tourner plusieurs applis et que j'agrandis la liste de mes créations.
Questions fréquentes
Mon IP domestique est dynamique, c'est un problème ?
Aucun. Avec Cloudflare Tunnel, c'est le mini PC qui ouvre une connexion sortante vers Cloudflare, donc IP publique, redirection de ports et DDNS sont totalement inutiles.
Est-ce que ça coûte quelque chose ?
Cloudflare Tunnel est gratuit en soi. Il suffit du coût d'un nom de domaine pour commencer.
Articles similaires
- 💻 Dev
Quand un bucket a deux propriétaires, c'est le dernier apply qui gagne
J'ai ajouté une règle de lifecycle S3 et terraform apply a échoué. La cause : une structure où deux ressources possédaient chacune la configuration lifecycle du même bucket. Le lifecycle S3 ne fonctionne pas à la règle près mais au document entier, et le dernier vainqueur efface silencieusement les règles de l'autre.
- 💻 Dev
Les tests étaient verts, mais aucune notification n'était jamais partie
Le code qui poussait des jobs dans la queue échouait à chaque fois depuis le premier jour. L'erreur était avalée, et les tests restaient verts grâce au mock. L'histoire d'un deux-points qui a tué trois fonctionnalités en silence.
- 💻 Dev
Une alerte disait que la base était morte. La base n'est jamais morte
En une journée, quatre alertes CRITICAL se sont empilées. Un 504, un Prisma P2028, un 500 sur l'admin, et « service DATABASE down ». J'ai d'abord ouvert les métriques RDS : 21 heures durant, le CPU a plafonné à 19,7 %, la base allait très bien. Ce qui était lent, ce n'était pas la base, c'était un aller-retour qui traversait l'Atlantique vingt-cinq fois. Quant à l'alerte « down », c'est le health check qui se l'était infligée à lui-même.