Cloudflare for SaaS alternative in 2026: meet Domainee (what it does, how it works, who it's for)

Cloudflare SSL for SaaS works. It runs JetBlue, Olo, Indeed. At the very high end of the market it is a serious piece of infrastructure.

You probably know that. The reason you typed "Cloudflare for SaaS alternative" into Google is something else. Procurement won't sign a multi-quarter Enterprise contract for a feature you haven't shipped yet. Or your sales call last week ended with a six-figure number and a deck. Or you want an API key today, not after legal. Or you already pay another CDN and don't want a second one bolted on. Or you want MCP so an AI agent can register hostnames inside a chat, and Cloudflare doesn't ship that.

This post is the full walkthrough of Domainee, the self-serve alternative. What it is, who it's for, how it works under the hood, the 5-minute tutorial, and the pricing. By the end you'll know whether to swap or keep walking.

Why people search for an alternative

Five reasons keep showing up in DMs and Reddit threads:

No published pricing. SSL for SaaS isn't on Cloudflare's pricing page. You won't see a number until a discovery call. Even strong technical leads at small SaaS teams have stopped reading at that point.
It's effectively Enterprise-only for production. The list features people assume are included (webhooks on hostname state changes, custom per-hostname metadata, BYOIP, apex proxying) all sit on the Enterprise plan. In practice that means deals start in the $5K to $15K per month range with a multi-quarter contract.
Partner-gated onboarding. Small and mid-market SaaS often can't self-serve at all. You'll be routed to a partner. The lead time is weeks, sometimes months.
Bundled with infrastructure you may not need. Cloudflare SSL for SaaS lands inside Cloudflare's full edge: WAF, bot management, R2, the works. Powerful, and a fair amount of it is overhead if you just need TLS termination for customer hostnames.
No MCP / agent surface. If you're building an AI-driven onboarding flow or letting an agent provision tenant resources, Cloudflare's API is fine but there's no first-class MCP integration. In 2026 that is starting to matter for a non-trivial slice of SaaS.

If you nodded at any of those, the rest of this post is for you.

What Cloudflare SSL for SaaS actually costs

The headline numbers, for context:

100 custom hostnames included on any paid Cloudflare zone (Free, Pro, or Business).
$0.10 per custom hostname per month above the first 100, capped at 50,000 on PAYG (raised from 5,000 in May 2025).
15 certificate issuances per minute by default. Hit the ceiling and you eat a 30-second lockout.

That math is competitive. The issue is the asterisks underneath it.

Webhooks on hostname state changes are Enterprise-only. Without webhooks you're polling result.status and result.ssl.status every 30 seconds during onboarding. Both have to read "active" before traffic works. That's fine for 5 customers, fine for 50, painful at 5,000.

Apex proxying, custom per-hostname metadata, and BYOIP are also Enterprise-only. Apex is the one that catches teams off guard. Your customer wants acme.com to land on your app, not shop.acme.com. On Cloudflare you need apex proxying for that to work cleanly, and apex proxying is gated. The deeper version of this (apex CNAME flattening, ALIAS records, A-record fallbacks) is a separate engineering project on top.

Cloudflare's published Enterprise contract starts in the $5K range. Real-world deals for SSL for SaaS at production scale land between $5K and $15K per month, multi-year, with a partner agreement.

A fuller breakdown lives at /alternatives/cloudflare-ssl-for-saas.

OK. The alternative.

Meet Domainee

Domainee is a developer API that lets your SaaS users connect their own domain to your product. Their customers type shop.acme.com and land on your app, with first-class TLS, real HTTP, and your origin invisible behind the edge.

Three things travel together in the box:

Connect API. Bring your own domain. One POST per customer hostname, one CNAME at their registrar, cert issues on first request and renews forever.
Buy-a-Domain API. Your user doesn't own a domain yet. Live availability check, one purchase call, auto-connect, the user is the legal registrant.
Masking and Forwarding APIs. Reverse-proxy at the edge (mode: "proxy") or HTTP 301/302 (mode: "redirect"). Same API, different intent.

Public REST surface plus a first-class MCP server so an AI agent can drive the exact same key. HMAC-signed webhooks fire on every plan, including the free one. Stripe-shaped developer experience: Bearer auth, idempotency keys, signed webhooks, every endpoint documented at /docs/api.

Who Domainee is for

Five fits where Domainee is the obvious pick:

SaaS founders shipping their first custom-domain feature. You're 1 to 200 customers in. You need this to ship, you need it to look professional, and you don't have the engineering bandwidth for an ACME loop or the procurement bandwidth for an Enterprise deal.
Multi-tenant teams ready to white-label. You're already running tenants on acme.yourapp.com subdomains. The customer wants app.acme.com. Same product, different URL. Domainee plugs in behind your existing tenant lookup.
Agencies and platform builders. You manage dozens of client brands. One Domainee workspace, one Bearer key, every client's hostname tagged with metadata.clientId, webhooks fan out to one handler. The setup is at /use-cases/agencies-platform-builders.
AI builders shipping with MCP. You're letting an agent provision tenants inside a chat. Domainee's MCP server exposes the API surface as tools, with the same auth. The agent can register a hostname, fetch its status, and emit a CNAME to the customer without you wiring it manually.
Anyone burned by a Cloudflare orange-cloud ticket. You've shipped custom domains before, on something else, and learned the operational realities the hard way. Domainee's dashboard detects orange-cloud automatically, flags apex misconfigurations, and surfaces drift before your customer files a ticket.

Who Domainee is NOT for: ultra-high-scale platforms that already run Cloudflare's full edge under contract (WAF, bot management, R2, the works). If you're already paying $10K+ a month for the rest of the platform, SSL for SaaS is a slot-in, and the comparison stops being interesting.

How Domainee works under the hood

If you've built a multi-tenant SaaS before, the architecture will read familiar. If not, here's the path a request walks.

Step 1. The customer adds a CNAME. They go to their registrar (Namecheap, GoDaddy, Cloudflare DNS, name dot com, etc.), open the DNS panel, paste one record: CNAME shop edge.domainee.dev. That's the only thing they ever touch.

Step 2. Domainee's edge picks up the resolver propagation. As Cloudflare, Google, Quad9, and OpenDNS catch up, Domainee verifies the CNAME and fires a domain.pending then domain.verified webhook to your backend.

Step 3. Let's Encrypt issues a cert on first request. ACME validation runs over HTTP-01 against Domainee's edge (no customer action required). The cert lands, marked ssl: "active" in the API. Renewals run every 60 days, forever. You never see them.

Step 4. A visitor hits shop.acme.com over HTTPS. Domainee's edge terminates TLS using the customer's hostname cert. It then proxies to your origin with two headers your origin reads to figure out the tenant:

X-Forwarded-Host:        shop.acme.com
X-Domainee-Original-Host: shop.acme.com

Step 5. Your origin reads the header, looks up the tenant, returns HTML. Same Next.js app, same Rails app, same Phoenix app. You're already doing this for your subdomain tenants. Nothing else changes.

Step 6. Drift detection runs in the background. Domainee polls each customer's DNS on a deterministic schedule. If a customer accidentally removes the CNAME, points it elsewhere, or flips on Cloudflare orange-cloud, you get a domain.drift webhook within minutes, with the exact diagnosis. Drift detection is on by default, every tier.

The whole thing is roughly one box drawing:

Visitor → shop.acme.com (TLS) → Domainee edge → X-Forwarded-Host → your origin
                                      ↓
                              Let's Encrypt cert
                              DNS health monitor
                              Webhook fanout

Tutorial: Connect your first customer domain in 5 minutes

End-to-end, from API key to a live customer hostname.

Step 1. Mint an API key

Sign up at /sign-up. Free, no card. Open /developers, click Create API key, copy the sk_live_… string. It's shown once.

Step 2. Register a customer hostname

From your app's backend, when a customer adds a domain:

curl https://api.domainee.dev/v1/domains \
  -H "Authorization: Bearer $DOMAINEE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "hostname": "shop.acme.com",
    "originUrl": "https://acme-prod.fly.dev",
    "mode": "proxy",
    "metadata": { "tenantId": "tnt_77721" }
  }'

