Lo stack di NameOcean: Python, Django, Redis e Proxmox

In breve: NameOcean è un'applicazione Python e Django. PostgreSQL custodisce i dati, Redis fa da cache, le attività in background girano su due sistemi di code (RQ su Redis per i job brevi, Dramatiq su RabbitMQ per le pipeline più pesanti), l'hosting dei clienti gira in container LXC Proxmox sui nostri server e potete gestire tutto dal browser, da uno strumento a riga di comando scritto in Go o dal vostro assistente AI tramite MCP. In questo articolo esaminiamo ogni livello e spieghiamo perché lo abbiamo scelto.

Lo stack in sintesi

• Linguaggio e framework: Python con Django, servito da Gunicorn dietro Nginx.
• Database: PostgreSQL, con backup point-in-time recovery su un server di backup separato.
• Cache: Redis, utilizzato tramite django-redis e django-cacheops.
• Code: RQ (django-rq) su Redis, più Dramatiq su RabbitMQ.
• Hosting: host Proxmox VE che eseguono ogni server dei clienti come container LXC.
• DNS: i nostri server PowerDNS, da ns1 a ns4.
• Object storage: uno storage self-hosted compatibile S3 per file, backup e immagini del blog.
• Strumenti client: la CLI nameocean (Go) e il nostro server MCP remoto per i client AI, entrambi basati sulla stessa API pubblica.
• Deploy: git push più un singolo comando Fabric. Nessuno modifica il codice direttamente su un server.

Volete scoprire come è costruito un altro sito? Il nostro Website Technology Checker gratuito mostra il provider di hosting, il CMS, il linguaggio di programmazione e il framework di qualsiasi dominio. Provatelo su nameocean.net.

Perché Python e Django

Visto dall'esterno, un registrar di domini sembra semplice: si cerca un nome, si paga, si gestisce il DNS. Sotto la superficie, però, c'è moltissima logica di business. Ci sono le API dei registrar, i trasferimenti con le loro macchine a stati, i rinnovi, le fatture in diverse valute, l'emissione dei certificati SSL, le zone DNS, le caselle di posta e i server di hosting, il tutto in 21 lingue. Volevamo uno stack che mantenesse questa logica leggibile e permettesse a un team ridotto di rilasciare in sicurezza. Django ci offre proprio questo.

"Batterie incluse", davvero

Django fornisce fin dal primo giorno i componenti di cui ogni registrar ha bisogno:

• ORM e migrazioni. I nostri modelli (domini, zone, trasferimenti, fatture, server) cambiano ogni settimana. Con le migrazioni di Django ogni modifica allo schema diventa un file revisionato in git, che viene eseguito allo stesso modo in locale, nei test e in produzione.
• L'admin. Il lavoro di supporto e operativo si svolge nell'admin di Django. Non abbiamo dovuto costruire un back office interno. Lo personalizziamo dove serve, ad esempio per le eliminazioni sicure e le operazioni di fatturazione.
• Autenticazione e sicurezza. Sessioni, protezione CSRF, hashing delle password e un modello utente personalizzato basato sull'e-mail sono integrati. Noi vi abbiamo aggiunto l'autenticazione a due fattori.
• Internazionalizzazione. Il sito è tradotto in 21 lingue con gli strumenti gettext di Django e URL con prefisso di lingua. L'inglese non ha prefisso, le altre lingue usano /tr/, /de/ e così via.
• Sitemap, caching, template. Tutto standard, tutto ben documentato.

Un solo linguaggio, dal sito web ai server

Python non è soltanto l'applicazione web. Lo stesso linguaggio esegue i worker delle code, i comandi di gestione dietro i nostri cron job, gli script che dialogano con Proxmox, gli strumenti DNS (dnspython) e i nostri script di deploy (Fabric). Un ingegnere in grado di leggere la view del checkout sa leggere anche il codice che crea un container di hosting o rinnova un certificato. Per un team piccolo, questo conta più della velocità pura.

Le eccezioni sono gli strumenti che girano sulla vostra macchina. Chiedere a ogni utente di installare Python e una serie di pacchetti sarebbe un pessimo primo approccio, per questo la CLI è scritta in Go (ne parliamo più avanti). Questi strumenti non contengono logica di business propria: tutto passa per la stessa API Django.

Un ecosistema maturo

Quasi tutto ciò con cui ci integriamo ha una solida libreria Python: Stripe per i pagamenti, Django REST framework per la nostra API pubblica, client S3 in stile boto, l'API di Proxmox, la segnalazione degli errori compatibile con Sentry. Anche il nostro server MCP remoto, che consente agli assistenti AI di gestire domini e DNS per conto di un cliente, fa parte dell'applicazione Django.

A cosa rinunciamo e come lo gestiamo

Python non è il linguaggio più veloce, e una richiesta Django sincrona non dovrebbe restare in attesa di un'API di registrar lenta. Gestiamo la cosa in tre modi: il lavoro pesante o lento va in coda, le letture più frequenti arrivano da Redis e il database è ottimizzato e indicizzato per i nostri pattern di query. In pratica, il collo di bottiglia è quasi sempre un'API esterna, non Python.

