Approximated vs DIY: The Real Cost of Point-an-A-Record-and-We-Handle-SSL on a Cluster-API Fleet

Every multi-tenant platform hits the same wall the week its first customer asks, "can I use my own domain?" Behind that one question sits an entire pipeline — domain verification, certificate issuance, renewal, routing, and abuse handling — that has to work unattended at 3 a.m. for domain number 10,000 exactly as well as it did for domain number one. Approximated packages that whole pipeline as one API call plus a DNS A record. The question is what that convenience costs against building the same ACME-plus-DNS flow into a Cluster-API fleet you already operate — and the honest answer depends on scale, bandwidth, and how much of the adjacent machinery you already own.

This post prices both sides with real published numbers, maps the DIY architecture onto CAPH-provisioned Hetzner nodes, and ends with an explicit decision rule.

The flow every multi-tenant PaaS has to build​

Strip away vendor branding and every custom-domain feature is the same four-step pipeline. A tenant declares a domain, the platform verifies they control it (DNS TXT record or an HTTP token file), the platform obtains a certificate for it from an ACME CA like Let's Encrypt, and the edge starts routing that hostname to the tenant's app with TLS terminated. Then a fifth step runs forever: renew every certificate before its 90-day expiry, monitor for failures, and handle the abuse case — anyone on the internet can point DNS at your IP, and your pipeline must not mint certificates for hostnames nobody verified.

Each step is a trust and uptime surface, not a feature checkbox. Verification is a security boundary: get it wrong and one tenant serves traffic on another tenant's domain. Renewal is a background reliability problem: a single stuck renewal is a customer-facing outage with a 90-day fuse.

Abuse handling is a rate-limit survival problem: an ungated issuance path lets an attacker burn through your ACME quota with throwaway domains. Whoever owns custom domains owns all of this, whether that owner is your team or a vendor's API.

What Approximated actually sells (all three plans)​

Approximated's pitch is deliberately boring infrastructure: you make one API call per domain, the tenant points one DNS A record at your cluster's dedicated IP, and certificates appear and renew themselves. The company claims years in production serving millions of custom domains with terabytes of traffic and thousands of concurrent connections per customer, and it ships framework guides for Django, Rails, Laravel, Next.js, Nuxt, SvelteKit, and TanStack Start. What matters for a build-vs-buy decision is that there are three distinct products, with very different "what runs where" answers.

The cloud plan is the fully managed version: Approximated spins up a dedicated cluster with edge nodes distributed globally, traffic routes through the nearest region, and certs are fully managed. Published pricing, last reviewed August 5, 2026: $0.20 per custom domain per month, a $20 monthly minimum (so 50 domains and 100 domains both bill $20), a volume discount that grows 5 percentage points per full 1,000 domains capped at 50%, 400 GB of included bandwidth, and $0.05 per GB above that. Their own examples: 1,000 domains cost $190/month in domain charges, 10,000 cost $1,000.

The hybrid self-hosted plan splits the difference: you keep using Approximated's cloud API and dashboard, but traffic and SSL certificates run strictly through your own infrastructure. That split exists for regulatory and procurement reality — for many organizations, running tenant traffic and private key material through a third party is the part that triggers review, while configuration metadata in someone else's dashboard is not. Pricing is $199/month base plus $0.10 per virtual host per month, and Approximated recommends it for almost all self-hosted scenarios unless you need a local API and dashboard.

The full self-hosted plan is complete detachment from Approximated's cloud: independent installation, custom SLAs, starting at $4,999/month. Note the honest caveat on the tin — features that depend on cloud infrastructure may arrive late or never on the fully detached version. You are paying for independence, not for parity.

For a pricing anchor outside Approximated, Cloudflare's SSL for SaaS charges $0.10 per custom hostname per month beyond 100 included hostnames — the number every other vendor in this space is implicitly competing with.

The cost table: 100 vs 1,000 vs 10,000 domains​

