NameOceans teknologistak: Python, Django, Redis og Proxmox

Kort svar: NameOcean er en Python- og Django-applikation. PostgreSQL rummer data, Redis fungerer som cache, og baggrundsopgaver kører på to køsystemer (RQ på Redis til korte jobs, Dramatiq på RabbitMQ til tungere pipelines). Kundehosting kører i Proxmox LXC-containere på vores egne servere, og De kan styre det hele fra browseren, fra et kommandolinjeværktøj skrevet i Go eller fra Deres AI-assistent via MCP. I dette indlæg gennemgår vi hvert lag og forklarer, hvorfor vi valgte det.

Stakken i overblik

• Sprog og framework: Python med Django, serveret af Gunicorn bag Nginx.
• Database: PostgreSQL med point-in-time recovery-backup til en separat backupserver.
• Cache: Redis, brugt via django-redis og django-cacheops.
• Køer: RQ (django-rq) på Redis samt Dramatiq på RabbitMQ.
• Hosting: Proxmox VE-værter, der kører hver kundeserver som en LXC-container.
• DNS: vores egne PowerDNS-servere, ns1 til ns4.
• Objektlager: et selvhostet, S3-kompatibelt lager til filer, backups og blogbilleder.
• Klientværktøjer: nameocean-CLI'en (Go) og vores eksterne MCP-server til AI-klienter, begge bygget oven på det samme offentlige API.
• Udrulning: git push plus en enkelt Fabric-kommando. Ingen redigerer kode direkte på en server.

Vil De se, hvordan et andet website er bygget? Vores gratis Website Technology Checker viser hostingudbyder, CMS, programmeringssprog og framework for et vilkårligt domæne. Prøv den på nameocean.net.

Hvorfor Python og Django

Udefra ser en domæneregistrator simpel ud: søg efter et navn, betal, administrér DNS. Nedenunder ligger der en masse forretningslogik. Der er registrator-API'er, overførsler med deres egne tilstandsmaskiner, fornyelser, fakturaer i flere valutaer, udstedelse af SSL-certifikater, DNS-zoner, postkasser og hostingservere – alt sammen på 21 sprog. Vi ønskede en stak, der holder den logik læsbar og lader et lille team udgive sikkert. Det giver Django os.

Batterierne er reelt inkluderet

Django leverer de dele, som enhver registrator har brug for fra første dag:

• ORM og migreringer. Vores modeller (domæner, zoner, overførsler, regninger, servere) ændrer sig hver uge. Med Django-migreringer bliver hver skemaændring en gennemgået fil i git, der kører på samme måde lokalt, i test og i produktion.
• Admin-panelet. Support- og driftsarbejde foregår i Django admin. Vi har ikke skullet bygge et internt backoffice. Vi tilpasser det, hvor det betyder noget, fx sikre sletninger og faktureringshandlinger.
• Autentificering og sikkerhed. Sessioner, CSRF-beskyttelse, hashing af adgangskoder og en brugerdefineret, e-mailbaseret brugermodel er indbygget. Ovenpå har vi tilføjet totrinsgodkendelse.
• Internationalisering. Sitet er oversat til 21 sprog med Djangos gettext-værktøjer og URL'er med sprogpræfiks. Engelsk har intet præfiks, de øvrige får /tr/, /de/ og så videre.
• Sitemaps, caching, skabeloner. Alt sammen standard og veldokumenteret.

Ét sprog fra website til servere

Python er ikke kun webapplikationen. Det samme sprog driver køworkerne, de management-kommandoer der ligger bag vores cron-jobs, scripts der taler med Proxmox, DNS-værktøjerne (dnspython) og vores udrulningsscripts (Fabric). En udvikler, der kan læse checkout-viewet, kan også læse koden, der opretter en hostingcontainer eller fornyer et certifikat. For et lille team betyder det mere end rå hastighed.

Undtagelserne er de værktøjer, der kører på Deres maskine. At bede alle brugere om at installere Python og en række pakker ville være en dårlig første oplevelse, så CLI'en er skrevet i Go (mere om den nedenfor). Den har ingen egen forretningslogik: alt går gennem det samme Django-API.

Et modent økosystem

Næsten alt, vi integrerer med, har et solidt Python-bibliotek: Stripe til betalinger, Django REST framework til vores offentlige API, S3-klienter i boto-stil, Proxmox-API'et og Sentry-kompatibel fejlrapportering. Vores eksterne MCP-server, som lader AI-assistenter administrere domæner og DNS for en kunde, er også en del af Django-applikationen.

Hvad vi giver afkald på, og hvordan vi håndterer det

Python er ikke det hurtigste sprog, og en synkron Django-forespørgsel bør ikke vente på et langsomt registrator-API. Det håndterer vi på tre måder: tungt eller langsomt arbejde sendes til en kø, hyppige læsninger hentes fra Redis, og databasen er tunet og indekseret efter vores forespørgselsmønstre. I praksis er flaskehalsen næsten altid et eksternt API, ikke Python.

