Custom domains

Every site starts on a managed.dev preview URL. When you’re ready to go live you attach one or more custom domains — the hostnames your visitors actually type. You add a domain to a site, verify you own it, point its DNS at managed.dev, and pick which hostname is primary. TLS is issued automatically, so the site serves HTTPS from the first request after cutover.

Add a domain

Domains are attached to a site, and each domain resolves to a specific environment — usually production. You can add a bare apex (example.com), a subdomain (www.example.com or shop.example.com), or both.

The Domains screen for a site in the app.managed.dev dashboard: a list of attached domains with their verification state and a “primary” tag on one row, plus an “Add domain” button.

Open your site in the dashboard and go to the Domains tab.
Choose Add domain and enter the hostname, for example www.example.com. Select the environment it should resolve to (production by default).
managed.dev shows you the DNS records to create and a verification record. Leave the screen open while you update DNS at your registrar.

You can do the same thing over the API once your keys are minted:

cURL
mf CLI

curl https://api.managed.dev/v1/sites/site_01J7.../domains \
  -H "Authorization: Bearer mfk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "hostname": "www.example.com", "environment_id": "env_01J8..." }'

mf domains add www.example.com \
  --site site_01J7... \
  --environment env_01J8...

Verify ownership

Before managed.dev will serve a domain — and before it requests a certificate — you have to prove you control it. Verification uses a TXT record (or, for apexes you delegate to us, the act of pointing the nameservers themselves). The exact record is shown on the Domains screen; add it at your DNS provider and the status flips to verified, usually within a few minutes of propagation.

Verification is also what protects you from someone else claiming a hostname they don’t own, so it can’t be skipped.

Point DNS

Once verified, point the hostname at your site’s public address target. managed.dev gives you the exact value to use on the Domains screen — you never guess an IP.

For a subdomain like www.example.com, create a CNAME to the target managed.dev shows you.
For an apex like example.com, create an A record (and AAAA for IPv6) to the address target shown, or use your provider’s apex-flattening / ALIAS record if it has one.

If managed.dev is also running your DNS, these records are created for you — see DNS records.

Set the primary domain

A site can carry several domains, but exactly one is the primary hostname. The primary is the canonical address: it’s what WordPress treats as the site URL, what appears in generated links and sitemaps, and where other domains redirect to. Mark a domain primary from the Domains tab, or set up the non-primary ones to forward with redirects (for example apex → www, or the reverse).

The preview URL before cutover

Your managed.dev preview URL keeps working before, during, and after you attach a custom domain. That’s deliberate: you can build and QA the production environment on its preview hostname, share it for sign-off, and only move real traffic when DNS flips. Nothing about the cutover rebuilds or redeploys the site — the same running environment simply starts answering on the new hostname once its certificate is ready.

Preview and staging environments also keep their own hostnames the whole time, under a per-node label like <env>.<node-label>.<zone>, so a custom domain on production never disturbs the URLs your team reviews branches on.

Next steps

DNS recordsRun your DNS on managed.dev or keep it external — and when you need our DNS for wildcard certs.

TLS certificatesHow automatic HTTPS works, including per-node wildcard certs for environments.

Go-live checklistDomain → DNS → TLS → cache → search-replace, the whole launch in order.

RedirectsForward apex to www (or the reverse) and map legacy URLs.