Pourquoi self-héberger une API Go sur un VPS
Contrairement à Java ou Node, une application Go (avec le framework Gin) se compile en un binaire statique unique qui n'a besoin ni d'interpréteur, ni de runtime, ni de bibliothèque partagée. Vous pouvez littéralement déposer le binaire sur un VPS et l'exécuter. Cette légèreté change tout pour le self-hosting : une API Gin tourne dans 15 à 30 Mo de RAM, encaisse des milliers de requêtes par seconde sur un seul cœur, et démarre en quelques millisecondes. Sur un VPS, vous exploitez à fond cette efficacité : un serveur d'entrée de gamme suffit à servir une charge que les langages interprétés exigeraient sur une machine bien plus grosse. Vous évitez aussi la complexité des images Docker volumineuses : une image scratch de 10 Mo suffit.
Bénéfices concrets
- Binaire statique unique : aucun runtime à installer, déploiement par simple copie de fichier
- Empreinte mémoire minuscule (15-30 Mo) permettant de saturer un petit VPS de requêtes
- Image Docker
scratchoudistrolessde 10-15 Mo : builds et pulls quasi instantanés - Démarrage en millisecondes : redéploiements et redémarrages sans interruption perceptible
- Concurrence native via les goroutines : un seul vCPU gère des milliers de connexions simultanées
- Surface d'attaque réduite : pas d'interpréteur ni de packages système à patcher
Prérequis matériels et logiciels
C'est là que Go brille : une API Gin sans base de données tient sur un VPS de 1 vCPU et 1 Go de RAM, et reste à l'aise. Avec PostgreSQL co-localisé, visez 2 Go pour être confortable. Vous n'avez même pas besoin de Go sur le serveur si vous compilez en CI ou en cross-compilation locale (GOOS=linux GOARCH=amd64 go build). Installez Docker si vous conteneurisez, ou rien du tout si vous lancez le binaire directement sous systemd. Pointez un domaine api.mondomaine.ma vers l'IP du VPS via un enregistrement A. 5 Go de disque suffisent largement.
Déploiement pas à pas
Cross-compiler le binaire pour Linux
Depuis votre poste, lancez CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app .. Le flag CGO_ENABLED=0 garantit un binaire 100 % statique, indispensable pour une image scratch. Vous obtenez un exécutable app prêt à tourner sur n'importe quel Linux.
Construire une image Docker minimale
Rédigez un Dockerfile multi-stage : un stage golang:1.22-alpine pour compiler, puis FROM scratch qui copie uniquement le binaire et les certificats CA (COPY --from=builder /etc/ssl/certs ...). L'image finale pèse une dizaine de Mo. Exposez le port 8080.
Configurer Gin pour la production
Passez Gin en mode release avec gin.SetMode(gin.ReleaseMode) ou la variable GIN_MODE=release pour désactiver les logs verbeux de debug. Lisez le port et les secrets depuis l'environnement (os.Getenv), jamais en dur dans le code.
Lancer le conteneur
Démarrez avec docker run -d --restart unless-stopped -p 127.0.0.1:8080:8080 -e GIN_MODE=release monapp:latest. En liant sur 127.0.0.1, vous n'exposez Gin qu'au reverse proxy local, pas à l'Internet directement.
Placer Nginx ou Caddy en frontal
Configurez un reverse proxy vers http://127.0.0.1:8080. Caddy est particulièrement adapté ici : avec une simple directive reverse_proxy localhost:8080, il provisionne automatiquement le certificat HTTPS sans Certbot.
Sécuriser avec TLS
Avec Caddy, le HTTPS est automatique dès que le domaine pointe vers le VPS. Avec Nginx, exécutez certbot --nginx -d api.mondomaine.ma. Vérifiez ensuite la chaîne TLS avec curl -I https://api.mondomaine.ma.
Activez le profiling pprof de Go derrière un endpoint protégé : import _ "net/http/pprof" exposé sur un port interne uniquement accessible en SSH tunnel. Vous obtenez des flame graphs CPU et mémoire en production réelle sans surcharge notable. Pensez aussi à compiler avec -ldflags="-s -w" pour réduire la taille du binaire de 30 % en supprimant les tables de debug.
