NameOcean Stack: Python, Django, Redis & Proxmox

Short answer: NameOcean is a Python and Django application. PostgreSQL holds the data, Redis is the cache, background work runs on two queue systems (RQ on Redis for short jobs, Dramatiq on RabbitMQ for heavier pipelines), customer hosting runs in Proxmox LXC containers on our own servers, and you can manage it all from the browser, a command line tool written in Go or a desktop app. This post walks through each layer and explains why we picked it.

The stack at a glance

• Language and framework: Python with Django, served by Gunicorn behind Nginx.
• Database: PostgreSQL, with point-in-time recovery backups to a separate backup server.
• Cache: Redis, used through django-redis and django-cacheops.
• Queues: RQ (django-rq) on Redis, plus Dramatiq on RabbitMQ.
• Hosting: Proxmox VE hosts that run every customer server as an LXC container.
• DNS: our own PowerDNS servers, ns1 to ns4.
• Object storage: a self-hosted, S3-compatible store for files, backups and blog images.
• Client tools: the nameocean CLI (Go) and the NameOcean desktop app (Electron), both on top of our public API and MCP server.
• Deploys: git push plus a single Fabric command. Nobody edits code on a server.

Want to see how any other site is built? Our free Website Technology Checker shows the hosting provider, CMS, programming language and framework of any domain. Try it on nameocean.net.

Why Python and Django

A domain registrar looks simple from the outside: search a name, pay, manage DNS. Underneath, it is a lot of business logic. There are registrar APIs, transfers with their own state machines, renewals, invoices in several currencies, SSL certificate issuance, DNS zones, mailboxes and hosting servers, all in 21 languages. We wanted a stack that keeps that logic readable and lets a small team ship safely. Django gives us that.

Batteries included, for real

Django ships the parts every registrar needs on day one:

• ORM and migrations. Our models (domains, zones, transfers, bills, servers) change every week. Django migrations make each schema change a reviewed file in git that runs the same way locally, in tests and in production.
• The admin. Support and operations work happens in the Django admin. We did not have to build an internal back office. We customise it where it matters, such as safe deletes and billing actions.
• Authentication and security. Sessions, CSRF protection, password hashing and a custom e-mail based user model are built in. We added two-factor authentication on top.
• Internationalisation. The site is translated into 21 languages with Django's gettext tooling and language-prefixed URLs. English needs no prefix, the others get /tr/, /de/ and so on.
• Sitemaps, caching, templates. All standard, all well documented.

One language from the website to the servers

Python is not only the web app. The same language runs the queue workers, the management commands behind our cron jobs, the scripts that talk to Proxmox, the DNS tooling (dnspython) and our deploy scripts (Fabric). An engineer who can read the checkout view can also read the code that creates a hosting container or renews a certificate. For a small team, that matters more than raw speed.

The exceptions are the tools that run on your machine. Asking every user to install Python and a set of packages would be a bad first experience, so the CLI is written in Go and the desktop app in JavaScript (more on both below). They hold no business logic of their own: everything goes through the same Django API.

A mature ecosystem

Nearly everything we integrate with has a solid Python library: Stripe for payments, Django REST framework for our public API, boto-style S3 clients, the Proxmox API, Sentry-compatible error reporting. Our remote MCP server, which lets AI assistants manage domains and DNS for a customer, is also part of the Django app.

What we give up, and how we deal with it

Python is not the fastest language, and a synchronous Django request should not wait on a slow registrar API. We handle that in three ways: heavy or slow work goes to a queue, hot reads come from Redis, and the database is tuned and indexed for our query patterns. In practice the bottleneck is almost always an external API, not Python.

PostgreSQL: the source of truth

Every domain, zone, invoice and server lives in PostgreSQL. We picked it for strict transactions (money and domain ownership must never be half-written), rich types such as JSON fields and network addresses, and a reliable backup story. Backups are continuous: the write-ahead log is shipped to a separate backup server, so we can restore the database to any point in time, not only to last night's dump. A warm standby web server uses the same database and can take over if the primary web server fails.

Redis: cache first

Redis is our cache. Domain availability and price lookups, rendered page fragments and rate limits all sit in Redis, so a repeated request never touches the registrar API or the database. Each cache key includes the language, because the same page differs between / and /tr/. We also use django-cacheops to cache ORM querysets and invalidate them automatically when a row changes.

Redis was an easy choice: it is fast, simple to run and has excellent Django support. Because it is already there, it also backs our lightweight job queue.

Queues: RQ on Redis and Dramatiq on RabbitMQ

Many things a customer starts should not block the page they are looking at. Registering a domain at the registry, issuing an SSL certificate, creating a mailbox address or starting a hosting container all take seconds or minutes. These jobs go to a queue, and workers pick them up. We run two queue systems, each for the work it is best at.

RQ (django-rq) on Redis

RQ is the simplest queue in the Python world: a job is a Python function and its arguments, stored in Redis. We use it for the website's day-to-day jobs:

• creating the customer's account at the registrar after sign-up,
• issuing and renewing SSL certificates,
• syncing domain status and DNS zones,
• adding mail addresses and forwarding rules,
• starting and stopping hosting containers, opening ports and configuring Nginx for a customer server,
• creating bills and sending renewal reminders.

A scheduler process runs periodic jobs, and the django-rq dashboard shows queued, running and failed jobs right inside the admin. In development, the queue runs synchronously, so a job runs inline and its errors show up immediately.

