ADR-06, Hébergement (Postgres self-host via Dokploy)

Statut : Accepté Date : 2026-04 Sujet : Choix de l'infrastructure d'hébergement (app + base de données + monitoring)

Contexte

Reciprok a besoin de :

1. Héberger une app Bun (Elysia) + un frontend Next.js
2. Héberger une Postgres + pgvector avec backups
3. Héberger une stack d'observabilité (Grafana, Loki, Prometheus, GlitchTip, Uptime Kuma)
4. Héberger des workers (cron, embeddings, AI proactive)
5. Le tout pour ~5 utilisateurs internes au démarrage, avec une croissance prévisible

Alternatives considérées

Option 1, Neon (Postgres managé) + Vercel (app) + Sentry SaaS

L'option "tout managé" classique d'un projet TypeScript moderne.

Pour :

• Zero ops : pas de serveur à gérer
• Branching DB par PR (Neon)
• Auto-scaling

Contre :

• Coût qui dérive vite : Vercel facture le bandwidth et les fonctions edge, Neon facture le compute, Sentry facture par event
• Lock-in fort : chaque service a sa logique propre, son tooling, ses limitations
• Latence cumulée : Vercel (US) → Neon (EU) → Anthropic → frontend = chaque hop ajoute 50-200ms
• Pas de contrôle sur les versions de Postgres, les extensions, les paramètres de tuning
• Migration vers le self-host plus tard = complexe : il faut tout réécrire
• L'infra Hostinger + Dokploy existe déjà et tourne d'autres projets HaloAgency. Coût marginal proche de 0.

Option 2, Supabase (Postgres + auth + storage)

Pour :

• pgvector inclus
• Pas mal de features intégrées (auth, storage, realtime)

Contre :

• On utilise déjà Better Auth (ADR à venir si besoin) et Cloudflare R2, les features intégrées sont des doublons
• Coût qui monte à mesure que la base grossit
• Lock-in sur leur SDK (acceptable mais on préfère du Postgres standard)

Option 3, AWS RDS + ECS / EKS

Pour :

• Industrial grade
• Toutes les features

Contre :

• Sur-dimensionné pour 5 utilisateurs
• Coût minimum non négligeable (~80€/mois rien que pour RDS Postgres minimal)
• Complexité de config IAM, VPC, security groups
• Besoin de compétences AWS dédiées

Option 4, Hostinger VPS + Dokploy (retenu)

L'infra interne existante de HaloAgency : un VPS Hostinger (Proxmox derrière), sur lequel tourne Dokploy pour orchestrer les containers Docker.

Pour :

• Infra existante : pas de nouveau setup, le VPS tourne déjà
• Dokploy = Heroku-like self-host : git push → build → deploy automatique. Beaucoup plus simple à opérer qu'un Kubernetes
• Postgres self-host via image officielle pgvector/pgvector:pg18, full control sur la version, les extensions, le tuning
• Coût marginal proche de zéro : on ajoute des services à un VPS existant, pas un nouveau serveur
• Tout au même endroit : app + DB + monitoring + workers tournent côte à côte, latence intra-réseau Docker ~0
• Pas de lock-in : tout est du Docker standard, on peut migrer vers n'importe quelle infra Docker
• Backups Postgres = pg_dump cron + upload R2 : simple, fiable, testable
• Cohérent avec le standard interne (cf. CLAUDE.md de l'équipe, l'infra Halo est rodée)

Contre :

• Pas de branching DB par PR comme Neon, on s'en passe (preprod avec data anonymisée, c'est suffisant pour notre flow)
• Pas d'auto-scaling, non pertinent pour 5 utilisateurs internes
• Backups, monitoring, upgrades à notre charge, accepté, c'est documenté dans operations/environments et operations/monitoring
• Single point of failure si le VPS tombe, accepté au démarrage, on monte un second VPS de réplication si le besoin arrive

Décision

Hostinger VPS + Dokploy comme infra d'hébergement unique, pour tous les environnements (preprod, prod, training).

Stack :

• Postgres : container pgvector/pgvector:pg18 géré par Dokploy
• App Elysia + workers : containers Bun
• Frontend Next.js : container Node ou Bun
• Monitoring : containers Grafana / Loki / Prometheus / GlitchTip / Uptime Kuma
• Reverse proxy : Traefik (intégré à Dokploy)
• Backups : cron quotidien pg_dump → Cloudflare R2 (rétention décrite dans operations/environments)

Conséquences

Positives :

• Coût incroyablement bas : ~12-20€/mois de VPS pour tout l'environnement
• Pas de vendor lock-in
• Latence intra-services minimale
• Cohérence opérationnelle avec le reste des projets HaloAgency
• Migration future vers une infra plus grande (Hetzner, OVH, AWS) = trivial parce que tout est en Docker

Négatives :

• Si le VPS tombe, l'app est down (acceptable au démarrage)
• Backups DB à valider régulièrement (test de restauration mensuel sur l'env preprod, documenté)
• Pas de zero-downtime deploy au démarrage (acceptable, ~30s de coupure tolérables avec 5 utilisateurs internes)

Triggers de réévaluation

On revisitera cette décision si :

• L'app sert plus de 500 utilisateurs externes (organisateurs en self-service)
• On a un incident de perte de données lié à une mauvaise rotation de backups
• Le single point of failure devient inacceptable pour les SLA contractuels
• Les coûts d'opération (notre temps) dépassent les coûts d'un service managé

Dans ces cas : passage à un setup plus robuste (réplication Postgres, second VPS, ou migration vers un Postgres managé tier comme Crunchy Data ou Aiven, qui restent dans la philosophie self-host friendly).

Voir aussi

• Environnements, détail des 4 envs sur Dokploy
• Monitoring & observabilité, la stack auto-hébergée
• Coûts opérationnels, budget total
• ADR-01, Postgres + pgvector