El stack de NameOcean: Python, Django, Redis y Proxmox

Respuesta corta: NameOcean es una aplicación escrita en Python y Django. PostgreSQL guarda los datos, Redis hace de caché y las tareas en segundo plano se reparten entre dos sistemas de colas (RQ sobre Redis para los trabajos cortos y Dramatiq sobre RabbitMQ para los procesos más pesados). El hosting de los clientes se ejecuta en contenedores LXC de Proxmox en nuestros propios servidores, y usted puede gestionarlo todo desde el navegador, desde una herramienta de línea de comandos escrita en Go o a través de su asistente de IA mediante MCP. En este artículo repasamos cada capa y explicamos por qué la elegimos.

El stack de un vistazo

• Lenguaje y framework: Python con Django, servido por Gunicorn detrás de Nginx.
• Base de datos: PostgreSQL, con copias de seguridad con recuperación a un punto en el tiempo en un servidor de backup independiente.
• Caché: Redis, a través de django-redis y django-cacheops.
• Colas: RQ (django-rq) sobre Redis, además de Dramatiq sobre RabbitMQ.
• Hosting: hosts de Proxmox VE que ejecutan cada servidor de cliente como un contenedor LXC.
• DNS: nuestros propios servidores PowerDNS, de ns1 a ns4.
• Almacenamiento de objetos: un almacén autoalojado y compatible con S3 para archivos, copias de seguridad e imágenes del blog.
• Herramientas de cliente: la CLI nameocean (Go) y nuestro servidor MCP remoto para clientes de IA, ambos construidos sobre la misma API pública.
• Despliegues: git push y un único comando de Fabric. Nadie edita código directamente en un servidor.

¿Quiere saber cómo está construido cualquier otro sitio? Nuestro Website Technology Checker gratuito muestra el proveedor de hosting, el CMS, el lenguaje de programación y el framework de cualquier dominio. Pruébelo con nameocean.net.

Por qué Python y Django

Desde fuera, un registrador de dominios parece sencillo: se busca un nombre, se paga y se gestiona el DNS. Por debajo, sin embargo, hay muchísima lógica de negocio: APIs de registradores, transferencias con sus propias máquinas de estados, renovaciones, facturas en varias divisas, emisión de certificados SSL, zonas DNS, buzones de correo y servidores de hosting, todo ello en 21 idiomas. Queríamos un stack que mantuviera esa lógica legible y permitiera a un equipo pequeño publicar cambios con seguridad. Django nos da exactamente eso.

Con todo incluido, de verdad

Django trae de serie las piezas que cualquier registrador necesita desde el primer día:

• ORM y migraciones. Nuestros modelos (dominios, zonas, transferencias, facturas, servidores) cambian cada semana. Con las migraciones de Django, cada cambio de esquema es un archivo revisado en git que se ejecuta igual en local, en los tests y en producción.
• El admin. El trabajo de soporte y operaciones se hace en el admin de Django. No tuvimos que construir un back office interno. Lo personalizamos donde importa, por ejemplo en los borrados seguros y en las acciones de facturación.
• Autenticación y seguridad. Sesiones, protección CSRF, hash de contraseñas y un modelo de usuario personalizado basado en el correo electrónico vienen integrados. Encima añadimos la autenticación en dos pasos.
• Internacionalización. El sitio está traducido a 21 idiomas con las herramientas gettext de Django y URLs con prefijo de idioma. El inglés no lleva prefijo; los demás usan /tr/, /de/, etc.
• Sitemaps, caché, plantillas. Todo estándar y todo bien documentado.

Un solo lenguaje, de la web a los servidores

Python no se limita a la aplicación web. El mismo lenguaje ejecuta los workers de las colas, los comandos de gestión que hay detrás de nuestros cron jobs, los scripts que hablan con Proxmox, las herramientas de DNS (dnspython) y nuestros scripts de despliegue (Fabric). Un ingeniero que sabe leer la vista del checkout también puede leer el código que crea un contenedor de hosting o renueva un certificado. Para un equipo pequeño, eso importa más que la velocidad bruta.

Las excepciones son las herramientas que se ejecutan en su equipo. Pedir a cada usuario que instale Python y un montón de paquetes sería una mala primera impresión, así que la CLI está escrita en Go (hablaremos de ella más abajo). No contiene lógica de negocio propia: todo pasa por la misma API de Django.

Un ecosistema maduro

Casi todo aquello con lo que nos integramos tiene una buena librería para Python: Stripe para los pagos, Django REST framework para nuestra API pública, clientes S3 al estilo boto, la API de Proxmox y el reporte de errores compatible con Sentry. Nuestro servidor MCP remoto, que permite a los asistentes de IA gestionar dominios y DNS en nombre de un cliente, también forma parte de la aplicación Django.

A qué renunciamos y cómo lo resolvemos

Python no es el lenguaje más rápido, y una petición síncrona de Django no debería quedarse esperando a la API lenta de un registrador. Lo resolvemos de tres formas: el trabajo pesado o lento va a una cola, las lecturas más frecuentes salen de Redis y la base de datos está ajustada e indexada según nuestros patrones de consulta. En la práctica, el cuello de botella casi siempre es una API externa, no Python.

