NameOcean-stacken: Python, Django, Redis og Proxmox

Kort fortalt: NameOcean er en Python- og Django-applikasjon. PostgreSQL lagrer dataene, og Redis fungerer som cache. Bakgrunnsarbeid kjøres på to køsystemer: RQ på Redis for korte jobber og Dramatiq på RabbitMQ for tyngre pipelines. Kundenes hosting kjører i Proxmox LXC-containere på våre egne servere, og alt kan administreres fra nettleseren, fra et kommandolinjeverktøy skrevet i Go eller fra AI-assistenten Deres via MCP. I dette innlegget går vi gjennom hvert lag og forklarer hvorfor vi valgte det.

Stacken i korte trekk

• Språk og rammeverk: Python med Django, servert av Gunicorn bak Nginx.
• Database: PostgreSQL, med sikkerhetskopier for gjenoppretting til et vilkårlig tidspunkt (point-in-time recovery) på en separat backupserver.
• Cache: Redis, brukt via django-redis og django-cacheops.
• Køer: RQ (django-rq) på Redis, samt Dramatiq på RabbitMQ.
• Hosting: Proxmox VE-verter som kjører hver kundeserver som en LXC-container.
• DNS: våre egne PowerDNS-servere, ns1 til ns4.
• Objektlagring: en egendriftet, S3-kompatibel lagringstjeneste for filer, sikkerhetskopier og bloggbilder.
• Klientverktøy: CLI-verktøyet nameocean (Go) og vår eksterne MCP-server for AI-klienter, begge bygget på det samme offentlige API-et.
• Utrulling: git push og én enkelt Fabric-kommando. Ingen redigerer kode direkte på en server.

Vil De se hvordan et annet nettsted er bygget? Med vår gratis Website Technology Checker ser De hostingleverandør, CMS, programmeringsspråk og rammeverk for et hvilket som helst domene. Prøv den på nameocean.net.

Hvorfor Python og Django

Utenfra ser en domeneregistrar enkel ut: søk etter et navn, betal, administrer DNS. Under overflaten skjuler det seg imidlertid mye forretningslogikk. Det handler om registrar-API-er, overføringer med egne tilstandsmaskiner, fornyelser, fakturaer i flere valutaer, utstedelse av SSL-sertifikater, DNS-soner, e-postkontoer og hostingservere, og alt dette på 21 språk. Vi ønsket en stack som holder denne logikken lesbar og lar et lite team levere trygt. Det gir Django oss.

«Batteries included» – på ordentlig

Django leveres med de delene enhver registrar trenger fra første dag:

• ORM og migreringer. Modellene våre (domener, soner, overføringer, fakturaer, servere) endres hver uke. Med Django-migreringer blir hver skjemaendring en gjennomgått fil i git som kjører likt lokalt, i tester og i produksjon.
• Admin-grensesnittet. Support- og driftsarbeid foregår i Django-admin. Vi har ikke måttet bygge et eget internt backoffice, og vi tilpasser det der det betyr noe, for eksempel ved sikre slettinger og faktureringshandlinger.
• Autentisering og sikkerhet. Sesjoner, CSRF-beskyttelse, passordhashing og en egendefinert brukermodell basert på e-postadresse er innebygd. Oppå dette har vi lagt totrinnsautentisering.
• Internasjonalisering. Nettstedet er oversatt til 21 språk med Djangos gettext-verktøy og URL-er med språkprefiks. Engelsk trenger ikke prefiks, mens de andre får /tr/, /de/ og så videre.
• Sitemaps, caching og maler. Alt er standard, og alt er godt dokumentert.

Ett språk fra nettstedet til serverne

Python brukes ikke bare i webapplikasjonen. Det samme språket driver køarbeiderne, management-kommandoene bak cron-jobbene våre, skriptene som kommuniserer med Proxmox, DNS-verktøyene (dnspython) og utrullingsskriptene (Fabric). En utvikler som kan lese koden for kassen, kan også lese koden som oppretter en hostingcontainer eller fornyer et sertifikat. For et lite team betyr det mer enn rå hastighet.