PostgreSQL: la fonte di verità

Ogni dominio, zona, fattura e server risiede in PostgreSQL. Lo abbiamo scelto per le transazioni rigorose (denaro e proprietà dei domini non devono mai essere scritti a metà), per i tipi avanzati come i campi JSON e gli indirizzi di rete, e per una strategia di backup affidabile. I backup sono continui: il write-ahead log viene inviato a un server di backup separato, così possiamo ripristinare il database in qualsiasi momento nel tempo, non solo al dump della notte precedente. Un web server in warm standby usa lo stesso database e può subentrare se il web server primario si guasta.

Redis: prima di tutto la cache

Redis è la nostra cache. Le verifiche di disponibilità e prezzo dei domini, i frammenti di pagina renderizzati e i rate limit risiedono tutti in Redis, così una richiesta ripetuta non tocca mai l'API del registrar né il database. Ogni chiave di cache include la lingua, perché la stessa pagina è diversa tra / e /tr/. Usiamo inoltre django-cacheops per mettere in cache i queryset dell'ORM e invalidarli automaticamente quando una riga cambia.

Redis è stata una scelta facile: è veloce, semplice da gestire e ha un ottimo supporto in Django. E dato che è già presente, fa anche da backend alla nostra coda di job leggera.

Code: RQ su Redis e Dramatiq su RabbitMQ

Molte operazioni avviate da un cliente non dovrebbero bloccare la pagina che sta guardando. Registrare un dominio presso il registry, emettere un certificato SSL, creare un indirizzo di posta o avviare un container di hosting richiedono secondi o minuti. Questi job finiscono in una coda e i worker li prendono in carico. Utilizziamo due sistemi di code, ciascuno per il lavoro in cui riesce meglio.

RQ (django-rq) su Redis

RQ è la coda più semplice del mondo Python: un job è una funzione Python con i suoi argomenti, salvata in Redis. La usiamo per le attività quotidiane del sito:

• creare l'account del cliente presso il registrar dopo la registrazione,
• emettere e rinnovare i certificati SSL,
• sincronizzare lo stato dei domini e le zone DNS,
• aggiungere indirizzi di posta e regole di inoltro,
• avviare e arrestare i container di hosting, aprire porte e configurare Nginx per il server di un cliente,
• creare le fatture e inviare i promemoria di rinnovo.

Un processo scheduler esegue i job periodici e la dashboard di django-rq mostra i job in coda, in esecuzione e falliti direttamente nell'admin. In sviluppo la coda funziona in modo sincrono, quindi un job viene eseguito inline e i suoi errori compaiono immediatamente.

Dramatiq su RabbitMQ

Per le pipeline più pesanti e lunghe usiamo Dramatiq con RabbitMQ come broker. RabbitMQ è un message broker dedicato: i messaggi vengono confermati solo dopo che un worker li ha completati, quindi un job non va perso se un worker si blocca a metà. Dramatiq aggiunge tentativi automatici con backoff esponenziale, limiti di tempo, priorità e middleware. È la soluzione ideale per carichi di lavoro con molti passaggi, volumi elevati o servizi esterni che ogni tanto falliscono.

Perché due code?

RQ mantiene semplici i job semplici: nessun servizio aggiuntivo, debug facile, e Redis è già in esecuzione. RabbitMQ e Dramatiq offrono garanzie di consegna più solide e un throughput migliore quando un job ne ha davvero bisogno. Scegliendo in base al carico di lavoro, non paghiamo il costo operativo di un message broker completo per un job di cinque secondi, né affidiamo una pipeline critica allo strumento più semplice.

Hosting: Proxmox e container LXC

I nostri piani di hosting e vibe hosting girano sui nostri server Proxmox VE. Ogni server dei clienti è un container LXC, non una macchina virtuale completa.

• I container condividono il kernel dell'host, quindi si avviano in pochi secondi e consumano molta meno memoria delle VM. Una parte maggiore dell'hardware va all'applicazione del cliente anziché a un secondo sistema operativo.
• Ogni container è isolato, con file system, processi, rete e limiti di risorse propri per CPU, memoria e disco.
• Tutto è automatizzato tramite l'API di Proxmox. Quando ordinate un server, Django invia un job alla coda e un worker crea il container da un template, ne imposta i limiti, collega la rete, apre le porte e configura il reverse proxy e l'SSL per il vostro dominio.
• Ridimensionamento, backup e ripristino sono pulsanti nella dashboard che richiamano la stessa API. I container possono anche essere spostati tra host Proxmox quando ribilanciamo il carico.

Gestire il nostro hardware significa prezzi prevedibili e pieno controllo su rete, backup e luogo in cui risiedono i dati.

DNS, e-mail e storage

