NameOceans teknikstack: Python, Django, Redis och Proxmox

Kort svar: NameOcean är en applikation byggd i Python och Django. PostgreSQL lagrar data, Redis fungerar som cache och bakgrundsjobb körs i två kösystem: RQ på Redis för korta jobb och Dramatiq på RabbitMQ för tyngre pipelines. Kundernas hosting körs i Proxmox LXC-containrar på våra egna servrar, och allt kan hanteras från webbläsaren, från ett kommandoradsverktyg skrivet i Go eller från er AI-assistent via MCP. I det här inlägget går vi igenom varje lager och förklarar varför vi valde det.

Stacken i korthet

• Språk och ramverk: Python med Django, som körs av Gunicorn bakom Nginx.
• Databas: PostgreSQL, med point-in-time recovery-säkerhetskopior till en separat backupserver.
• Cache: Redis, via django-redis och django-cacheops.
• Köer: RQ (django-rq) på Redis samt Dramatiq på RabbitMQ.
• Hosting: Proxmox VE-värdar som kör varje kundserver som en LXC-container.
• DNS: våra egna PowerDNS-servrar, ns1 till ns4.
• Objektlagring: en egendriven, S3-kompatibel lagring för filer, säkerhetskopior och bloggbilder.
• Klientverktyg: CLI:t nameocean (Go) och vår fjärranslutna MCP-server för AI-klienter, båda byggda ovanpå samma publika API.
• Driftsättning: git push plus ett enda Fabric-kommando. Ingen redigerar kod direkt på en server.

Vill ni se hur andra webbplatser är byggda? Vårt kostnadsfria verktyg Website Technology Checker visar hostingleverantör, CMS, programmeringsspråk och ramverk för vilken domän som helst. Testa det på nameocean.net.

Varför Python och Django

En domänregistrar ser enkel ut utifrån: sök efter ett namn, betala, hantera DNS. Under ytan finns det dock mycket affärslogik. Det handlar om registrar-API:er, flyttar med egna tillståndsmaskiner, förnyelser, fakturor i flera valutor, utfärdande av SSL-certifikat, DNS-zoner, e-postlådor och hostingservrar, och allt detta på 21 språk. Vi ville ha en stack som håller logiken läsbar och låter ett litet team leverera på ett säkert sätt. Det ger Django oss.

Allt som behövs ingår, på riktigt

Django levererar de delar som varje registrar behöver från första dagen:

• ORM och migreringar. Våra modeller (domäner, zoner, flyttar, fakturor, servrar) förändras varje vecka. Med Djangos migreringar blir varje schemaändring en granskad fil i git som körs på samma sätt lokalt, i tester och i produktion.
• Adminpanelen. Support- och driftarbete sker i Django admin. Vi har inte behövt bygga ett eget internt backoffice. Vi anpassar den där det spelar roll, till exempel för säkra borttagningar och faktureringsåtgärder.
• Autentisering och säkerhet. Sessioner, CSRF-skydd, lösenordshashning och en anpassad användarmodell baserad på e-postadress finns inbyggt. Ovanpå det har vi lagt tvåfaktorsautentisering.
• Internationalisering. Webbplatsen är översatt till 21 språk med Djangos gettext-verktyg och URL:er med språkprefix. Engelska behöver inget prefix, övriga språk får /tr/, /de/ och så vidare.
• Sitemaps, cachning, mallar. Allt standard och väldokumenterat.

Ett språk från webbplatsen till servrarna

Python används inte bara i webbapplikationen. Samma språk driver köarbetarna, management-kommandona bakom våra cron-jobb, skripten som kommunicerar med Proxmox, DNS-verktygen (dnspython) och våra driftsättningsskript (Fabric). En utvecklare som kan läsa kassavyn kan också läsa koden som skapar en hostingcontainer eller förnyar ett certifikat. För ett litet team väger det tyngre än ren prestanda.

Undantagen är verktygen som körs på er dator. Att be varje användare installera Python och en uppsättning paket vore en dålig första upplevelse, så CLI:t är skrivet i Go (mer om det nedan). Verktygen innehåller ingen egen affärslogik: allt går via samma Django-API.

Ett moget ekosystem

Nästan allt vi integrerar med har ett stabilt Python-bibliotek: Stripe för betalningar, Django REST framework för vårt publika API, S3-klienter i boto-stil, Proxmox-API:t och Sentry-kompatibel felrapportering. Vår fjärranslutna MCP-server, som låter AI-assistenter hantera domäner och DNS åt en kund, är också en del av Django-applikationen.

Vad vi avstår från, och hur vi hanterar det

Python är inte det snabbaste språket, och en synkron Django-förfrågan bör inte vänta på ett långsamt registrar-API. Vi hanterar det på tre sätt: tungt eller långsamt arbete skickas till en kö, frekventa läsningar hämtas från Redis och databasen är optimerad och indexerad för våra frågemönster. I praktiken är flaskhalsen nästan alltid ett externt API, inte Python.

