Custom domains and DNS

A new app answers on a *.vercel.app address. Pointing your own domain at it takes one setting and one DNS record.

Set the domain

In the console, set the project's domain on the configure screen, or after the first deploy in the project's What next? list, which adds it and deploys. In launchpad.json:

{ "domain": "app.example.com" }

On the next deploy, Launchpad adds the domain to the Vercel project and prints the DNS record to add. Once the record is live, Vercel issues the certificate, usually within a few minutes.

Let Launchpad add the record

If the domain's DNS is on Cloudflare, Launchpad can add the records itself:

{ "domain": "app.example.com", "dns": { "provider": "cloudflare" } }

The Cloudflare token then needs Zone → DNS → Edit and Zone → Read for that zone.

How it behaves:

• It adds the record Vercel asks for, and Resend's records for your sending domain.
• Records are added DNS-only, not proxied, so the certificate can be issued.
• It never overwrites. A record that already exists is left alone, and one that would clash is left on the Still to do list for you to decide.
• A teardown removes only the records Launchpad added.

A domain for a background API

A web process can have its own domain:

"processes": [{ "name": "api", "type": "web", "domain": "api.example.com" }]

The web app can then be given its address automatically, as shown in Environment variables and secrets.

Things worth knowing

• Apex domains (example.com with no www) need their DNS on a provider that supports the record Vercel asks for; on Cloudflare this works, elsewhere a redirect from www may be simpler.
• Team projects on Vercel protect their *.vercel.app address by default, so before a domain is added only signed-in team members can see the app. Turn that off in the project's Deployment Protection settings, or add the domain.
• Sign-in redirects, bot protection and storage CORS all follow the domain automatically once it's set.