A stack da NameOcean: Python, Django, Redis e Proxmox

Resposta curta: a NameOcean é uma aplicação Python e Django. O PostgreSQL armazena os dados, o Redis serve de cache, o trabalho em segundo plano roda em dois sistemas de filas (RQ sobre Redis para tarefas curtas e Dramatiq sobre RabbitMQ para pipelines mais pesados), a hospedagem dos clientes roda em contêineres LXC no Proxmox em servidores próprios, e tudo pode ser gerenciado pelo navegador, por uma ferramenta de linha de comando escrita em Go ou pelo seu assistente de IA via MCP. Este artigo percorre cada camada e explica por que a escolhemos.

A stack em resumo

• Linguagem e framework: Python com Django, servido pelo Gunicorn atrás do Nginx.
• Banco de dados: PostgreSQL, com backups de recuperação para um ponto no tempo (point-in-time recovery) em um servidor de backup separado.
• Cache: Redis, usado por meio do django-redis e do django-cacheops.
• Filas: RQ (django-rq) sobre Redis, além de Dramatiq sobre RabbitMQ.
• Hospedagem: hosts Proxmox VE que executam cada servidor de cliente como um contêiner LXC.
• DNS: nossos próprios servidores PowerDNS, de ns1 a ns4.
• Armazenamento de objetos: um armazenamento auto-hospedado compatível com S3 para arquivos, backups e imagens do blog.
• Ferramentas para clientes: a CLI nameocean (Go) e nosso servidor MCP remoto para clientes de IA, ambos sobre a mesma API pública.
• Deploys: git push e um único comando Fabric. Ninguém edita código diretamente em um servidor.

Quer ver como qualquer outro site é construído? Nosso Website Technology Checker gratuito mostra o provedor de hospedagem, o CMS, a linguagem de programação e o framework de qualquer domínio. Experimente com nameocean.net.

Por que Python e Django

Visto de fora, um registrador de domínios parece simples: pesquisar um nome, pagar, gerenciar o DNS. Por baixo, há muita lógica de negócio. São APIs de registradores, transferências com suas próprias máquinas de estado, renovações, faturas em várias moedas, emissão de certificados SSL, zonas DNS, caixas de e-mail e servidores de hospedagem, tudo em 21 idiomas. Queríamos uma stack que mantivesse essa lógica legível e permitisse a uma equipe pequena entregar com segurança. O Django nos dá isso.

"Baterias incluídas" de verdade

O Django já traz as peças de que todo registrador precisa desde o primeiro dia:

• ORM e migrações. Nossos modelos (domínios, zonas, transferências, faturas, servidores) mudam toda semana. As migrações do Django transformam cada alteração de esquema em um arquivo revisado no git, que roda da mesma forma localmente, nos testes e em produção.
• O admin. O trabalho de suporte e operações acontece no admin do Django. Não precisamos construir um back office interno. Nós o personalizamos onde importa, como exclusões seguras e ações de faturamento.
• Autenticação e segurança. Sessões, proteção contra CSRF, hash de senhas e um modelo de usuário personalizado baseado em e-mail vêm de fábrica. Acrescentamos a autenticação de dois fatores por cima.
• Internacionalização. O site é traduzido para 21 idiomas com as ferramentas gettext do Django e URLs com prefixo de idioma. O inglês não precisa de prefixo; os demais recebem /tr/, /de/ e assim por diante.
• Sitemaps, cache, templates. Tudo padrão, tudo bem documentado.

Uma só linguagem, do site aos servidores

Python não é só o aplicativo web. A mesma linguagem executa os workers das filas, os comandos de gerenciamento por trás dos nossos cron jobs, os scripts que conversam com o Proxmox, as ferramentas de DNS (dnspython) e nossos scripts de deploy (Fabric). Um engenheiro que consegue ler a view do checkout também consegue ler o código que cria um contêiner de hospedagem ou renova um certificado. Para uma equipe pequena, isso importa mais do que a velocidade bruta.

As exceções são as ferramentas que rodam na sua máquina. Pedir a cada usuário que instale Python e um conjunto de pacotes seria uma péssima primeira impressão, então a CLI é escrita em Go (mais sobre ela abaixo). Ela não tem lógica de negócio própria: tudo passa pela mesma API do Django.

Um ecossistema maduro

Quase tudo com que nos integramos tem uma biblioteca Python sólida: Stripe para pagamentos, Django REST framework para a nossa API pública, clientes S3 no estilo boto, a API do Proxmox, relatórios de erros compatíveis com Sentry. Nosso servidor MCP remoto, que permite a assistentes de IA gerenciar domínios e DNS em nome de um cliente, também faz parte do aplicativo Django.

Do que abrimos mão e como lidamos com isso

Python não é a linguagem mais rápida, e uma requisição síncrona do Django não deve esperar por uma API de registrador lenta. Lidamos com isso de três formas: trabalho pesado ou lento vai para uma fila, leituras frequentes vêm do Redis, e o banco de dados é ajustado e indexado para os nossos padrões de consulta. Na prática, o gargalo quase sempre é uma API externa, não o Python.

