La stack de NameOcean : Python, Django, Redis et Proxmox

En bref : NameOcean est une application Python et Django. PostgreSQL stocke les données, Redis sert de cache, les tâches en arrière-plan tournent sur deux systèmes de files d'attente (RQ sur Redis pour les tâches courtes, Dramatiq sur RabbitMQ pour les traitements plus lourds), l'hébergement des clients repose sur des conteneurs LXC Proxmox installés sur nos propres serveurs, et vous pouvez tout gérer depuis le navigateur, un outil en ligne de commande écrit en Go ou votre assistant IA via MCP. Cet article passe en revue chaque couche et explique nos choix.

La stack en un coup d'œil

• Langage et framework : Python avec Django, servi par Gunicorn derrière Nginx.
• Base de données : PostgreSQL, avec des sauvegardes permettant une restauration à un instant précis (point-in-time recovery) vers un serveur de sauvegarde distinct.
• Cache : Redis, utilisé via django-redis et django-cacheops.
• Files d'attente : RQ (django-rq) sur Redis, ainsi que Dramatiq sur RabbitMQ.
• Hébergement : des hôtes Proxmox VE qui font tourner chaque serveur client dans un conteneur LXC.
• DNS : nos propres serveurs PowerDNS, de ns1 à ns4.
• Stockage objet : un stockage auto-hébergé compatible S3 pour les fichiers, les sauvegardes et les images du blog.
• Outils clients : la CLI nameocean (Go) et notre serveur MCP distant pour les clients IA, tous deux bâtis sur la même API publique.
• Déploiements : un git push et une seule commande Fabric. Personne ne modifie de code directement sur un serveur.

Vous voulez savoir comment un autre site est construit ? Notre Website Technology Checker gratuit affiche l'hébergeur, le CMS, le langage de programmation et le framework de n'importe quel domaine. Essayez-le sur nameocean.net.

Pourquoi Python et Django

Vu de l'extérieur, un registrar de domaines semble simple : on cherche un nom, on paie, on gère ses DNS. En coulisses, c'est une grande quantité de logique métier : API de registrars, transferts avec leurs propres machines à états, renouvellements, factures en plusieurs devises, émission de certificats SSL, zones DNS, boîtes mail et serveurs d'hébergement, le tout en 21 langues. Nous voulions une stack qui garde cette logique lisible et permette à une petite équipe de livrer en toute sécurité. Django nous offre exactement cela.

« Batteries incluses », et pour de vrai

Django fournit dès le premier jour les briques dont tout registrar a besoin :

• ORM et migrations. Nos modèles (domaines, zones, transferts, factures, serveurs) évoluent chaque semaine. Avec les migrations Django, chaque modification de schéma devient un fichier relu et versionné dans git, qui s'exécute de la même manière en local, dans les tests et en production.
• L'admin. Le support et les opérations travaillent dans l'admin Django. Nous n'avons pas eu à développer de back-office interne. Nous le personnalisons là où c'est important, par exemple pour les suppressions sécurisées et les actions de facturation.
• Authentification et sécurité. Sessions, protection CSRF, hachage des mots de passe et modèle utilisateur personnalisé basé sur l'adresse e-mail sont intégrés. Nous avons ajouté l'authentification à deux facteurs par-dessus.
• Internationalisation. Le site est traduit en 21 langues grâce aux outils gettext de Django et à des URL préfixées par la langue. L'anglais n'a pas de préfixe, les autres langues ont /tr/, /de/, etc.
• Sitemaps, cache, templates. Tout est standard et bien documenté.

Un seul langage, du site web jusqu'aux serveurs

Python ne se limite pas à l'application web. Le même langage fait tourner les workers des files d'attente, les commandes de gestion derrière nos tâches cron, les scripts qui dialoguent avec Proxmox, les outils DNS (dnspython) et nos scripts de déploiement (Fabric). Un ingénieur capable de lire la vue de paiement peut aussi lire le code qui crée un conteneur d'hébergement ou renouvelle un certificat. Pour une petite équipe, c'est plus important que la vitesse brute.