Here is the all-in monthly comparison. Two assumptions are stated up front because they decide the close calls. First, bandwidth: the table below covers domain charges only, and I work the bandwidth sensitivity right after it. Second, DIY: marginal infrastructure on a fleet you already run is near zero — the edge gateway already exists — so the DIY row prices the one-time build (estimated below) plus ongoing ops instead of pretending it is free.

The crossovers are the story. Below roughly 100 domains, Cloudflare's free tier and Approximated's $20 minimum make buying nearly free — no DIY build pays back at that scale. Between 1,000 and 10,000 domains, Approximated's volume discount and Cloudflare's flat $0.10 converge around $1,000/month, while hybrid's $199 base keeps it slightly above both. Full self-hosted at $4,999 never wins on price; it wins only when "no third party in the data or control path" is a requirement rather than a preference.

Now the bandwidth sensitivity, because $0.05/GB over 400 GB is where the cloud plan's bill can quietly double. If your 1,000 tenant domains are brochure sites averaging 0.4 GB/month each, total egress is 400 GB and the overage is $0.

If they average 2 GB each — small apps with real traffic — that is 2 TB total, roughly 1.6 TB over the allowance, adding about $80/month. At 10,000 domains those same 2 GB averages mean 20 TB total and nearly $1,000 in overage alone. Light-tenant fleets can ignore this row; media-heavy or high-traffic tenant mixes must add it before comparing against DIY, where egress is already priced into the Hetzner flat rate.

And the DIY side, honestly estimated: building the verification-plus-issuance-plus-renewal flow (TXT verification flow, issuance gating, renewal monitoring, tenant-facing domain status) is roughly one to three engineering weeks against Caddy or cert-manager, plus roughly half a day a month of ongoing ops — watching renewal metrics, tracking ACME policy changes, and handling the occasional stuck order. At typical salary cost that is a few thousand dollars one-time and a few hundred a month amortized. The payback math follows directly: DIY beats a $1,000/month vendor bill within the first year at 10,000-domain scale, and never pays back at 100-domain scale. There is no universal winner; there is a scale at which the lines cross, and it sits somewhere in the low thousands of domains for most teams.

The DIY path on a Cluster-API fleet​

If you build, there are two proven architectures, and on a Cluster-API fleet both run in-fleet on CAPH-provisioned Hetzner nodes behind the platform's own Gateway — no new vendor, no new region, no data leaving machines you own.

Option A: Caddy with on-demand TLS. Caddy terminates TLS at the edge and issues a Let's Encrypt certificate on first connection for any hostname it serves — gated by an ask endpoint, an HTTP URL Caddy queries with the hostname before issuing. Your platform's control plane answers 200 only for verified tenant domains and 403 otherwise. The moving pieces are small: Caddy as a DaemonSet or Gateway deployment, the ask handler (a few dozen lines against your domain registry), and shared storage for Caddy's certificate state so any replica can serve any handshake. This is the fastest DIY path and the one most small platforms standardize on.

