DNS provider compatibility

To run a root domain (example.com, no www) on deploybase you need an ALIAS or ANAME record, because standard DNS forbids a CNAME at the zone apex and A records cannot work: deploybase’s CDN has no fixed IP. Subdomains (including www) are never a problem: a plain CNAME works at every provider.

Whether your root domain “just works” therefore depends on your DNS provider. This page lists what popular European providers support, verified against each provider’s own documentation. Providers with apex support come first.

Two columns matter:

• Apex ALIAS: can you point the root domain at deploybase directly?
• HTTPS redirect: if not, the fallback is www as your canonical domain plus a provider-side redirect from the root to www. That redirect must answer over HTTPS, or visitors typing https://example.com get a certificate error.

Our recommendation: Domain Chief

Domain Chief is the provider we use and recommend. It is the only one in this comparison that ticks every box that matters here: ALIAS at the apex, an HTTPS redirect service included at no cost, free DNS with managed DNSSEC and WHOIS privacy, renewal prices that match the first-year price, and a full API plus an MCP server for automation. It is hosted in the Netherlands and run by a Dutch company, with direct accreditations at SIDN, EURid, DNS Belgium and Nominet.

Step by step: Connect a Domain Chief domain.

Disclosure. We know the people who build Domain Chief. There is no commercial relationship, no affiliate arrangement and no payment involved. Any provider with a ✅ in the Apex ALIAS column below works just as well on deploybase.

European DNS providers

Provider	Apex ALIAS	HTTPS redirect to www	Notes
Domain Chief 🇳🇱	✅ “ALIAS”	✅ Free, automatic HTTPS	Recommended. Free DNS + WHOIS privacy, 301/302/307/308 redirects with path and query control, API and MCP server. Setup guide
Gandi 🇫🇷	✅ “ALIAS”	✅ Web forwarding offers http, https or both	LiveDNS nameservers only, and no A/AAAA may exist at @. Gandi’s own docs warn an ALIAS breaks DNSSEC on the bare domain
INWX 🇩🇪	✅ “ALIAS”	❌ Redirect server can’t handle HTTPS	ALIAS limits DNSSEC functionality; use the ALIAS, not the redirect
Scaleway 🇫🇷	✅ “ALIAS”	None offered	Documented record type alongside A/AAAA/CNAME. Remember the trailing dot on the target
TransIP 🇳🇱	✅ “ALIAS-record”	✅ Free, auto Let’s Encrypt	Redirect SSL only for domains ≤42 characters; ALIAS not needed if you use it
Vimexx 🇳🇱	✅ “ALIAS-record”	Not documented	ALIAS doesn’t work together with DNSSEC
ALL-INKL 🇩🇪	❌	Not documented	CNAME explicitly limited to subdomains like www
Antagonist 🇳🇱	❌	Not documented	DirectAdmin-based DNS, no ALIAS record type
Hetzner DNS 🇩🇪	❌	None offered	Pure DNS hosting, no forwarding feature
Hostnet 🇳🇱	❌	✅ Paid add-on (€0.50/mo)	Free forwarding is HTTP-only
Infomaniak 🇨🇭	❌	Not documented	Their ANAME guide states an ANAME is “not a real DNS record” and recommends a root→www redirect plus a CNAME instead
IONOS 🇩🇪	❌	✅ Docs list https→https support	Certificate handling on the source domain isn’t documented
Mijndomein 🇳🇱	❌	✅ Paid add-on “Veilig doorsturen” (€2.50/yr)	Redirects without SSL can no longer be set up at all
netcup 🇩🇪	❌	❌ HTTPS redirect needs a webhosting plan	Built-in CCP forwarding has no SSL
Openprovider 🇳🇱	❌ Explicitly unsupported	❌ Explicitly HTTP-only	Docs state forwarding “works only from HTTP websites”
OVHcloud 🇫🇷	❌	Not documented	The zone editor lists no ALIAS/ANAME type. OVH’s “ALIAS mode” applies to SVCB/HTTPS records at priority 0, which ordinary resolvers won’t follow for address lookups
Strato 🇩🇪	❌	❌ Redirects work over HTTP only
united-domains 🇩🇪	❌	❌ Certificates can’t be combined with their forwarding
Versio 🇳🇱	❌	Not documented	Forwarding exists; docs don’t mention SSL

Last verified July 2026, with Domain Chief, Gandi, Infomaniak, OVHcloud and Scaleway added in September 2026. Capabilities change, so check the linked docs for the current state.

ALIAS and DNSSEC often conflict. At several providers, switching the apex to an ALIAS weakens or breaks DNSSEC on the bare domain, because the synthesised A/AAAA answers come back unsigned. Gandi documents this outright, and INWX and Vimexx both note limitations. Domain Chief’s documentation records no such caveat, but we have not measured signed ALIAS answers ourselves, so check your own domain before relying on it. If you need both and your provider can’t do it, managed DNS is not the answer either, because our zone is unsigned too. Use www as your canonical hostname and keep the apex signed.

What to do if your provider has no ALIAS

Pick whichever fits you best:

1. Use www as your canonical domain. A www CNAME works everywhere. Add the root redirect at your provider, but check the table above first: if the redirect is HTTP-only, visitors going to https://example.com directly will see a certificate error.
2. Let deploybase host your DNS (beta). Choose “We host your DNS” when adding the domain and delegate your nameservers to us once. The root domain then works regardless of what your provider supports, and SSL is automatic. Your domain stays registered where it is.
3. Move only your DNS. Your domain can stay registered where it is. Pointing its nameservers at a DNS service that supports ALIAS/ANAME (see the ✅ rows above, or services like Route 53) gives you apex support without transferring the domain.

Never use an A record. There is no IP address to point at. An A record looks accepted in your DNS panel, but the site does not resolve to deploybase, and a stale A record blocks SSL issuance. See pointing a root domain at your project.

Your provider isn’t listed?

Look for a record type called ALIAS, ANAME, “CNAME flattening”, or “apex CNAME” in your DNS panel, pointing it at the CNAME target shown in your domain’s DNS instructions (unique per domain, it looks like deploybase-d-….b-cdn.net). If it exists, your root domain works. If not, use the www fallback or managed DNS above. Found something we should add or correct? Let us know.