Les exceptions sont les outils qui tournent sur votre machine. Demander à chaque utilisateur d'installer Python et une série de paquets serait une mauvaise première expérience : la CLI est donc écrite en Go (nous y revenons plus bas). Ces outils ne contiennent aucune logique métier propre : tout passe par la même API Django.

Un écosystème mature

Presque tout ce que nous intégrons dispose d'une solide bibliothèque Python : Stripe pour les paiements, Django REST framework pour notre API publique, des clients S3 de type boto, l'API Proxmox, un reporting d'erreurs compatible Sentry. Notre serveur MCP distant, qui permet aux assistants IA de gérer les domaines et les DNS d'un client, fait lui aussi partie de l'application Django.

Ce à quoi nous renonçons, et comment nous le compensons

Python n'est pas le langage le plus rapide, et une requête Django synchrone ne doit pas attendre la réponse d'une API de registrar lente. Nous gérons cela de trois façons : les traitements lourds ou lents partent dans une file d'attente, les lectures fréquentes sont servies par Redis, et la base de données est optimisée et indexée pour nos schémas de requêtes. En pratique, le goulot d'étranglement est presque toujours une API externe, pas Python.

PostgreSQL : la source de vérité

Chaque domaine, zone, facture et serveur est stocké dans PostgreSQL. Nous l'avons choisi pour ses transactions strictes (l'argent et la propriété d'un domaine ne doivent jamais être écrits à moitié), ses types riches comme les champs JSON et les adresses réseau, et sa fiabilité en matière de sauvegarde. Les sauvegardes sont continues : le journal d'écriture anticipée (WAL) est envoyé vers un serveur de sauvegarde distinct, ce qui nous permet de restaurer la base à n'importe quel instant, et pas seulement au dump de la nuit précédente. Un serveur web de secours à chaud utilise la même base de données et peut prendre le relais si le serveur web principal tombe en panne.

Redis : le cache avant tout

Redis est notre cache. Les vérifications de disponibilité et de prix des domaines, les fragments de pages rendus et les limites de débit y sont stockés, de sorte qu'une requête répétée ne sollicite jamais l'API du registrar ni la base de données. Chaque clé de cache inclut la langue, car une même page diffère entre / et /tr/. Nous utilisons aussi django-cacheops pour mettre en cache les querysets de l'ORM et les invalider automatiquement lorsqu'une ligne change.

Redis s'est imposé facilement : il est rapide, simple à exploiter et très bien pris en charge par Django. Et puisqu'il est déjà en place, il sert aussi de socle à notre file d'attente légère.

Files d'attente : RQ sur Redis et Dramatiq sur RabbitMQ

Beaucoup d'actions lancées par un client ne doivent pas bloquer la page qu'il consulte. Enregistrer un domaine auprès du registre, émettre un certificat SSL, créer une adresse e-mail ou démarrer un conteneur d'hébergement prend des secondes, voire des minutes. Ces tâches sont placées dans une file d'attente, puis prises en charge par des workers. Nous utilisons deux systèmes de files d'attente, chacun pour ce qu'il fait le mieux.

RQ (django-rq) sur Redis

RQ est la file d'attente la plus simple de l'univers Python : une tâche est une fonction Python et ses arguments, stockés dans Redis. Nous l'utilisons pour les tâches quotidiennes du site :

• créer le compte du client chez le registrar après son inscription,
• émettre et renouveler les certificats SSL,
• synchroniser le statut des domaines et les zones DNS,
• ajouter des adresses e-mail et des règles de redirection,
• démarrer et arrêter les conteneurs d'hébergement, ouvrir des ports et configurer Nginx pour un serveur client,
• générer les factures et envoyer les rappels de renouvellement.

Un processus planificateur exécute les tâches périodiques, et le tableau de bord django-rq affiche les tâches en attente, en cours et en échec directement dans l'admin. En développement, la file fonctionne de manière synchrone : la tâche s'exécute immédiatement et ses erreurs apparaissent tout de suite.

Dramatiq sur RabbitMQ