Unntakene er verktøyene som kjører på Deres maskin. Å be hver bruker installere Python og en rekke pakker ville vært en dårlig førsteopplevelse, så CLI-verktøyet er skrevet i Go (mer om det nedenfor). Disse verktøyene har ingen egen forretningslogikk: alt går gjennom det samme Django-API-et.

Et modent økosystem

Nesten alt vi integrerer med, har et solid Python-bibliotek: Stripe for betalinger, Django REST framework for vårt offentlige API, S3-klienter i boto-stil, Proxmox-API-et og Sentry-kompatibel feilrapportering. Også vår eksterne MCP-server, som lar AI-assistenter administrere domener og DNS for en kunde, er en del av Django-applikasjonen.

Hva vi gir avkall på, og hvordan vi håndterer det

Python er ikke det raskeste språket, og en synkron Django-forespørsel bør ikke vente på et tregt registrar-API. Det håndterer vi på tre måter: tungt eller tregt arbeid sendes til en kø, hyppige lesinger hentes fra Redis, og databasen er tunet og indeksert for spørringsmønstrene våre. I praksis er flaskehalsen nesten alltid et eksternt API, ikke Python.

PostgreSQL: den autoritative kilden

Alle domener, soner, fakturaer og servere ligger i PostgreSQL. Vi valgte den for strenge transaksjoner (penger og domeneeierskap må aldri bli halvveis skrevet), rike datatyper som JSON-felt og nettverksadresser, og en pålitelig backupløsning. Sikkerhetskopieringen er kontinuerlig: write-ahead-loggen sendes til en separat backupserver, slik at vi kan gjenopprette databasen til et hvilket som helst tidspunkt, ikke bare til nattens dump. En varm standby-webserver bruker den samme databasen og kan ta over hvis den primære webserveren svikter.

Redis: cache først

Redis er cachen vår. Oppslag på domenetilgjengelighet og priser, ferdig rendrede sidefragmenter og hastighetsbegrensninger ligger i Redis, slik at en gjentatt forespørsel aldri treffer registrar-API-et eller databasen. Hver cachenøkkel inkluderer språket, fordi den samme siden er forskjellig på / og /tr/. Vi bruker også django-cacheops til å cache ORM-querysets og ugyldiggjøre dem automatisk når en rad endres.

Redis var et enkelt valg: det er raskt, lett å drifte og har utmerket støtte i Django. Siden det allerede er på plass, fungerer det også som grunnlag for den lette jobbkøen vår.

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

Mye av det en kunde setter i gang, bør ikke blokkere siden vedkommende ser på. Å registrere et domene hos registeret, utstede et SSL-sertifikat, opprette en e-postadresse eller starte en hostingcontainer tar alt fra sekunder til minutter. Slike jobber legges i en kø, der arbeidsprosesser plukker dem opp. Vi kjører to køsystemer, hver for den typen arbeid den egner seg best til.

RQ (django-rq) på Redis

RQ er den enkleste køen i Python-verdenen: en jobb er en Python-funksjon med argumenter, lagret i Redis. Vi bruker den til nettstedets daglige jobber:

• opprette kundens konto hos registraren etter registrering,
• utstede og fornye SSL-sertifikater,
• synkronisere domenestatus og DNS-soner,
• legge til e-postadresser og videresendingsregler,
• starte og stoppe hostingcontainere, åpne porter og konfigurere Nginx for en kundeserver,
• opprette fakturaer og sende påminnelser om fornyelse.

En planleggerprosess kjører periodiske jobber, og django-rq-dashbordet viser jobber i kø, jobber som kjører og jobber som har feilet, direkte i admin-grensesnittet. Under utvikling kjører køen synkront, slik at en jobb kjøres umiddelbart og eventuelle feil vises med en gang.