PostgreSQL: a fonte da verdade

Cada domínio, zona, fatura e servidor vive no PostgreSQL. Escolhemos o PostgreSQL por suas transações rigorosas (dinheiro e titularidade de domínios nunca podem ficar gravados pela metade), por tipos ricos como campos JSON e endereços de rede, e por uma estratégia de backup confiável. Os backups são contínuos: o write-ahead log é enviado a um servidor de backup separado, o que nos permite restaurar o banco de dados em qualquer ponto no tempo, e não apenas no dump da noite anterior. Um servidor web em warm standby usa o mesmo banco de dados e pode assumir caso o servidor web principal falhe.

Redis: cache em primeiro lugar

O Redis é o nosso cache. Consultas de disponibilidade e preço de domínios, fragmentos de páginas renderizadas e limites de taxa ficam todos no Redis, de modo que uma requisição repetida nunca chega à API do registrador nem ao banco de dados. Cada chave de cache inclui o idioma, porque a mesma página é diferente entre / e /tr/. Também usamos o django-cacheops para armazenar em cache querysets do ORM e invalidá-los automaticamente quando uma linha muda.

O Redis foi uma escolha fácil: é rápido, simples de operar e tem excelente suporte no Django. Como ele já está lá, também serve de base para a nossa fila de tarefas leve.

Filas: RQ sobre Redis e Dramatiq sobre RabbitMQ

Muitas ações iniciadas pelo cliente não devem travar a página que ele está vendo. Registrar um domínio no registro, emitir um certificado SSL, criar um endereço de e-mail ou iniciar um contêiner de hospedagem levam segundos ou minutos. Essas tarefas vão para uma fila, e os workers as processam. Executamos dois sistemas de filas, cada um para o tipo de trabalho em que é melhor.

RQ (django-rq) sobre Redis

O RQ é a fila mais simples do mundo Python: uma tarefa é uma função Python e seus argumentos, armazenados no Redis. Nós o usamos para as tarefas do dia a dia do site:

• criar a conta do cliente no registrador após o cadastro,
• emitir e renovar certificados SSL,
• sincronizar o status dos domínios e as zonas DNS,
• adicionar endereços de e-mail e regras de encaminhamento,
• iniciar e parar contêineres de hospedagem, abrir portas e configurar o Nginx para o servidor de um cliente,
• gerar faturas e enviar lembretes de renovação.

Um processo agendador executa tarefas periódicas, e o painel do django-rq mostra as tarefas na fila, em execução e com falha diretamente no admin. Em desenvolvimento, a fila roda de forma síncrona, então a tarefa é executada na hora e seus erros aparecem imediatamente.

Dramatiq sobre RabbitMQ

Para pipelines mais pesados e longos, usamos o Dramatiq com o RabbitMQ como broker. O RabbitMQ é um message broker dedicado: as mensagens só são confirmadas depois que um worker termina de processá-las, então uma tarefa não se perde se um worker falhar no meio do caminho. O Dramatiq acrescenta novas tentativas automáticas com backoff exponencial, limites de tempo, prioridades e middleware. Isso se encaixa em cargas de trabalho com muitas etapas, alto volume ou serviços externos que falham de vez em quando.

Por que duas filas?

O RQ mantém simples o que é simples: nenhum serviço extra, depuração fácil, e o Redis já está rodando. O RabbitMQ e o Dramatiq oferecem garantias de entrega mais fortes e maior vazão quando uma tarefa realmente precisa disso. Escolher conforme a carga de trabalho significa que não pagamos o custo operacional de um message broker completo por uma tarefa de cinco segundos, nem confiamos um pipeline crítico à ferramenta mais simples.

Hospedagem: Proxmox e contêineres LXC

Nossos planos de hospedagem e vibe hosting rodam em nossos próprios servidores Proxmox VE. Cada servidor de cliente é um contêiner LXC, não uma máquina virtual completa.

• Os contêineres compartilham o kernel do host, então iniciam em segundos e usam muito menos memória do que VMs. Uma parte maior do hardware vai para a aplicação do cliente, em vez de um segundo sistema operacional.
• Cada contêiner é isolado, com seu próprio sistema de arquivos, processos, rede e limites de recursos para CPU, memória e disco.
• Tudo é automatizado pela API do Proxmox. Quando você contrata um servidor, o Django envia uma tarefa para a fila, e um worker cria o contêiner a partir de um template, define seus limites, conecta a rede, abre portas e configura o proxy reverso e o SSL para o seu domínio.
• Redimensionamento, backups e restaurações são botões no painel que chamam a mesma API. Os contêineres também podem ser movidos entre hosts Proxmox quando rebalanceamos a carga.

Ter nosso próprio hardware significa preços previsíveis e controle total sobre a rede, os backups e o local onde os dados ficam.

DNS, e-mail e armazenamento