PostgreSQL: den enda sanningskällan

Varje domän, zon, faktura och server finns i PostgreSQL. Vi valde den för strikta transaktioner (pengar och domänägande får aldrig skrivas till hälften), rika datatyper som JSON-fält och nätverksadresser, samt pålitliga säkerhetskopior. Säkerhetskopieringen sker kontinuerligt: write-ahead-loggen skickas till en separat backupserver, så att vi kan återställa databasen till valfri tidpunkt och inte bara till gårdagens dump. En varm standby-webbserver använder samma databas och kan ta över om den primära webbservern går ner.

Redis: cache först

Redis är vår cache. Uppslag av domäntillgänglighet och priser, renderade sidfragment och hastighetsbegränsningar ligger i Redis, så att en upprepad förfrågan aldrig behöver gå till registrar-API:t eller databasen. Varje cachenyckel innehåller språket, eftersom samma sida skiljer sig mellan / och /tr/. Vi använder också django-cacheops för att cacha ORM-querysets och ogiltigförklara dem automatiskt när en rad ändras.

Redis var ett enkelt val: det är snabbt, lätt att drifta och har utmärkt stöd i Django. Eftersom det redan finns på plats används det även som grund för vår lättviktiga jobbkö.

Köer: RQ på Redis och Dramatiq på RabbitMQ

Mycket av det en kund sätter igång bör inte blockera sidan hen tittar på. Att registrera en domän hos registret, utfärda ett SSL-certifikat, skapa en e-postadress eller starta en hostingcontainer tar sekunder eller minuter. Sådana jobb läggs i en kö där arbetsprocesser plockar upp dem. Vi kör två kösystem, vart och ett för den typ av arbete det passar bäst för.

RQ (django-rq) på Redis

RQ är den enklaste kön i Python-världen: ett jobb är en Python-funktion med argument, lagrad i Redis. Vi använder den för webbplatsens dagliga jobb:

• skapa kundens konto hos registraren efter registrering,
• utfärda och förnya SSL-certifikat,
• synkronisera domänstatus och DNS-zoner,
• lägga till e-postadresser och vidarebefordringsregler,
• starta och stoppa hostingcontainrar, öppna portar och konfigurera Nginx för en kundserver,
• skapa fakturor och skicka påminnelser om förnyelse.

En schemaläggningsprocess kör periodiska jobb, och django-rq-panelen visar köade, pågående och misslyckade jobb direkt i adminpanelen. Under utveckling körs kön synkront, så att ett jobb körs direkt och eventuella fel syns omedelbart.

Dramatiq på RabbitMQ

För tyngre och längre pipelines använder vi Dramatiq med RabbitMQ som meddelandemäklare. RabbitMQ är en dedikerad meddelandemäklare: meddelanden kvitteras först när en arbetsprocess har slutfört dem, så ett jobb går inte förlorat om en arbetsprocess kraschar halvvägs. Dramatiq lägger till automatiska omförsök med exponentiell backoff, tidsgränser, prioriteringar och middleware. Det passar arbetslaster med många steg, stora volymer eller externa tjänster som då och då fallerar.

Varför två köer?

RQ håller enkla jobb enkla: ingen extra tjänst, enkel felsökning, och Redis körs redan. RabbitMQ och Dramatiq ger starkare leveransgarantier och bättre genomströmning när ett jobb verkligen kräver det. Genom att välja utifrån arbetslast slipper vi driftkostnaden för en fullskalig meddelandemäklare för ett jobb på fem sekunder, och vi anförtror inte en kritisk pipeline åt det enklaste verktyget.

Hosting: Proxmox och LXC-containrar

Våra hosting- och vibe hosting-paket körs på våra egna Proxmox VE-servrar. Varje kundserver är en LXC-container, inte en fullständig virtuell maskin.

• Containrar delar värdens kärna, så de startar på några sekunder och använder betydligt mindre minne än virtuella maskiner. En större del av hårdvaran går till kundens applikation i stället för till ett extra operativsystem.
• Varje container är isolerad, med eget filsystem, egna processer, eget nätverk och egna resursgränser för CPU, minne och disk.
• Allt automatiseras via Proxmox-API:t. När ni beställer en server skickar Django ett jobb till kön, och en arbetsprocess skapar containern från en mall, sätter dess gränser, kopplar på nätverket, öppnar portar och konfigurerar reverse proxy och SSL för er domän.
• Storleksändring, säkerhetskopiering och återställning är knappar i kontrollpanelen som anropar samma API. Containrar kan också flyttas mellan Proxmox-värdar när vi balanserar om lasten.

Att köra egen hårdvara innebär förutsägbara priser och full kontroll över nätverket, säkerhetskopiorna och var data lagras.

DNS, e-post och lagring

