Preview URLs on Your Own Domain — Without Handing Us Your DNS

Starting today, PreviewDrop previews can live on your domain. Instead of

https://prv-a8c2f9.previews.previewdrop.dev

your Pro or Team workspace can serve

https://prv-a8c2f9.previews.yourcompany.com

— same containers, same build pipeline, same auto-expiry, but the link your client, your QA team, or your PR reviewer opens carries your name, not a hosting vendor's.

Why this matters more for some teams than others

If your previews are internal, the URL is cosmetic. But two groups have been asking for this since launch:

Agencies. When you send a client a preview link, that link is the deliverable for the day. previews.youragency.com reads like your infrastructure; a vendor subdomain reads like a shortcut. Same passwords, same QR codes, same self-destructing TTL — on your brand.

Teams with strict link policies. Some organizations filter or flag external hosting domains in email and chat. A preview on your own domain travels through those filters the way the rest of your links do.

The setup: three DNS records, once

Add your domain in the project's settings, and PreviewDrop shows you exactly three records to create:

| Type | Record | Purpose | |---|---|---| | TXT | _previewdrop-verify.previews.yourcompany.com | Proves you control the domain | | CNAME | *.previews.yourcompany.com → previews.previewdrop.dev | Routes preview traffic | | CNAME | _acme-challenge.previews.yourcompany.com → acme-delegate.previewdrop.dev | Delegates certificate issuance |

The dashboard checks each record individually and tells you which one is missing or wrong — a typo in your DNS panel is a ten-second fix, not a support ticket. Once all three verify, every deploy for that project comes out on your domain: pushes, PR previews, API deploys, MCP deploys, all of them.

One caveat worth knowing up front: the records must be plain DNS entries. If your provider proxies traffic (orange-cloud style), turn the proxy off for these records — the routing CNAME needs to resolve to us directly.

The interesting part: wildcard TLS with zero access to your DNS

Every preview needs HTTPS, and previews on *.previews.yourcompany.com need a certificate for your domain. The usual ways to get one are all bad: you upload certificates to us (and renew them forever), or you hand us API access to your DNS provider (which nobody should do for a preview tool).

We use neither. The third record above — the _acme-challenge CNAME — is an ACME DNS-01 delegation. When Let's Encrypt asks "prove you control this domain," it follows that CNAME into a zone we control, where our infrastructure answers the challenge. The result is a wildcard certificate for your domain, issued and renewed automatically, while your DNS credentials never leave your DNS provider.

You can verify the issuance yourself once it's live:

echo | openssl s_client -connect prv-yourpreview.previews.yourcompany.com:443 2>/dev/null \
  | openssl x509 -noout -subject -issuer
# subject=CN=*.previews.yourcompany.com
# issuer=C=US, O=Let's Encrypt, ...

No lock-in, by design

Remove the DNS records — or remove the domain from the project, or downgrade your plan — and previews fall back to the default previews.previewdrop.dev URLs on the next deploy. Nothing breaks, no deploy fails; the links just come out on the default domain again. The domain is a routing preference, not a dependency.

Available now

Custom preview domains are included on Pro ($79/mo) and Team ($149/mo) — no add-on fee, no per-domain charge. The domain card is in your project's Settings tab.

If you've been sending clients vendor-branded preview links, this is the day that stops.