Egna domäner för SaaS: låt kunderna använda sin egen domän med Cloudflare for SaaS

Det korta svaret

För att en kund ska kunna köra din app på sin egen domän, till exempel portal.customer.com, registrerar du domänen som ett custom hostname i din Cloudflare-zon. Kunden lägger till en CNAME-post som pekar mot dig, Cloudflare kontrollerar att kunden råder över hostnamnet, en certifikatutfärdare utfärdar certifikaten och trafiken börjar nå din app.

I oktober 2026 ingår på Cloudflare for SaaS-planssidan 100 custom hostnames i planerna Free, Pro och Business, med ett pris på 0,10 USD per extra hostname och ett tak på 50 000 hostnames för dessa planer.

Två begränsningar styr varje upplägg. Kunder kan inte peka en ren apex-domän (customer.com) mot dig utan ett betalt Enterprise-tillägg. Och wildcard-hostnames, egna certifikat och val av certifikatutfärdare finns bara i Enterprise. Själva Cloudflare-konfigurationen är några få steg. Produktarbetet runt omkring tar längre tid, och det är det mesta av den här guiden handlar om.

Vad ett custom hostname är

Ett custom hostname är en domän som din kund äger och som Cloudflare dirigerar in i din zon. Installationsguiden har fyra delar:

• SaaS-zon. Din egen domän hos Cloudflare, med Cloudflare for SaaS aktiverat. En zon på Free-planen räcker för att komma igång.
• Fallback origin. En proxad DNS-post, till exempel proxy-fallback.yourapp.com, dit trafiken för custom hostnames går.
• CNAME-mål. Ett valfritt, enklare namn som kunderna kan peka mot, till exempel customers.yourapp.com.
• Custom hostname. Kundens domän, skapad via API eller dashboard, med eget valideringsstatus. Cloudflare utfärdar två certifikat för varje: ett primärt ECDSA P-256 och ett RSA 2048-bitars som reserv för äldre klienter.