PostgreSQL: la fuente de verdad

Cada dominio, zona, factura y servidor vive en PostgreSQL. Lo elegimos por sus transacciones estrictas (el dinero y la titularidad de un dominio nunca pueden quedar a medio escribir), por sus tipos avanzados, como los campos JSON y las direcciones de red, y por su fiabilidad a la hora de hacer copias de seguridad. Las copias son continuas: el write-ahead log se envía a un servidor de backup independiente, de modo que podemos restaurar la base de datos a cualquier momento, no solo al volcado de anoche. Un servidor web en espera activa usa la misma base de datos y puede tomar el relevo si falla el servidor web principal.

Redis: primero, la caché

Redis es nuestra caché. Las consultas de disponibilidad y precio de dominios, los fragmentos de página renderizados y los límites de peticiones se guardan en Redis, de forma que una petición repetida nunca llega a la API del registrador ni a la base de datos. Cada clave de caché incluye el idioma, porque la misma página es distinta en / y en /tr/. También usamos django-cacheops para cachear querysets del ORM e invalidarlos automáticamente cuando cambia una fila.

Redis fue una elección fácil: es rápido, sencillo de operar y tiene un soporte excelente en Django. Y como ya lo teníamos, también sirve de base para nuestra cola de trabajos ligera.

Colas: RQ sobre Redis y Dramatiq sobre RabbitMQ

Muchas de las acciones que inicia un cliente no deberían bloquear la página que está viendo. Registrar un dominio en el registro, emitir un certificado SSL, crear una dirección de correo o arrancar un contenedor de hosting llevan segundos o minutos. Estos trabajos van a una cola y los workers los recogen. Usamos dos sistemas de colas, cada uno para lo que mejor sabe hacer.

RQ (django-rq) sobre Redis

RQ es la cola más sencilla del mundo Python: un trabajo es una función de Python con sus argumentos, almacenada en Redis. La usamos para el día a día del sitio web:

• crear la cuenta del cliente en el registrador tras el alta,
• emitir y renovar certificados SSL,
• sincronizar el estado de los dominios y las zonas DNS,
• añadir direcciones de correo y reglas de reenvío,
• arrancar y detener contenedores de hosting, abrir puertos y configurar Nginx para el servidor de un cliente,
• generar facturas y enviar recordatorios de renovación.

Un proceso planificador ejecuta los trabajos periódicos, y el panel de django-rq muestra los trabajos en cola, en ejecución y fallidos directamente dentro del admin. En desarrollo, la cola funciona de forma síncrona, así que cada trabajo se ejecuta en línea y sus errores aparecen al instante.

Dramatiq sobre RabbitMQ

Para los procesos más pesados y largos usamos Dramatiq con RabbitMQ como broker. RabbitMQ es un broker de mensajes dedicado: los mensajes solo se confirman cuando un worker los ha terminado, así que un trabajo no se pierde si un worker se cae a mitad. Dramatiq añade reintentos automáticos con backoff exponencial, límites de tiempo, prioridades y middleware. Encaja con cargas de trabajo de muchos pasos, gran volumen o servicios externos que fallan de vez en cuando.

¿Por qué dos colas?

RQ mantiene sencillos los trabajos sencillos: ningún servicio adicional, depuración fácil, y Redis ya está en marcha. RabbitMQ y Dramatiq ofrecen garantías de entrega más sólidas y mayor rendimiento cuando un trabajo de verdad lo necesita. Elegir según la carga de trabajo nos evita pagar el coste operativo de un broker de mensajes completo para un trabajo de cinco segundos, y también confiar un proceso crítico a la herramienta más simple.

Hosting: Proxmox y contenedores LXC

Nuestros planes de hosting y vibe hosting funcionan en nuestros propios servidores Proxmox VE. Cada servidor de cliente es un contenedor LXC, no una máquina virtual completa.

• Los contenedores comparten el kernel del host, por lo que arrancan en segundos y consumen mucha menos memoria que las máquinas virtuales. Una mayor parte del hardware se dedica a la aplicación del cliente en lugar de a un segundo sistema operativo.
• Cada contenedor está aislado, con su propio sistema de archivos, procesos, red y límites de recursos de CPU, memoria y disco.
• Todo está automatizado mediante la API de Proxmox. Cuando usted contrata un servidor, Django envía un trabajo a la cola y un worker crea el contenedor a partir de una plantilla, fija sus límites, conecta la red, abre los puertos y configura el proxy inverso y el SSL para su dominio.
• El redimensionado, las copias de seguridad y las restauraciones son botones del panel que llaman a esa misma API. Los contenedores también pueden moverse entre hosts de Proxmox cuando reequilibramos la carga.

Tener nuestro propio hardware significa precios previsibles y control total sobre la red, las copias de seguridad y la ubicación de los datos.

DNS, correo electrónico y almacenamiento