• DNS: zonerna betjänas av våra egna PowerDNS-servrar (ns1 till ns4). Ändringar ni gör i DNS-panelen skrivs till den primära servern och förs automatiskt vidare till de sekundära. Den primära servern säkerhetskopieras varje natt.
• E-post: e-posthosting och kostnadsfri vidarebefordran av e-post körs på våra egna e-postservrar, med SPF, DKIM och DMARC konfigurerade för er domän.
• Objektlagring: en egendriven, S3-kompatibel lagring håller uppladdade filer, säkerhetskopior och bilder.

CLI:t nameocean och MCP-servern

Webbpanelen är inte den enda vägen in. Allt den gör går via vårt publika REST API och vår fjärranslutna MCP-server på https://nameocean.net/mcp, och CLI:t nameocean är byggt ovanpå dessa.

CLI:t nameocean

nameocean är en enda statisk binärfil skriven i Go, byggd för macOS, Linux och Windows på både amd64 och arm64. Vi valde Go här av motsatt anledning till att vi valde Python för servern: ett CLI måste gå att installera på några sekunder och köras var som helst utan runtime, och Go kompileras till en enda fil som gör precis det.

• Logga in en gång. nameocean login öppnar webbläsaren och loggar in er med OAuth 2.1 och PKCE. Token lagras i operativsystemets nyckelring (macOS Keychain, Windows Credential Manager eller libsecret på Linux) och förnyas automatiskt. På servrar och i CI fungerar i stället en API-nyckel från kontrollpanelen.
• Servrar och portar. nameocean servers ls, servers info för SSH- och git-uppgifter, samt ports open / ports close för att exponera en port på er container.
• Domäner på servrar. nameocean bind example.com <server> konfigurerar DNS, SSL och lastbalanseraren med ett enda kommando.
• DNS och SSL. dns ls, dns add och dns rm för A-, CNAME-, MX-, TXT- och andra poster, plus ssl status och ssl issue --wait.
• Domäner. domains ls och domains check för tillgänglighet och pris. CLI:t spenderar aldrig pengar: registreringar och förnyelser görs i kontrollpanelen.
• Byggt för skript och AI-agenter. Varje kommando tar --json och skriver ut API:ets JSON oförändrad, så att den kan skickas direkt vidare till jq, skalskript eller en agent.
• Ett kommando för AI-klienter. nameocean mcp install hittar Claude Code, Cursor och OpenCode på er dator och lägger till NameOceans MCP-server i var och en 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'

Installera det med Homebrew (brew install nameocean/tap/nameocean) eller ladda ner ett arkiv för er plattform.

Den fjärranslutna MCP-servern

Med vibe hosting pratar er AI-assistent direkt med NameOcean. Ett enda kommando ansluter Claude Code: claude mcp add --transport http nameocean https://nameocean.net/mcp. Ni loggar in en gång i webbläsaren, och därefter kan ni be assistenten att driftsätta, öppna en port eller peka en domän mot er server utan att röra en enda konfigurationsfil. Cursor, Claude Desktop, claude.ai och andra MCP-klienter ansluter till samma URL; i MCP-dokumentationen ser ni hur. Ingenting körs på er dator, så det finns inget att installera eller uppdatera.

Tidigare levererade vi en skrivbordsapp för detta. Den startade en lokal MCP-server och loggade in med lösenord, vilket inte fungerar med tvåstegsinloggning, och den fjärranslutna servern gör samma jobb utan installation. Därför avvecklade vi appen i november 2026.

Varför båda?

Olika människor arbetar på olika sätt. CLI:t är till för utvecklare som lever i terminalen och vill ha skriptbara, repeterbara kommandon. MCP-servern är till för dem som hellre beskriver vad de vill uppnå och låter sin AI-assistent sköta resten. Eftersom båda är tunna lager ovanpå samma API når en funktion som läggs till i Django-applikationen webbpanelen, CLI:t och alla MCP-klienter samtidigt.

Övervakning och driftsättning

Varje fel i produktion rapporteras till en egendriven, Sentry-kompatibel felspårare. Tillgänglighetskontroller övervakar varje webbserver, och mätvärden skickas till en tidsseriedatabas. Driftsättningar är medvetet odramatiska: vi pushar till git, kör ett Fabric-kommando, och det uppdaterar alla webbservrar, installerar beroenden, kör migreringar, samlar in statiska filer, kompilerar översättningar och startar om applikationen. Om en server har inaktuell kod är lösningen en ny driftsättning, aldrig en manuell ändring.

Sammanfattning

• Python och Django för läsbar affärslogik, adminpanelen, i18n och ett och samma språk överallt.
• PostgreSQL som den enda sanningskällan, med point-in-time recovery.
• Redis som cache och som backend för jobbkön RQ.
• RQ för enkla bakgrundsjobb, Dramatiq på RabbitMQ för tunga pipelines där inget får gå förlorat.
• Proxmox LXC-containrar för snabb, isolerad och prisvärd hosting.
• CLI:t nameocean (Go) och den fjärranslutna MCP-servern som tunna lager ovanpå samma API.

Nyfiken på vad som driver en annan webbplats? Kör den genom vår Website Technology Checker. Redo att bygga er egen? Hitta en domän och lägg den på NameOcean hosting.