Om din app körs på Cloudflare Workers, plattformen som Dardo bygger på, kan Workern vara fallback origin. En */*-route fångar upp anrop för alla custom hostnames, och din kod läser headern Host för att hitta rätt tenant. Cloudflare erbjuder även anpassad metadata per hostname, men det är ett betalt Enterprise-tillägg, så på andra planer ligger den uppslagningen i din egen databas, till exempel D1.

Så fungerar flödet

1. Kunden anger en domän i appens inställningar. Din backend normaliserar den och anropar endpointen Create Custom Hostname med en valideringsmetod för certifikatet.
2. Kunden lägger till DNS-posten som du visar, till exempel portal.customer.com CNAME customers.yourapp.com.
3. Cloudflare validerar äganderätten till hostnamnet. Realtidsvalidering körs när CNAME-posten dyker upp, vilket kan innebära ett kort avbrott. Förvalidering använder en TXT-post eller en HTTP-token innan DNS ändras, för domäner som redan är i drift. Förvalidering stöds inte när kundens egen zon också ligger hos Cloudflare (en "Orange-to-Orange"-konfiguration).
4. Certifikatutfärdaren validerar domänkontrollen och utfärdar certifikaten.
5. Hostnamnet är klart när både status och ssl.status är active och DNS pekar mot ditt mål. Cloudflare varnar för att en TLS-handskakning kan lyckas innan ssl.status blir active, så utgå från endpointen för detaljer om custom hostname som sanningskälla.

Valideringsmetoder för certifikat

Cloudflares valideringsguide erbjuder dessa alternativ:

Valideringen väntar inte för evigt. Cloudflare försöker validera hostnamnet 75 gånger under sju dagar, och enligt dess backoff-schema raderas custom hostname om valideringen misslyckas. Certifikattokens går också ut: efter 7 dagar hos Let's Encrypt och 14 dagar hos Google Trust Services eller SSL.com.

Vad det kostar, i oktober 2026

Planssidan anger 0,10 USD utan någon tidsperiod. Cloudflares meddelande från 2022 beskrev det som en sänkning av priset "från 2 USD till 0,10 USD i månaden". Med den månadstaxan innebär 1 000 kunddomäner 900 utöver de 100 som ingår, alltså 90 USD i månaden.

Två faktureringsregler spelar roll för produktdesignen. Enligt Cloudflares sida om kvoter och fakturering räknas varje hostname mot användningen tills du raderar det, inklusive "hostnames som väntar på validering eller aktivering". Och planer utanför Enterprise har en tröskel i API:t, över vilken nya hostnames avvisas.

Där det går sönder

Apex-domäner

Cloudflares installationsguide är tydlig: "By default, using an A record to point to the target is not a supported setup." De flesta DNS-leverantörer tillåter inte en CNAME på domänens rot, så kunderna behöver en underdomän som www.customer.com eller app.customer.com. Apex proxying ger ditt konto statiska IP-prefix så att kunderna kan använda en A-post, men det är ett Enterprise-tillägg med egen kostnad. Utan det ber du kunderna om en underdomän och förklarar hur de vidarebefordrar den nakna domänen dit hos sin DNS-leverantör.

Certifikatutfärdare och CAA-poster

Cloudflares referens för certifikatutfärdare listar Let's Encrypt (certifikat på 90 dagar), Google Trust Services och SSL.com (14, 30 eller 90 dagar) för anpassade värdnamn. Att välja certifikatutfärdare ingår bara i Enterprise; annars använder Cloudflare sin standard och kontrollerar CAA-poster först. Om kundens CAA-poster inte tillåter den certifikatutfärdaren misslyckas utfärdandet med "CAA records block issuance", och bara kunden kan åtgärda det. CAA-uppslag följer CNAME-kedjor, så även CAA-posterna för din egen måldomän spelar roll. Felsökningsguiden listar de andra felen på kundsidan: trasig DNSSEC och DNS-servrar som svarar med SERVFAIL.

Förnyelser

Certifikat för anpassade värdnamn gäller i 90 dagar och kan förnyas 30 dagar före utgång. Aktiva värdnamn utan jokertecken förnyas automatiskt via HTTP. Om ett värdnamn inte längre är aktivt, till exempel för att kunden har ändrat sin DNS, måste kunden lägga in en ny token, och du ansvarar för att skicka den till kunden. Jokertecken kan bara förnyas via TXT, vilket är det Delegated DCV automatiserar.

Kunder på ett annat CDN eller på Cloudflare

Cloudflare säger att anpassade värdnamn som använder ett annat CDN inte är kompatibla när det CDN:et döljer DNS-posterna. Kunder vars domäner ligger hos Cloudflare ger det motsatta problemet: om de lämnar dig och du inte tar bort deras värdnamn kan det fortsätta att dirigera till din tjänst även efter att de ändrat sin DNS.

Workers framför valideringssökvägar

Om en Worker är din reservorigin måste den släppa igenom /.well-known/pki-validation/* och /.well-known/acme-challenge/* oförändrade. En övergripande route som svarar med appens 404-sida bryter HTTP-valideringen.

Produktarbetet runt omkring

• Kontroll av abonnemang. Bestäm vilka av dina abonnemang som inkluderar egna domäner och hur många, och kontrollera det innan du anropar Cloudflare. Cloudflares kvot och tröskel är tak, inte din prissättning.
• Introduktionsvy. Ett enda inmatningsfält. Gör om texten till gemener, ta bort protokoll och sökväg, avvisa nakna apex-domäner om du inte har köpt apex proxying, och avvisa din egen zon, som Cloudflare säger att man aldrig ska skapa som anpassat värdnamn. Visa sedan exakt vilken post som ska läggas till, med en kopieringsknapp.
• Två statusar på klarspråk. Värdnamn och certifikat valideras separat, så visa båda. Översätt ssl.validation_errors till instruktioner: "Din domäns CAA-poster tillåter inte vår certifikatutfärdare; lägg till den här posten" slår "pending_validation". Svaret vid skapandet kanske ännu inte innehåller några valideringsposter, så hämta värdnamnet igen efter en kort fördröjning. Cloudflares webhook-notiser rapporterar validerings- och utfärdandehändelser, vilket slår polling.
• Övervakning av förnyelser. Ett dagligt jobb som flaggar värdnamn vars certifikat inte är aktivt eller vars DNS inte längre pekar på dig, så att ditt team får veta det före kunden.
• Städning. Ta bort värdnamn som aldrig valideras och värdnamn som tillhör kunder som lämnar. Båda faktureras tills de tas bort.
• Isolering mellan tenants. Identifiera tenant enbart utifrån aktiva värdnamn i din databas. Om tenants även får underdomäner till din domän påpekar Vercels domändokumentation att en cookie som en tenant sätter för föräldradomänen når de andra, så håll din instrumentpanel och inloggning på en separat domän.
• Supportmanual. En kort sida åt ditt team som kopplar varje fel till vem som åtgärdar det: saknad CNAME, CAA, DNSSEC och SERVFAIL ligger hos kunden; tokens, CA-gränser och Worker-routes ligger hos dig.

Det här är den sortens arbete Dardo gör inom utveckling av webbappar, och white label-kundportaler är där egna domäner efterfrågas oftast.

Alternativ: Vercel och Netlify

Om din app redan körs någon annanstans hanterar båda leverantörerna kunddomäner, med egna dokumenterade begränsningar per oktober 2026.

Vercels stöd för apex är den tydligaste skillnaden: kunderna kan peka en naken domän dit med en A-post. Observera att Hobby-abonnemanget enligt Vercels riktlinjer för rimlig användning är begränsat till "non-commercial, personal use only", så en betalande SaaS börjar på Pro. Netlifys rekommendation på 50 alias gör det till ett dåligt val för en enda driftsättning som ska betjäna hundratals kunddomäner.

När du bör bygga det

Om två eller tre kunder frågar efter det, lägg till deras värdnamn i Cloudflares instrumentpanel och för en checklista. Bygg självbetjäningsflödet när egna domäner blir en del av ett abonnemang du säljer eller av ett white label-erbjudande. Om kunder behöver nakna apex-domäner eller jokerteckendomäner i stor skala, prata med Cloudflare om Enterprise innan du utformar något kring begränsningarna.

Vill du ha det flödet inbyggt i din produkt, med statusar, aviseringar och supportanteckningar enligt ovan? Berätta om din app.