Response:

{
  "domain": {
    "id": "8f09b47c-b42f-4d14-9e10-...",
    "hostname": "shop.acme.com",
    "status": "pending",
    "ssl": "pending",
    "dnsRecords": [
      { "type": "CNAME",
        "name": "shop.acme.com",
        "value": "edge.domainee.dev" }
    ]
  }
}

metadata is yours. Stick your tenant ID, client ID, plan tier, whatever. It comes back on every webhook so your handler doesn't need a second lookup.

Step 3. Tell the customer the CNAME

Render the dnsRecords array in your UI. For a clean experience: copy button on the value, a registrar hint ("On Cloudflare DNS? Make sure the proxy is OFF."), and a live status pill.

Type   Name           Value
CNAME  shop.acme.com  edge.domainee.dev

Step 4. Handle the webhook when DNS lands

Domainee fires domain.verified the moment DNS resolves and the cert provisions. HMAC-signed with your endpoint secret. Retried for 7 days if your handler 5xx's.

import crypto from "node:crypto";
import express from "express";

const app = express();

app.post(
  "/webhooks/domainee",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    const sig = req.header("x-domainee-signature");
    const expected =
      "sha256=" +
      crypto.createHmac("sha256", process.env.WHSEC)
        .update(req.body)
        .digest("hex");
    if (!crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected))) {
      return res.status(401).end();
    }
    const event = JSON.parse(req.body.toString());
    if (event.type === "domain.verified") {
      await db.tenants.update({
        where: { id: event.data.metadata.tenantId },
        data: { customDomain: event.data.hostname, status: "live" },
      });
    }
    res.json({ ok: true });
  },
);