Option B: cert-manager plus Gateway API. Each verified tenant domain becomes an HTTPRoute (hostname match to the tenant's Service) and a Certificate object; cert-manager handles ACME issuance and renewal per object. Your control plane generates both resources when a domain verifies. This is more Kubernetes-native — routes and certs are declarative objects with status conditions your existing monitoring already understands — at the cost of more objects to manage per tenant (one HTTPRoute plus one Certificate per domain, so 10,000 domains is 20,000 objects the API server and controllers reconcile).

Either way, the same three gotchas decide whether your DIY build survives contact with production. First, Let's Encrypt rate limits: 50 certificates per registered domain per week is the famous one, but the operational binding constraint for a platform is new-order throughput per ACME account — a bulk tenant import or a retry storm after an outage can stall issuance for hours unless you queue, back off, and spread load across accounts. Second, abuse gating: without the ask endpoint (Caddy) or a verified-only issuance gate (cert-manager), anyone pointing DNS at your edge exhausts your ACME quota with domains you never agreed to serve — this gate is load-bearing, not optional. Third, renewal monitoring: issuance is the demo, renewal is the product; you need per-certificate expiry metrics, alerts well inside the 30-day renewal window, and a runbook for stuck orders, because a silent renewal failure is an outage with a three-month fuse.

The fleet-specific part is where cert state and route objects live in your upgrade story. Caddy's cert storage must survive node replacement — a Machine rolling upgrade that wipes local cert state forces mass re-issuance against rate limits, so that storage belongs on a persistent volume or shared backend from day one. The cert-manager path inherits CAPI's usual object-migration story instead, but puts per-tenant scale pressure on the API server and controllers that a 100-domain fleet never felt. Neither is a reason not to build; both are reasons to build deliberately rather than discovering them during your first incident.

Beyond price: the ops surface you're buying or building​

Price converges; operational surface does not. With Approximated cloud, the domain-verification-to-live-traffic path runs through a vendor API, a vendor edge, and vendor cert storage — your on-call owns the integration (API calls, webhook handling, tenant status mapping) but never debugs issuance at 3 a.m. The failure modes you inherit are vendor-shaped: API outages, edge-region issues, and pricing changes, all outside your control plane.

With hybrid, the data path and key material move onto your machines while the control API stays in Approximated's cloud — you own edge uptime and cert storage, they own the dashboard and API semantics. With DIY, every layer is yours: the ask gate, the ACME client behavior, the renewal monitoring, the edge capacity planning. Your on-call owns issuance incidents end to end, and in exchange no vendor outage, acquisition, or pricing change can move your unit economics.

There is also a quieter cost to the vendor path: one more component in the domain-verification-to-live-traffic path tomorrow. Every vendor in that path is a second status page to check during a tenant-facing TLS incident, a second auth credential to rotate, and a second API whose deprecations land on your roadmap uninvited.

For a platform that already owns the gateway, the DNS flow, and the tenant registry, adopting a purpose-built third-party layer for the one missing primitive — automated issuance — means the incident-debug path for "customer domain shows cert error" now spans two organizations. That is sometimes worth it. It is never free.

The decision rule​

Buy Approximated (or Cloudflare for SaaS) when speed matters more than unit cost: pre-launch, under a few hundred domains, a team with no spare on-call capacity, or a compliance posture where hybrid's "traffic and keys on our machines, dashboard in their cloud" clears review faster than a homegrown build. The $20 minimum and the free tiers exist precisely for this phase, and building a cert pipeline before product-market fit is a classic misallocation.

Build the primitive into your own control plane when you already own every adjacent piece — the gateway, the tenant registry, the DNS verification flow — and your domain count is heading into the thousands, where vendor bills cross $500–$1,000/month and the DIY payback drops under a year. That is exactly the bex-shaped position: a Cluster-API PaaS already reconciles machines, routes, and tenant state declaratively, so per-tenant HTTPRoutes and Certificates are one more controller loop on infrastructure the platform operates anyway, not a new system to stand up. The platform that owns the fleet should own the issuance gate too, because it already owns both sides of it.

The uncomfortable middle — hundreds of domains, growing fast, small team — is where hybrid earns its keep: vendor API velocity today, your machines under the traffic, and a clean migration to full DIY later since the data path never lived anywhere else.

Owning the last mile of your tenants' domains​

Custom domains are the last mile of multi-tenancy: the feature where your platform's reliability becomes visible under somebody else's brand. Approximated's three plans price that last mile honestly — $20 to start, a few hundred at platform scale, $4,999 for full detachment — and for many teams that is exactly the right trade. But for a self-hosted PaaS already running its own gateway on its own machines, automated issuance is a controller loop, not a product category. Build it once, monitor renewals like production depends on it — because it does — and keep the domain-verification-to-live-traffic path inside the control plane you already own.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.