• DNS: las zonas se sirven desde nuestros propios servidores PowerDNS (de ns1 a ns4). Los cambios que haga en el panel DNS se escriben en el primario y se propagan automáticamente a los secundarios. El primario se respalda cada noche.
• Correo electrónico: el hosting de correo y el reenvío de correo gratuito funcionan en nuestros propios servidores de correo, con SPF, DKIM y DMARC configurados para su dominio.
• Almacenamiento de objetos: un almacén autoalojado y compatible con S3 guarda los archivos subidos, las copias de seguridad y las imágenes.

La CLI de nameocean y el servidor MCP

El panel web no es la única puerta de entrada. Todo lo que hace pasa por nuestra API REST pública y por nuestro servidor MCP remoto en https://nameocean.net/mcp, y la CLI nameocean está construida sobre ellos.

La CLI de nameocean

nameocean es un único binario estático escrito en Go, compilado para macOS, Linux y Windows en amd64 y arm64. Aquí elegimos Go por el motivo contrario por el que elegimos Python para el servidor: una CLI tiene que instalarse en segundos y funcionar en cualquier sitio sin runtime, y Go compila a un solo archivo que hace exactamente eso.

• Inicie sesión una sola vez. nameocean login abre el navegador e inicia sesión con OAuth 2.1 y PKCE. Los tokens se guardan en el llavero del sistema operativo (Llavero de macOS, Administrador de credenciales de Windows o libsecret en Linux) y se renuevan automáticamente. En servidores y en CI, puede usar en su lugar una clave de API del panel.
• Servidores y puertos. nameocean servers ls, servers info para los datos de SSH y git, y ports open / ports close para exponer un puerto en su contenedor.
• Dominios en servidores. nameocean bind example.com <server> configura el DNS, el SSL y el balanceador de carga con un solo comando.
• DNS y SSL. dns ls, dns add y dns rm para registros A, CNAME, MX, TXT y otros, además de ssl status y ssl issue --wait.
• Dominios. domains ls y domains check para consultar disponibilidad y precio. La CLI nunca gasta dinero: los registros y las renovaciones se quedan en el panel.
• Pensada para scripts y agentes de IA. Todos los comandos aceptan --json y devuelven el JSON de la API sin modificar, así que se pueden encadenar directamente con jq, scripts de shell o un agente.
• Un solo comando para los clientes de IA. nameocean mcp install detecta Claude Code, Cursor y OpenCode en su equipo y añade el servidor MCP de NameOcean a cada uno de ellos.

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'

Instálela con Homebrew (brew install nameocean/tap/nameocean) o descargue el archivo correspondiente a su plataforma.

El servidor MCP remoto

Con el vibe hosting, su asistente de IA habla directamente con NameOcean. Un solo comando conecta Claude Code: claude mcp add --transport http nameocean https://nameocean.net/mcp. Inicia sesión una vez en el navegador y, a partir de ahí, puede pedirle que despliegue, abra un puerto o apunte un dominio a su servidor sin tocar ningún archivo de configuración. Cursor, Claude Desktop, claude.ai y otros clientes MCP se conectan a la misma URL; la documentación de MCP explica cómo. No se ejecuta nada en su equipo, así que no hay nada que instalar ni actualizar.

Antes ofrecíamos una aplicación de escritorio para esto. Arrancaba un servidor MCP local e iniciaba sesión con contraseña, algo incompatible con el inicio de sesión en dos pasos, y el servidor remoto hace lo mismo sin instalar nada, así que la retiramos en noviembre de 2026.

¿Por qué ambos?

Cada persona trabaja a su manera. La CLI es para desarrolladores que viven en la terminal y quieren comandos reproducibles y automatizables. El servidor MCP es para quienes prefieren describir lo que quieren y dejar que su asistente de IA haga el resto. Como ambos son capas finas sobre la misma API, cualquier funcionalidad que se añade a la aplicación Django llega a la vez al panel web, a la CLI y a todos los clientes MCP.

Monitorización y despliegues

Cada error de producción se notifica a un sistema de seguimiento de errores autoalojado y compatible con Sentry. Las comprobaciones de disponibilidad vigilan cada servidor web y las métricas se envían a una base de datos de series temporales. Los despliegues son aburridos a propósito: hacemos push a git, ejecutamos un comando de Fabric y este actualiza todos los servidores web, instala las dependencias, ejecuta las migraciones, recopila los archivos estáticos, compila las traducciones y reinicia la aplicación. Si un servidor tiene código desactualizado, la solución es otro despliegue, nunca una edición manual.

Resumen

• Python y Django para una lógica de negocio legible, el admin, la i18n y un único lenguaje en todas partes.
• PostgreSQL como única fuente de verdad, con recuperación a un punto en el tiempo.
• Redis como caché y como backend de la cola de trabajos RQ.
• RQ para los trabajos sencillos en segundo plano, y Dramatiq sobre RabbitMQ para los procesos pesados que no se pueden perder.
• Contenedores LXC en Proxmox para un hosting rápido, aislado y asequible.
• La CLI de nameocean (Go) y el servidor MCP remoto como capas finas sobre la misma API.

¿Tiene curiosidad por saber qué hay detrás de otro sitio web? Analícelo con nuestro Website Technology Checker. ¿Listo para crear el suyo? Encuentre un dominio y alójelo en el hosting de NameOcean.