Step 5. Read the host header at your origin

When a visitor hits the customer's hostname, your existing tenant lookup keys off X-Forwarded-Host. Next.js middleware example:

// middleware.ts
import { NextRequest, NextResponse } from "next/server";

export function middleware(req: NextRequest) {
  const host =
    req.headers.get("x-domainee-original-host") ??
    req.headers.get("x-forwarded-host") ??
    req.headers.get("host") ??
    "";

  if (host === "yoursaas.com" || host.endsWith(".yoursaas.com")) {
    return NextResponse.next();
  }

  const tenant = lookupTenantByHost(host);
  if (!tenant) return NextResponse.next();

  const url = req.nextUrl.clone();
  url.pathname = `/_tenants/${tenant.id}${url.pathname}`;
  return NextResponse.rewrite(url);
}

The full multi-tenant pattern (including dynamic OG tags and per-tenant favicons) is at /blog/nextjs-multi-tenant-custom-domains.

That's the whole integration

Five minutes if you've got an Express or Next.js app ready. Twenty minutes if you're wiring it into a Rails or Phoenix app for the first time. The customer-facing UX is a single text field plus a status pill.

Pricing

The whole reason this post exists.

Free, forever. 50 custom domains and 100 GB bandwidth per month, no credit card, no expiry. The free quota stays free even after you upgrade.
Pay as you go. $0.20 per domain per month, graduated to $0.10 at 10,000+ domains (50% off). 400 GB bandwidth included on paid, $0.05/GB after. No monthly minimum.

What's included on every tier (yes, including free):

Connect API (BYO domain)
Buy-a-Domain API (your user purchases inside your app)
Masking + Forwarding APIs
HMAC-signed webhooks with retries
MCP server for AI agents
Drift detection + orange-cloud warnings
Dashboard with per-customer telemetry

What's NOT included: a sales call. There isn't one.

Operational realities you should know about up front

Five things every SaaS shipping custom domains hits in production. Worth knowing whether you pick Domainee or anything else.

Cloudflare orange-cloud. Your customer's domain uses Cloudflare DNS, they click the orange cloud, and their Cloudflare instance gets between the visitor and your edge. TLS handshakes fail. Domainee inspects A records on registration and flags it with the fix pre-drafted. Full runbook at /blog/debug-customer-custom-domain-runbook.

Apex domains. The customer wants acme.com, not shop.acme.com. CNAME at the apex is technically against spec; most registrars support ALIAS / ANAME / Cloudflare CNAME-flattening. Where they don't, A records work. Domainee returns BOTH options in dnsRecords. Full breakdown at /blog/apex-domain-support-for-saas.

Cert renewal. Let's Encrypt rate-limits in three tiers (50, 500, 5,000 hostnames per account/week). Domainee handles the pool routing internally. You never trip a limit.

DNS drift. Customer accidentally removes the CNAME six months in. Domainee polls deterministically, fires domain.drift within minutes, the dashboard shows the diagnosis. The wider story is at /blog/monitor-customer-ssl-certificates-at-scale.

Masking vs forwarding. Two intents people conflate. Masking keeps the customer's URL in the address bar and proxies under it (mode: "proxy"). Forwarding sends a 301 to a new URL (mode: "redirect"). Both work, but the use cases are different. The honest comparison is at /blog/domain-masking-without-iframe.

What to do next

If you came in pre-shortlisted on Cloudflare and just need an alternative that ships this week: start with the free tier (/sign-up). Fifty customer hostnames covers the entire pilot and early-paid phase of most SaaS products. No card, no contract.

If you're already convinced and want the deeper how-to, the multi-tenant Next.js pattern is at /blog/nextjs-multi-tenant-custom-domains.

If you want to compare side-by-side first, the long-form Cloudflare comparison is at /alternatives/cloudflare-ssl-for-saas.