Dramatiq on RabbitMQ

For heavier and longer pipelines we use Dramatiq with RabbitMQ as the broker. RabbitMQ is a dedicated message broker: messages are acknowledged only after a worker finishes them, so a job is not lost if a worker crashes mid-way. Dramatiq adds automatic retries with exponential backoff, time limits, priorities and middleware on top. That fits workloads with many steps, high volume or external services that fail now and then.

Why two queues?

RQ keeps simple jobs simple: no extra service, easy debugging, and Redis is already running. RabbitMQ and Dramatiq give stronger delivery guarantees and better throughput when a job really needs them. Picking per workload means we do not pay the operational cost of a full message broker for a five-second job, and we do not trust a critical pipeline to the simplest tool.

Hosting: Proxmox and LXC containers

Our hosting and vibe hosting plans run on our own Proxmox VE servers. Every customer server is an LXC container, not a full virtual machine.

• Containers share the host kernel, so they start in seconds and use far less memory than VMs. More of the hardware goes to the customer's application instead of a second operating system.
• Each container is isolated, with its own file system, processes, network and resource limits for CPU, memory and disk.
• Everything is automated through the Proxmox API. When you order a server, Django sends a job to the queue, and a worker creates the container from a template, sets its limits, attaches the network, opens ports and configures the reverse proxy and SSL for your domain.
• Resizing, backups and restores are buttons in the dashboard that call the same API. Containers can also be moved between Proxmox hosts when we rebalance load.

Running our own hardware means predictable prices and full control over the network, the backups and where data lives.

DNS, e-mail and storage

• DNS: zones are served by our own PowerDNS servers (ns1 to ns4). Changes you make in the DNS panel are written to the primary and passed on to the secondaries automatically. The primary is backed up nightly.
• E-mail: email hosting and free email forwarding run on our own mail servers with SPF, DKIM and DMARC set up for your domain.
• Object storage: a self-hosted, S3-compatible store keeps uploaded files, backups and images.

The nameocean CLI and the desktop app

The web dashboard is not the only way in. Everything it does goes through our public REST API and our remote MCP server at https://nameocean.net/mcp, and we built two clients on top of them.

The nameocean CLI

nameocean is a single static binary written in Go, built for macOS, Linux and Windows on both amd64 and arm64. We picked Go here for the opposite reason we picked Python for the server: a CLI has to install in seconds and run anywhere with no runtime, and Go compiles to one file that does exactly that.

• Sign in once. nameocean login opens the browser and signs you in with OAuth 2.1 and PKCE. Tokens are stored in the operating system's keychain (macOS Keychain, Windows Credential Manager or libsecret on Linux) and refreshed automatically. On servers and in CI, an API key from the dashboard works instead.
• Servers and ports. nameocean servers ls, servers info for SSH and git details, and ports open / ports close to expose a port on your container.
• Domains on servers. nameocean bind example.com <server> sets up DNS, SSL and the load balancer in one command.
• DNS and SSL. dns ls, dns add and dns rm for A, CNAME, MX, TXT and other records, plus ssl status and ssl issue --wait.
• Domains. domains ls and domains check for availability and price. The CLI never spends money: registrations and renewals stay in the dashboard.
• Built for scripts and AI agents. Every command takes --json and prints the API's JSON unchanged, so it pipes straight into jq, shell scripts or an agent.
• One command for AI clients. nameocean mcp install finds Claude Code, Cursor and OpenCode on your machine and adds the NameOcean MCP server to each of them.

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'

The CLI is in its final stretch before release; it will be available through a Homebrew tap, a one-line install script and downloadable archives.

The NameOcean desktop app

The desktop app is built with Electron and runs on macOS (a universal build for Intel and Apple silicon), Windows and Linux (AppImage). It is aimed at vibe hosting: you sign in, see your servers and domains, and the app connects them to Claude Code through MCP automatically. From then on you can ask your AI assistant to deploy, open a port or point a domain at your server without touching a config file. You can download it from the hosting page.

Why both?

Different people work in different places. The CLI is for developers who live in a terminal and want scriptable, repeatable commands. The desktop app is for people who would rather click once and let their AI assistant do the rest. Because both are thin clients over the same API, a feature added to the Django app reaches the web dashboard, the CLI, the desktop app and every MCP client at once.

Monitoring and deploys

Every production error is reported to a self-hosted, Sentry-compatible error tracker. Uptime checks watch each web server, and metrics go to a time-series database. Deploys are boring on purpose: we push to git, run one Fabric command, and it updates every web server, installs requirements, runs migrations, collects static files, compiles translations and restarts the app. If a server has stale code, the fix is another deploy, never a manual edit.

Summary

• Python and Django for readable business logic, the admin, i18n and one language everywhere.
• PostgreSQL as the single source of truth, with point-in-time recovery.
• Redis as the cache, and as the backend of the RQ job queue.
• RQ for simple background jobs, Dramatiq on RabbitMQ for heavy, must-not-lose pipelines.
• Proxmox LXC containers for fast, isolated and affordable hosting.
• The nameocean CLI (Go) and the desktop app (Electron) as thin clients over the same API and MCP server.

Curious what powers another website? Run it through our Website Technology Checker. Ready to build your own? Find a domain and put it on NameOcean hosting.