• DNS: le zone sono servite dai nostri server PowerDNS (da ns1 a ns4). Le modifiche effettuate nel pannello DNS vengono scritte sul primario e propagate automaticamente ai secondari. Il primario viene sottoposto a backup ogni notte.
• E-mail: l'email hosting e l'inoltro email gratuito girano sui nostri mail server, con SPF, DKIM e DMARC configurati per il vostro dominio.
• Object storage: uno storage self-hosted compatibile S3 conserva file caricati, backup e immagini.

La CLI nameocean e il server MCP

La dashboard web non è l'unica via d'accesso. Tutto ciò che fa passa per la nostra API REST pubblica e per il nostro server MCP remoto all'indirizzo https://nameocean.net/mcp, e la CLI nameocean è costruita su di essi.

La CLI nameocean

nameocean è un singolo binario statico scritto in Go, compilato per macOS, Linux e Windows sia su amd64 sia su arm64. Qui abbiamo scelto Go per il motivo opposto per cui abbiamo scelto Python lato server: una CLI deve installarsi in pochi secondi e funzionare ovunque senza runtime, e Go compila in un unico file che fa esattamente questo.

• Accesso una sola volta. nameocean login apre il browser e vi autentica con OAuth 2.1 e PKCE. I token vengono salvati nel portachiavi del sistema operativo (Portachiavi di macOS, Gestione credenziali di Windows o libsecret su Linux) e aggiornati automaticamente. Sui server e in CI si può usare invece una chiave API generata dalla dashboard.
• Server e porte. nameocean servers ls, servers info per i dettagli SSH e git, e ports open / ports close per esporre una porta sul vostro container.
• Domini sui server. nameocean bind example.com <server> configura DNS, SSL e load balancer con un solo comando.
• DNS e SSL. dns ls, dns add e dns rm per record A, CNAME, MX, TXT e altri, oltre a ssl status e ssl issue --wait.
• Domini. domains ls e domains check per disponibilità e prezzi. La CLI non spende mai denaro: registrazioni e rinnovi restano nella dashboard.
• Pensata per script e agenti AI. Ogni comando accetta --json e stampa il JSON dell'API invariato, così può essere passato direttamente a jq, a script shell o a un agente.
• Un solo comando per i client AI. nameocean mcp install individua Claude Code, Cursor e OpenCode sulla vostra macchina e aggiunge a ciascuno il server MCP di NameOcean.

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'

Installatela con Homebrew (brew install nameocean/tap/nameocean) oppure scaricate l'archivio per la vostra piattaforma.

Il server MCP remoto

Con il vibe hosting, il vostro assistente AI comunica direttamente con NameOcean. Un solo comando collega Claude Code: claude mcp add --transport http nameocean https://nameocean.net/mcp. Accedete una volta nel browser e da quel momento potete chiedergli di effettuare un deploy, aprire una porta o puntare un dominio al vostro server senza toccare alcun file di configurazione. Cursor, Claude Desktop, claude.ai e altri client MCP si collegano allo stesso URL; la documentazione MCP spiega come. Sulla vostra macchina non gira nulla, quindi non c'è niente da installare o aggiornare.

In passato distribuivamo un'app desktop per questo scopo. Avviava un server MCP locale ed effettuava l'accesso con una password, cosa incompatibile con l'accesso in due passaggi; il server remoto svolge lo stesso compito senza installazione, per cui l'abbiamo dismessa a novembre 2026.

Perché entrambi?

Persone diverse lavorano in contesti diversi. La CLI è per gli sviluppatori che vivono nel terminale e vogliono comandi ripetibili e automatizzabili. Il server MCP è per chi preferisce descrivere ciò che desidera e lasciare il resto al proprio assistente AI. Poiché entrambi sono livelli sottili sopra la stessa API, una funzionalità aggiunta all'applicazione Django arriva contemporaneamente alla dashboard web, alla CLI e a ogni client MCP.

Monitoraggio e deploy

Ogni errore in produzione viene segnalato a un error tracker self-hosted compatibile con Sentry. I controlli di uptime sorvegliano ogni web server e le metriche confluiscono in un database di serie temporali. I deploy sono volutamente noiosi: facciamo push su git, eseguiamo un comando Fabric e questo aggiorna ogni web server, installa le dipendenze, esegue le migrazioni, raccoglie i file statici, compila le traduzioni e riavvia l'applicazione. Se un server ha codice non aggiornato, la soluzione è un altro deploy, mai una modifica manuale.

Riepilogo

• Python e Django per una logica di business leggibile, l'admin, l'i18n e un solo linguaggio ovunque.
• PostgreSQL come unica fonte di verità, con point-in-time recovery.
• Redis come cache e come backend della coda di job RQ.
• RQ per i job in background semplici, Dramatiq su RabbitMQ per le pipeline pesanti che non possono andare perse.
• Container LXC su Proxmox per un hosting veloce, isolato ed economico.
• La CLI nameocean (Go) e il server MCP remoto come livelli sottili sopra la stessa API.

Siete curiosi di sapere cosa alimenta un altro sito web? Analizzatelo con il nostro Website Technology Checker. Pronti a costruire il vostro? Trovate un dominio e ospitatelo su NameOcean hosting.