PostgreSQL: den autoritative datakilde

Hvert domæne, hver zone, faktura og server ligger i PostgreSQL. Vi valgte den for de strikse transaktioner (penge og domæneejerskab må aldrig blive halvt skrevet), rige datatyper som JSON-felter og netværksadresser samt en pålidelig backupløsning. Backup sker løbende: write-ahead-loggen sendes til en separat backupserver, så vi kan gendanne databasen til et hvilket som helst tidspunkt – ikke kun til nattens dump. En warm standby-webserver bruger den samme database og kan tage over, hvis den primære webserver svigter.

Redis: cache først

Redis er vores cache. Opslag på domænetilgængelighed og priser, renderede sidefragmenter og rate limits ligger alle i Redis, så en gentaget forespørgsel aldrig rører registrator-API'et eller databasen. Hver cachenøgle indeholder sproget, fordi den samme side er forskellig på / og /tr/. Vi bruger også django-cacheops til at cache ORM-querysets og invalidere dem automatisk, når en række ændres.

Redis var et let valg: den er hurtig, nem at drive og har fremragende Django-understøttelse. Og når den nu alligevel kører, bærer den også vores letvægts-jobkø.

Køer: RQ på Redis og Dramatiq på RabbitMQ

Mange af de ting, en kunde sætter i gang, bør ikke blokere den side, vedkommende kigger på. Registrering af et domæne hos registret, udstedelse af et SSL-certifikat, oprettelse af en mailadresse eller opstart af en hostingcontainer tager alle sekunder eller minutter. Disse jobs sendes til en kø, hvor workers tager dem op. Vi kører to køsystemer, hver til det arbejde, det er bedst til.

RQ (django-rq) på Redis

RQ er den enkleste kø i Python-verdenen: et job er en Python-funktion og dens argumenter, gemt i Redis. Vi bruger den til websitets daglige opgaver:

• oprettelse af kundens konto hos registratoren efter tilmelding,
• udstedelse og fornyelse af SSL-certifikater,
• synkronisering af domænestatus og DNS-zoner,
• tilføjelse af mailadresser og videresendelsesregler,
• start og stop af hostingcontainere, åbning af porte og konfiguration af Nginx for en kundeserver,
• oprettelse af regninger og afsendelse af påmindelser om fornyelse.

En scheduler-proces kører periodiske jobs, og django-rq-dashboardet viser køede, kørende og fejlede jobs direkte i admin-panelet. Under udvikling kører køen synkront, så et job afvikles inline, og fejl dukker op med det samme.

Dramatiq på RabbitMQ

Til tungere og længere pipelines bruger vi Dramatiq med RabbitMQ som broker. RabbitMQ er en dedikeret message broker: beskeder kvitteres først, når en worker er færdig med dem, så et job ikke går tabt, hvis en worker går ned midt i det. Dramatiq tilføjer automatiske genforsøg med eksponentiel backoff, tidsgrænser, prioriteter og middleware. Det passer til opgaver med mange trin, stor volumen eller eksterne tjenester, der fejler en gang imellem.

Hvorfor to køer?

RQ holder simple jobs simple: ingen ekstra tjeneste, nem fejlfinding, og Redis kører allerede. RabbitMQ og Dramatiq giver stærkere leveringsgarantier og bedre gennemløb, når et job virkelig har brug for det. Ved at vælge efter opgavetype betaler vi ikke driftsomkostningen for en fuld message broker for et job på fem sekunder, og vi overlader ikke en kritisk pipeline til det simpleste værktøj.

Hosting: Proxmox og LXC-containere

Vores hosting- og vibe hosting-planer kører på vores egne Proxmox VE-servere. Hver kundeserver er en LXC-container, ikke en fuld virtuel maskine.

• Containere deler værtens kerne, så de starter på sekunder og bruger langt mindre hukommelse end VM'er. Mere af hardwaren går til kundens applikation i stedet for et ekstra operativsystem.
• Hver container er isoleret med sit eget filsystem, egne processer, eget netværk og egne ressourcegrænser for CPU, hukommelse og disk.
• Alt er automatiseret via Proxmox-API'et. Når De bestiller en server, sender Django et job til køen, og en worker opretter containeren ud fra en skabelon, sætter dens grænser, tilknytter netværket, åbner porte og konfigurerer reverse proxy og SSL for Deres domæne.
• Opskalering, backup og gendannelse er knapper i dashboardet, der kalder det samme API. Containere kan også flyttes mellem Proxmox-værter, når vi omfordeler belastningen.

Når vi kører vores egen hardware, får vi forudsigelige priser og fuld kontrol over netværket, backups og hvor data ligger.

DNS, e-mail og lager