Pour les traitements plus lourds et plus longs, nous utilisons Dramatiq avec RabbitMQ comme broker. RabbitMQ est un broker de messages dédié : un message n'est acquitté qu'une fois que le worker l'a entièrement traité, si bien qu'aucune tâche n'est perdue si un worker plante en cours de route. Dramatiq ajoute par-dessus des relances automatiques avec backoff exponentiel, des limites de temps, des priorités et des middlewares. C'est idéal pour les traitements en plusieurs étapes, les gros volumes ou les services externes qui échouent de temps à autre.

Pourquoi deux files d'attente ?

RQ garde les tâches simples… simples : pas de service supplémentaire, un débogage facile, et Redis tourne déjà. RabbitMQ et Dramatiq offrent des garanties de livraison plus fortes et un meilleur débit lorsqu'une tâche en a vraiment besoin. Choisir selon la charge de travail nous évite de payer le coût d'exploitation d'un broker complet pour une tâche de cinq secondes, sans pour autant confier un traitement critique à l'outil le plus rudimentaire.

Hébergement : Proxmox et conteneurs LXC

Nos offres d'hébergement et de vibe hosting tournent sur nos propres serveurs Proxmox VE. Chaque serveur client est un conteneur LXC, et non une machine virtuelle complète.

• Les conteneurs partagent le noyau de l'hôte : ils démarrent en quelques secondes et consomment bien moins de mémoire que des VM. Une plus grande part du matériel profite ainsi à l'application du client plutôt qu'à un second système d'exploitation.
• Chaque conteneur est isolé, avec son propre système de fichiers, ses processus, son réseau et ses limites de ressources en CPU, mémoire et disque.
• Tout est automatisé via l'API Proxmox. Lorsque vous commandez un serveur, Django envoie une tâche dans la file d'attente, et un worker crée le conteneur à partir d'un modèle, définit ses limites, le connecte au réseau, ouvre les ports et configure le reverse proxy ainsi que le SSL pour votre domaine.
• Redimensionnement, sauvegardes et restaurations sont de simples boutons dans le tableau de bord, qui appellent la même API. Les conteneurs peuvent aussi être déplacés d'un hôte Proxmox à un autre lorsque nous rééquilibrons la charge.

Exploiter notre propre matériel nous garantit des prix prévisibles et un contrôle total sur le réseau, les sauvegardes et l'emplacement des données.

DNS, e-mail et stockage

• DNS : les zones sont servies par nos propres serveurs PowerDNS (ns1 à ns4). Les modifications effectuées dans le panneau DNS sont écrites sur le serveur primaire puis propagées automatiquement aux secondaires. Le primaire est sauvegardé chaque nuit.
• E-mail : l'hébergement e-mail et la redirection d'e-mails gratuite fonctionnent sur nos propres serveurs de messagerie, avec SPF, DKIM et DMARC configurés pour votre domaine.
• Stockage objet : un stockage auto-hébergé compatible S3 conserve les fichiers envoyés, les sauvegardes et les images.

La CLI nameocean et le serveur MCP

Le tableau de bord web n'est pas la seule porte d'entrée. Tout ce qu'il fait passe par notre API REST publique et notre serveur MCP distant à l'adresse https://nameocean.net/mcp, et la CLI nameocean repose sur ces mêmes briques.

La CLI nameocean

nameocean est un binaire statique unique écrit en Go, compilé pour macOS, Linux et Windows, en amd64 comme en arm64. Nous avons choisi Go ici pour la raison inverse de celle qui nous a fait choisir Python côté serveur : une CLI doit s'installer en quelques secondes et fonctionner partout sans runtime, et Go produit un fichier unique qui fait exactement cela.

