Entri alternative (2026)

If you are looking for an Entri alternative, you are almost certainly solving one specific problem: your customers have to connect their own domains to your product, and doing it by hand generates support tickets you did not budget for.

This page is an evaluation guide, not a takedown. Entri is a real product solving a real problem, and for plenty of teams it is the right answer. What follows is how to compare it against anything else — including us — on the dimensions that actually determine whether your support queue gets shorter.

We build one of the alternatives, so read this with that in mind. Every claim we make about our own behaviour below is checkable against our API, and where we do not do something we say so.

Start by naming which problem you have

"Custom domain onboarding" bundles several jobs. Vendors are strong at different ones, and a feature grid hides that.

1. Guided manual setup. Show the customer exactly which record to create, in the words their own registrar uses. Every vendor does some version of this; they differ enormously in how many registrars they cover properly.
2. Automatic record writing. Write the record on the customer's behalf, via the DNS provider's API or an OAuth grant, so the customer never types anything. This is where the ticket volume actually goes to zero — and where coverage claims deserve the most scrutiny.
3. Certificate issuance and renewal. Get and keep a TLS certificate for every connected hostname.
4. Serving the traffic. Some products stop at DNS and hand you the request; others terminate TLS and proxy to your origin.
5. Telling you the truth about state. Distinguishing "record created" from "actually live" for every domain, continuously.

Decide which of these you need before comparing anything. A vendor that is excellent at (1) and absent at (5) will feel great in a demo and poor in production.

The questions that actually separate vendors

"How many providers do you support?" is the wrong question

Every vendor's number is large and none of them mean the same thing. Ask instead:

• How many can you write records to automatically, without the customer leaving my app? This is the number that reduces tickets. It is always much smaller than the headline number.
• How many are guided-manual only? Perfectly fine — but it is a different product experience, and you should know the split.
• What happens for a provider you have never seen? The honest answer is "generic instructions". A vendor that claims universal automatic coverage is describing something that is not achievable: it requires either a published API or a Domain Connect template from each provider, and most registrars have neither.

For reference, our own census covers 63 DNS providers, of which a minority support a fully automatic rail — Domain Connect templates, native OAuth, or a customer-supplied API token. The rest are guided manual with provider-specific instructions. We publish which is which rather than averaging them into one number.

Apex domains

Ask directly: what happens when my customer wants to connect example.com and not app.example.com?

A root domain cannot hold a CNAME (RFC 1034 §3.6.2), so this always requires either a provider-specific ALIAS/ANAME record or A records to published addresses. A vendor that has not thought about this will either refuse the apex or, worse, accept it and fail later. Ask what happens specifically on GoDaddy and Namecheap, neither of which has an ALIAS type.

CAA records

Ask: what do you do when a domain publishes a CAA record that excludes your certificate authority?

This is the single most common silent certificate failure. The correct answer involves checking CAA before attempting issuance and telling the customer what to change. An answer that does not mention CAA at all is a signal that you will be debugging this yourself.

Propagation

Ask: how do I know a domain is live, and how do you distinguish "not propagated yet" from "typed it wrong"?

The answer should involve polling authoritative nameservers, not the vendor's own resolver cache and not a fixed timer. Ask specifically how negative caching is handled: a resolver that was queried before the record existed will remember the absence for the zone's SOA minimum (RFC 2308 §5) — an hour on some registrars — and a vendor that reports "live" based on its own lookup will be wrong for your customer.

Where the traffic goes

Ask: do you terminate TLS and proxy to my origin, or do I still have to handle the request?

Both models are legitimate and they have very different integration costs. If a vendor only handles DNS and certificates, you still need your own edge that recognises every customer hostname. If a vendor proxies, ask about latency, regions, and what happens to WebSockets and streaming responses.

Pricing shape, not price

Ask: what does the 10,000th domain cost, and what does an idle domain cost?

Per-domain pricing and flat-tier-with-included-volume pricing produce very different bills at scale, and most custom-domain portfolios have a long tail of domains that are connected and barely used. Model your own distribution against both shapes before comparing headline numbers.

For our part, pricing is flat tiers with included volume — you know what a domain costs before you connect it — and there is a free tier with 10 connections a year for integrating and testing.

A comparison worth running yourself

Feature grids are easy to write and easy to game. Run this instead, against any vendor including us, before you commit:

1. Take five real domains from five different registrars in your actual customer base — not five you picked because they are easy.
2. Include at least one apex domain and at least one on a registrar with no ALIAS support.
3. Connect each one through the vendor's real flow, as a customer would.
4. Count: how many completed with zero manual DNS entry? How many needed instructions? How many failed outright?
5. Now break one deliberately — add a conflicting A record, or a CAA record naming a different authority — and see whether the vendor tells you what is wrong or just says "pending".

Step 5 is the one that separates products. Anything can report success.

What we do and do not do

Honest scope, so you can rule us out quickly if we are wrong for you:

• We do: provider detection from authoritative nameservers, per-provider guided instructions, automatic record writing where the provider exposes a rail, apex handling including A-record realization for providers with no ALIAS, certificate issuance and renewal, CAA conflict detection before issuance, continuous authoritative-nameserver polling with drift detection, an embeddable widget, a REST API, webhooks, and an MCP server for agent-driven setup.
• We also do, on higher tiers: a reverse-proxy edge that terminates TLS and forwards to your origin, so you do not need your own hostname-aware edge.
• We do not: sell domains, act as a registrar, or manage your whole DNS zone. We touch the records needed for the connection and leave the rest alone.
• Automatic coverage is partial, by construction. Where a provider has no API, no OAuth and no Domain Connect template, we render provider-specific manual instructions rather than pretending otherwise.

Related

• Choosing a custom-domain solution — the broader build-versus-buy decision.
• How to connect a custom domain — the mechanics, if you are evaluating building it yourself.
• Quickstart — connect a domain through our API in a few minutes and judge it directly.