• DNS: zoner serveres af vores egne PowerDNS-servere (ns1 til ns4). Ændringer, De laver i DNS-panelet, skrives til den primære server og videregives automatisk til de sekundære. Den primære server tages der backup af hver nat.
• E-mail: e-mailhosting og gratis videresendelse af e-mail kører på vores egne mailservere med SPF, DKIM og DMARC sat op for Deres domæne.
• Objektlager: et selvhostet, S3-kompatibelt lager opbevarer uploadede filer, backups og billeder.

nameocean-CLI'en og MCP-serveren

Webdashboardet er ikke den eneste vej ind. Alt, hvad det gør, går gennem vores offentlige REST API og vores eksterne MCP-server på https://nameocean.net/mcp, og nameocean-CLI'en er bygget oven på dem.

nameocean-CLI'en

nameocean er én statisk binærfil skrevet i Go, bygget til macOS, Linux og Windows på både amd64 og arm64. Vi valgte Go her af den modsatte grund af den, vi valgte Python til serveren: en CLI skal kunne installeres på sekunder og køre overalt uden runtime, og Go kompilerer til én fil, der gør præcis det.

• Log ind én gang. nameocean login åbner browseren og logger Dem ind med OAuth 2.1 og PKCE. Tokens gemmes i operativsystemets nøglering (macOS Keychain, Windows Credential Manager eller libsecret på Linux) og fornyes automatisk. På servere og i CI kan De i stedet bruge en API-nøgle fra dashboardet.
• Servere og porte. nameocean servers ls, servers info til SSH- og git-oplysninger samt ports open / ports close til at eksponere en port på Deres container.
• Domæner på servere. nameocean bind example.com <server> sætter DNS, SSL og load balancer op med én kommando.
• DNS og SSL. dns ls, dns add og dns rm til A-, CNAME-, MX-, TXT- og andre records samt ssl status og ssl issue --wait.
• Domæner. domains ls og domains check til tilgængelighed og pris. CLI'en bruger aldrig penge: registreringer og fornyelser foregår i dashboardet.
• Bygget til scripts og AI-agenter. Alle kommandoer tager --json og udskriver API'ets JSON uændret, så det kan sendes direkte videre til jq, shell-scripts eller en agent.
• Én kommando til AI-klienter. nameocean mcp install finder Claude Code, Cursor og OpenCode på Deres maskine og tilføjer NameOcean-MCP-serveren til hver af dem.

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'

Installér den med Homebrew (brew install nameocean/tap/nameocean), eller download et arkiv til Deres platform.

Den eksterne MCP-server

Med vibe hosting taler Deres AI-assistent direkte med NameOcean. Én kommando forbinder Claude Code: claude mcp add --transport http nameocean https://nameocean.net/mcp. De logger ind én gang i browseren, og derefter kan De bede den om at udrulle, åbne en port eller pege et domæne mod Deres server uden at røre en konfigurationsfil. Cursor, Claude Desktop, claude.ai og andre MCP-klienter forbinder til den samme URL; MCP-dokumentationen viser hvordan. Intet kører på Deres maskine, så der er intet at installere eller opdatere.

Tidligere udgav vi en desktop-app til dette. Den startede en lokal MCP-server og loggede ind med en adgangskode, hvilket totrinsgodkendelse udelukker, og den eksterne server gør det samme uden installation. Derfor udfasede vi den i november 2026.

Hvorfor begge dele?

Folk arbejder forskellige steder. CLI'en er til udviklere, der lever i terminalen og ønsker scriptbare, gentagelige kommandoer. MCP-serveren er til dem, der hellere vil beskrive, hvad de ønsker, og lade deres AI-assistent klare resten. Da begge er tynde lag over det samme API, når en ny funktion i Django-applikationen ud til webdashboardet, CLI'en og alle MCP-klienter på én gang.

Overvågning og udrulning

Hver fejl i produktion rapporteres til en selvhostet, Sentry-kompatibel fejlsporer. Oppetidstjek overvåger hver webserver, og metrikker sendes til en tidsseriedatabase. Udrulninger er bevidst kedelige: vi pusher til git, kører én Fabric-kommando, og den opdaterer alle webservere, installerer afhængigheder, kører migreringer, samler statiske filer, kompilerer oversættelser og genstarter applikationen. Hvis en server har forældet kode, er løsningen endnu en udrulning – aldrig en manuel rettelse.

Opsummering

• Python og Django for læsbar forretningslogik, admin-panelet, i18n og ét sprog overalt.
• PostgreSQL som den eneste autoritative datakilde, med point-in-time recovery.
• Redis som cache og som backend for RQ-jobkøen.
• RQ til simple baggrundsjobs, Dramatiq på RabbitMQ til tunge pipelines, der ikke må gå tabt.
• Proxmox LXC-containere til hurtig, isoleret og prisvenlig hosting.
• nameocean-CLI'en (Go) og den eksterne MCP-server som tynde lag over det samme API.

Nysgerrig efter, hvad der driver et andet website? Kør det gennem vores Website Technology Checker. Klar til at bygge Deres eget? Find et domæne, og læg det på NameOcean hosting.