Ton app créée avec l’IA est prête. Et le serveur ?

Ton app fonctionne en local. Tu peux créer un compte, cliquer partout et montrer une démo. Le passage en production commence quand il faut garantir que les bonnes personnes accèdent aux bonnes données, même quand une requête échoue.

Que le code vienne de Codex, de Grok ou de toi ne change pas les questions à poser au serveur. Qui peut l’administrer ? Où sont les secrets ? Comment revenir à la version précédente ? Voici une base de discussion pour un déploiement sur VPS, pas une certification de sécurité.

Exposer le site, pas toute la machine

Dans cet exemple, Caddy tourne sur l’hôte et reçoit le trafic web. L’app Docker n’est publiée que sur l’adresse locale du serveur. Elle écoute sur 0.0.0.0:3000 à l’intérieur du conteneur. L’image doit déjà fonctionner sans privilèges et sans écrire dans son système de fichiers, hors des emplacements prévus.

APP_IMAGE doit contenir la référence d’une image vérifiée, idéalement figée par digest. L’utilisateur 10001 doit correspondre à celui de ton image. Adapte les limites de mémoire après mesure. N’ajoute pas les secrets dans ce fichier ni dans l’image.

1services:
2  app:
3    image: ${APP_IMAGE:?Set a verified image reference}
4    user: "10001:10001"
5    restart: unless-stopped
6    ports:
7      - "127.0.0.1:3000:3000"
8    read_only: true
9    tmpfs:
10      - /tmp:size=64m,mode=1777
11    cap_drop:
12      - ALL
13    security_opt:
14      - no-new-privileges:true
15    pids_limit: 100
16    mem_limit: 512m
17    cpus: 1.0

Brancher le domaine et vérifier de l’extérieur

Remplace app.example.com par ton domaine et fais pointer son DNS vers le VPS. Pour le fonctionnement HTTPS standard de Caddy, les ports 80 et 443 doivent être accessibles et son dossier de données doit rester persistant. L’administration SSH reste limitée aux accès prévus.

1app.example.com {
2  reverse_proxy 127.0.0.1:3000
3}

Préparer la panne avant l’ouverture

Utilise une version corrigée de Docker et teste les ports depuis une autre machine. Sa documentation signale une limite d’isolation pour les ports locaux avant la version 28.0.0. Elle précise aussi que les ports publiés peuvent contourner les règles UFW. Le simple statut « pare-feu actif » ne suffit pas.

Avant d’ouvrir les inscriptions, vérifie les autorisations avec deux comptes distincts, les limites des endpoints publics et la restauration d’une sauvegarde hors serveur. Conserve l’image précédente et prépare le retour arrière des migrations. Docker et HTTPS ne corrigent pas une route qui laisse lire les données d’un autre compte.