Dramatiq på RabbitMQ

For tyngre og lengre pipelines bruker vi Dramatiq med RabbitMQ som megler. RabbitMQ er en dedikert meldingsmegler: meldinger bekreftes først når en arbeidsprosess er ferdig med dem, så en jobb går ikke tapt hvis en arbeidsprosess krasjer underveis. Dramatiq legger til automatiske nye forsøk med eksponentiell backoff, tidsgrenser, prioriteringer og middleware. Det passer for arbeidsmengder med mange steg, stort volum eller eksterne tjenester som av og til feiler.

Hvorfor to køer?

RQ holder enkle jobber enkle: ingen ekstra tjeneste, enkel feilsøking, og Redis kjører allerede. RabbitMQ og Dramatiq gir sterkere leveringsgarantier og bedre gjennomstrømning når en jobb virkelig trenger det. Ved å velge per arbeidsmengde slipper vi å betale driftskostnaden for en fullverdig meldingsmegler for en jobb på fem sekunder, og vi overlater ikke en kritisk pipeline til det enkleste verktøyet.

Hosting: Proxmox og LXC-containere

Planene våre for hosting og vibe hosting kjører på våre egne Proxmox VE-servere. Hver kundeserver er en LXC-container, ikke en fullverdig virtuell maskin.

• Containere deler vertens kjerne, så de starter på sekunder og bruker langt mindre minne enn virtuelle maskiner. Mer av maskinvaren går dermed til kundens applikasjon i stedet for til et ekstra operativsystem.
• Hver container er isolert, med eget filsystem, egne prosesser, eget nettverk og egne ressursgrenser for CPU, minne og disk.
• Alt er automatisert via Proxmox-API-et. Når De bestiller en server, sender Django en jobb til køen, og en arbeidsprosess oppretter containeren fra en mal, setter grensene, kobler til nettverket, åpner porter og konfigurerer reverse proxy og SSL for domenet Deres.
• Endring av størrelse, sikkerhetskopiering og gjenoppretting er knapper i dashbordet som kaller det samme API-et. Containere kan også flyttes mellom Proxmox-verter når vi fordeler lasten på nytt.

Ved å drifte vår egen maskinvare får vi forutsigbare priser og full kontroll over nettverket, sikkerhetskopiene og hvor dataene lagres.

DNS, e-post og lagring

• DNS: sonene serveres av våre egne PowerDNS-servere (ns1 til ns4). Endringer De gjør i DNS-panelet, skrives til primærserveren og videreformidles automatisk til sekundærserverne. Primærserveren sikkerhetskopieres hver natt.
• E-post: e-posthosting og gratis e-postvideresending kjører på våre egne e-postservere, med SPF, DKIM og DMARC satt opp for domenet Deres.
• Objektlagring: en egendriftet, S3-kompatibel lagringstjeneste tar vare på opplastede filer, sikkerhetskopier og bilder.

nameocean-CLI-et og MCP-serveren

Webdashbordet er ikke den eneste inngangen. Alt det gjør, går gjennom vårt offentlige REST API og vår eksterne MCP-server på https://nameocean.net/mcp, og CLI-verktøyet nameocean er bygget oppå disse.

nameocean-CLI-et

nameocean er én enkelt statisk binærfil skrevet i Go, bygget for macOS, Linux og Windows på både amd64 og arm64. Vi valgte Go her av motsatt grunn av hvorfor vi valgte Python for serveren: et CLI-verktøy må kunne installeres på sekunder og kjøre hvor som helst uten kjøretidsmiljø, og Go kompilerer til én fil som gjør nettopp det.