• Une seule connexion. nameocean login ouvre le navigateur et vous connecte via OAuth 2.1 avec PKCE. Les jetons sont stockés dans le trousseau du système d'exploitation (Trousseau macOS, Gestionnaire d'identifiants Windows ou libsecret sous Linux) et renouvelés automatiquement. Sur les serveurs et en CI, une clé d'API générée depuis le tableau de bord fait l'affaire.
• Serveurs et ports. nameocean servers ls, servers info pour les informations SSH et git, et ports open / ports close pour exposer un port de votre conteneur.
• Domaines sur les serveurs. nameocean bind example.com <server> configure le DNS, le SSL et le répartiteur de charge en une seule commande.
• DNS et SSL. dns ls, dns add et dns rm pour les enregistrements A, CNAME, MX, TXT et autres, ainsi que ssl status et ssl issue --wait.
• Domaines. domains ls et domains check pour la disponibilité et le prix. La CLI ne dépense jamais d'argent : les enregistrements et renouvellements restent dans le tableau de bord.
• Pensée pour les scripts et les agents IA. Chaque commande accepte --json et affiche le JSON de l'API tel quel, pour un usage direct avec jq, des scripts shell ou un agent.
• Une seule commande pour les clients IA. nameocean mcp install détecte Claude Code, Cursor et OpenCode sur votre machine et ajoute le serveur MCP de NameOcean à chacun d'eux.

nameocean login
nameocean dns add example.com A @ 203.0.113.10 --ttl 5m
nameocean bind example.com 3f9a1c2e
nameocean servers ls --json | jq '.servers[].default_domain'

Installez-la avec Homebrew (brew install nameocean/tap/nameocean) ou téléchargez l'archive correspondant à votre plateforme.

Le serveur MCP distant

Avec le vibe hosting, votre assistant IA dialogue directement avec NameOcean. Une seule commande suffit pour connecter Claude Code : claude mcp add --transport http nameocean https://nameocean.net/mcp. Vous vous connectez une fois dans le navigateur, puis vous pouvez lui demander de déployer, d'ouvrir un port ou de faire pointer un domaine vers votre serveur sans toucher à un seul fichier de configuration. Cursor, Claude Desktop, claude.ai et les autres clients MCP se connectent à la même URL ; la documentation MCP explique comment faire. Rien ne tourne sur votre machine : il n'y a donc rien à installer ni à mettre à jour.

Nous proposions auparavant une application de bureau pour cet usage. Elle lançait un serveur MCP local et se connectait avec un mot de passe, ce qui est incompatible avec la connexion en deux étapes ; comme le serveur distant fait le même travail sans installation, nous l'avons retirée en novembre 2026.

Pourquoi les deux ?

Chacun travaille à sa manière. La CLI s'adresse aux développeurs qui vivent dans un terminal et veulent des commandes scriptables et reproductibles. Le serveur MCP s'adresse à ceux qui préfèrent décrire ce qu'ils veulent et laisser leur assistant IA faire le reste. Comme ce sont deux fines couches au-dessus de la même API, toute fonctionnalité ajoutée à l'application Django est disponible simultanément dans le tableau de bord web, la CLI et tous les clients MCP.

Supervision et déploiements

Chaque erreur en production est remontée à un outil de suivi d'erreurs auto-hébergé compatible Sentry. Des sondes de disponibilité surveillent chaque serveur web, et les métriques sont envoyées vers une base de données de séries temporelles. Les déploiements sont volontairement ennuyeux : nous poussons sur git, lançons une commande Fabric, et celle-ci met à jour chaque serveur web, installe les dépendances, exécute les migrations, collecte les fichiers statiques, compile les traductions et redémarre l'application. Si un serveur exécute du code obsolète, la solution est un nouveau déploiement, jamais une modification manuelle.

En résumé

• Python et Django pour une logique métier lisible, l'admin, l'i18n et un seul langage partout.
• PostgreSQL comme source unique de vérité, avec restauration à un instant précis.
• Redis comme cache, et comme backend de la file d'attente RQ.
• RQ pour les tâches d'arrière-plan simples, Dramatiq sur RabbitMQ pour les traitements lourds qui ne doivent jamais être perdus.
• Des conteneurs LXC Proxmox pour un hébergement rapide, isolé et abordable.
• La CLI nameocean (Go) et le serveur MCP distant, de fines couches au-dessus de la même API.

Curieux de savoir ce qui fait tourner un autre site ? Analysez-le avec notre Website Technology Checker. Prêt à construire le vôtre ? Trouvez un domaine et hébergez-le chez NameOcean.