• DNS: as zonas são servidas pelos nossos próprios servidores PowerDNS (ns1 a ns4). As alterações que você faz no painel de DNS são gravadas no primário e repassadas automaticamente aos secundários. O primário tem backup todas as noites.
• E-mail: a hospedagem de e-mail e o encaminhamento de e-mail gratuito rodam em nossos próprios servidores de e-mail, com SPF, DKIM e DMARC configurados para o seu domínio.
• Armazenamento de objetos: um armazenamento auto-hospedado compatível com S3 guarda arquivos enviados, backups e imagens.

A CLI nameocean e o servidor MCP

O painel web não é a única porta de entrada. Tudo o que ele faz passa pela nossa API REST pública e pelo nosso servidor MCP remoto em https://nameocean.net/mcp, e a CLI nameocean é construída sobre eles.

A CLI nameocean

A nameocean é um único binário estático escrito em Go, compilado para macOS, Linux e Windows, tanto em amd64 quanto em arm64. Escolhemos Go aqui pelo motivo oposto ao que nos levou ao Python no servidor: uma CLI precisa ser instalada em segundos e rodar em qualquer lugar sem runtime, e o Go compila para um único arquivo que faz exatamente isso.

• Faça login uma vez. nameocean login abre o navegador e autentica você com OAuth 2.1 e PKCE. Os tokens são armazenados no chaveiro do sistema operacional (Keychain do macOS, Gerenciador de Credenciais do Windows ou libsecret no Linux) e renovados automaticamente. Em servidores e em CI, uma chave de API do painel pode ser usada no lugar.
• Servidores e portas. nameocean servers ls, servers info para detalhes de SSH e git, e ports open / ports close para expor uma porta no seu contêiner.
• Domínios em servidores. nameocean bind example.com <server> configura DNS, SSL e o balanceador de carga com um só comando.
• DNS e SSL. dns ls, dns add e dns rm para registros A, CNAME, MX, TXT e outros, além de ssl status e ssl issue --wait.
• Domínios. domains ls e domains check para disponibilidade e preço. A CLI nunca gasta dinheiro: registros e renovações ficam no painel.
• Feita para scripts e agentes de IA. Todo comando aceita --json e imprime o JSON da API sem alterações, então a saída vai direto para o jq, scripts de shell ou um agente.
• Um comando para clientes de IA. nameocean mcp install localiza o Claude Code, o Cursor e o OpenCode na sua máquina e adiciona o servidor MCP da NameOcean a cada um deles.

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'

Instale com o Homebrew (brew install nameocean/tap/nameocean) ou baixe um arquivo para a sua plataforma.

O servidor MCP remoto

No vibe hosting, seu assistente de IA conversa diretamente com a NameOcean. Um único comando conecta o Claude Code: claude mcp add --transport http nameocean https://nameocean.net/mcp. Você faz login uma vez no navegador e, a partir daí, pode pedir que ele faça deploy, abra uma porta ou aponte um domínio para o seu servidor sem mexer em nenhum arquivo de configuração. O Cursor, o Claude Desktop, o claude.ai e outros clientes MCP se conectam à mesma URL; a documentação do MCP mostra como. Nada roda na sua máquina, então não há nada para instalar ou atualizar.

Antes, oferecíamos um aplicativo de desktop para isso. Ele iniciava um servidor MCP local e fazia login com senha, o que o login em duas etapas não permite, e o servidor remoto faz o mesmo trabalho sem instalação; por isso, o descontinuamos em novembro de 2026.

Por que os dois?

Pessoas diferentes trabalham em lugares diferentes. A CLI é para desenvolvedores que vivem no terminal e querem comandos repetíveis e automatizáveis. O servidor MCP é para quem prefere descrever o que deseja e deixar o assistente de IA fazer o resto. Como ambos são camadas finas sobre a mesma API, um recurso adicionado ao aplicativo Django chega ao mesmo tempo ao painel web, à CLI e a todos os clientes MCP.

Monitoramento e deploys

Todo erro em produção é reportado a um rastreador de erros auto-hospedado e compatível com Sentry. Verificações de disponibilidade monitoram cada servidor web, e as métricas vão para um banco de dados de séries temporais. Os deploys são entediantes de propósito: fazemos push para o git, executamos um comando Fabric, e ele atualiza todos os servidores web, instala as dependências, executa as migrações, coleta os arquivos estáticos, compila as traduções e reinicia o aplicativo. Se um servidor estiver com código desatualizado, a solução é outro deploy, nunca uma edição manual.

Resumo

• Python e Django para lógica de negócio legível, o admin, i18n e uma só linguagem em todo lugar.
• PostgreSQL como fonte única da verdade, com recuperação para um ponto no tempo.
• Redis como cache e como backend da fila de tarefas RQ.
• RQ para tarefas simples em segundo plano, Dramatiq sobre RabbitMQ para pipelines pesados que não podem se perder.
• Contêineres LXC no Proxmox para uma hospedagem rápida, isolada e acessível.
• A CLI nameocean (Go) e o servidor MCP remoto como camadas finas sobre a mesma API.

Curioso para saber o que move outro site? Analise-o com o nosso Website Technology Checker. Pronto para criar o seu? Encontre um domínio e coloque-o na hospedagem da NameOcean.