• Logg inn én gang. nameocean login åpner nettleseren og logger Dem inn med OAuth 2.1 og PKCE. Tokenene lagres i operativsystemets nøkkelring (macOS Keychain, Windows Credential Manager eller libsecret på Linux) og fornyes automatisk. På servere og i CI kan De i stedet bruke en API-nøkkel fra dashbordet.
• Servere og porter. nameocean servers ls, servers info for SSH- og git-detaljer, og ports open / ports close for å eksponere en port på containeren Deres.
• Domener på servere. nameocean bind example.com <server> setter opp DNS, SSL og lastbalansereren med én kommando.
• DNS og SSL. dns ls, dns add og dns rm for A-, CNAME-, MX-, TXT- og andre oppføringer, samt ssl status og ssl issue --wait.
• Domener. domains ls og domains check for tilgjengelighet og pris. CLI-verktøyet bruker aldri penger: registreringer og fornyelser gjøres i dashbordet.
• Laget for skript og AI-agenter. Alle kommandoer støtter --json og skriver ut API-ets JSON uendret, slik at utdataene kan sendes rett videre til jq, shellskript eller en agent.
• Én kommando for AI-klienter. nameocean mcp install finner Claude Code, Cursor og OpenCode på maskinen Deres og legger til NameOcean-MCP-serveren i hver av 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'

Installer det med Homebrew (brew install nameocean/tap/nameocean) eller last ned et arkiv for Deres plattform.

Den eksterne MCP-serveren

Med vibe hosting kommuniserer AI-assistenten Deres direkte med NameOcean. Én kommando kobler til Claude Code: claude mcp add --transport http nameocean https://nameocean.net/mcp. De logger inn én gang i nettleseren, og deretter kan De be assistenten rulle ut, åpne en port eller peke et domene mot serveren Deres uten å røre en eneste konfigurasjonsfil. Cursor, Claude Desktop, claude.ai og andre MCP-klienter kobler seg til den samme URL-en; MCP-dokumentasjonen viser hvordan. Ingenting kjører på maskinen Deres, så det er ingenting å installere eller oppdatere.

Tidligere tilbød vi en skrivebordsapp for dette. Den startet en lokal MCP-server og logget inn med passord, noe som ikke er forenlig med totrinnsinnlogging. Den eksterne serveren gjør den samme jobben uten installasjon, så vi faset ut appen i november 2026.

Hvorfor begge deler?

Folk jobber på ulike måter. CLI-verktøyet er for utviklere som lever i terminalen og ønsker skriptbare, repeterbare kommandoer. MCP-serveren er for dem som heller vil beskrive hva de ønsker, og la AI-assistenten ordne resten. Fordi begge er tynne lag over det samme API-et, når en funksjon som legges til i Django-applikasjonen, webdashbordet, CLI-verktøyet og alle MCP-klienter samtidig.

Overvåking og utrulling

Alle feil i produksjon rapporteres til en egendriftet, Sentry-kompatibel feilsporer. Oppetidssjekker overvåker hver webserver, og metrikker sendes til en tidsseriedatabase. Utrullingene er bevisst kjedelige: vi pusher til git og kjører én Fabric-kommando, som oppdaterer alle webservere, installerer avhengigheter, kjører migreringer, samler statiske filer, kompilerer oversettelser og starter applikasjonen på nytt. Har en server utdatert kode, er løsningen en ny utrulling, aldri en manuell endring.

Oppsummering

• Python og Django for lesbar forretningslogikk, admin-grensesnittet, i18n og ett språk overalt.
• PostgreSQL som den eneste autoritative kilden, med gjenoppretting til et vilkårlig tidspunkt.
• Redis som cache og som backend for RQ-jobbkøen.
• RQ for enkle bakgrunnsjobber, Dramatiq på RabbitMQ for tunge pipelines som ikke må gå tapt.
• Proxmox LXC-containere for rask, isolert og rimelig hosting.
• nameocean-CLI-et (Go) og den eksterne MCP-serveren som tynne lag over det samme API-et.

Nysgjerrig på hva som driver et annet nettsted? Sjekk det med vår Website Technology Checker. Klar til å bygge Deres eget? Finn et domene og legg det på NameOcean-hosting.