Configuring Custom Domains

If you plan on offering subdomains like *.acme.com, add a wildcard domain to your Vercel project. Vercel needs access to DNS challenges to issue and renew wildcard certificates. To configure the domain with Vercel's nameservers:

1. Point your domain to Vercel's nameservers (ns1.vercel-dns.com and ns2.vercel-dns.com).
2. In your Vercel project settings, add the apex domain (e.g., acme.com).
3. Add a wildcard domain: *.acme.com.

If you can't change your domain's nameservers, follow Use wildcard domains with an external DNS provider to delegate certificate validation and configure wildcard traffic routing.

Now, any tenant subdomain you create, such as tenant1.acme.com or tenant2.acme.com, resolves to your Vercel deployment. Vercel issues one wildcard certificate for *.acme.com that covers every tenant subdomain at that level, so you don't need a certificate per tenant. A wildcard certificate covers only one subdomain level. To serve a deeper subdomain such as docs.tenant1.acme.com over HTTPS, add a wildcard domain for that level, such as *.tenant1.acme.com, which gets its own wildcard certificate.

If tenants can publish content or run code on your subdomains, submit your shared domain to the Public Suffix List (PSL). The PSL is a public list of domains, such as vercel.app, whose subdomains belong to different owners. Browsers read the list and treat each subdomain of a listed domain as its own site.

Without a PSL entry, browsers treat tenant1.acme.com and tenant2.acme.com as part of the same site. This affects how browsers scope cookies and apply SameSite rules.

For example, tenant1.acme.com can set a cookie with Domain=acme.com. The browser then sends that cookie to tenant2.acme.com, app.acme.com, and the apex domain. This can add unwanted cookies to requests for another tenant or your dashboard.

Submit the domain that sits directly above each tenant name:

• For <tenant>.acme.com, submit acme.com
• For <tenant>.sites.acme.com, submit sites.acme.com

After receiving the PSL update, browsers treat each tenant subdomain as a separate site. Browsers also block tenant attempts to set cookies for the shared domain. You don't need to submit custom domains that tenants own.

The PSL's private section covers domains that give subdomains to parties that do not trust each other. Adding an entry changes existing cookie and sign-in behavior.

Before you submit, test parent-scoped cookies, cross-subdomain sign-in, and code that identifies a site from its hostname. Then follow these steps:

1. Confirm that your service meets the PSL private-domain criteria. Only an authorized representative of the domain owner can submit the change.
2. Add the exact shared suffix to the PRIVATE DOMAINS section with the required company header and sort order.
3. Open a pull request with your service details, example domains, and expected site boundaries in the required template.
4. Create a permanent _psl.<suffix> DNS TXT record that contains the pull request URL.
5. Respond to the maintainers' review.
6. Wait for browsers and other clients to receive the updated list after the maintainers merge the change.

The PSL maintainers do not guarantee a review time. After a change is merged, each browser receives the update on its own schedule.

PSL review and browser updates can take time. Use these controls until browsers recognize your shared domain:

• Put your dashboard and authentication service under a different apex domain when possible. For example, use app.acme.net for tenants under *.acme.com.
• Prefix sensitive cookie names with __Host-.
• Set Secure, HttpOnly, and Path=/ on session cookies. Omit the Domain attribute.
• Validate the Origin header or use a cross-site request forgery token for requests that change data.

A cookie without a Domain attribute is only sent to the host that set it. For example, set a session cookie with this response header:

Set-Cookie: __Host-session=your_session_value_here; Secure; HttpOnly; Path=/; SameSite=Lax

Browsers that support __Host- reject prefixed cookies with a Domain attribute or a path other than /. This prevents a sibling tenant from setting __Host-session for your host.

The __Host- prefix does not change SameSite behavior, so keep the Origin or cross-site request forgery token checks. These controls add protection but do not replace a PSL entry.

You can also give tenants the option to bring their own domain. In that case, you'll want your code to:

1. Provision and assign the tenant's domain to your Vercel project.
2. Verify the domain (to ensure the tenant truly owns it).
3. Automatically generate an SSL certificate.

You can add a new domain through the Vercel SDK. For example:

import { VercelCore as Vercel } from '@vercel/sdk/core.js';
import { projectsAddProjectDomain } from '@vercel/sdk/funcs/projectsAddProjectDomain.js';
 
const vercel = new Vercel({
  bearerToken: process.env.VERCEL_TOKEN,
});
 
// The 'idOrName' is your project name in Vercel, for example: 'multi-tenant-app'
await projectsAddProjectDomain(vercel, {
  idOrName: 'my-multi-tenant-app',
  teamId: 'team_1234',
  requestBody: {
    // The tenant's custom domain
    name: 'customacmesite.com',
  },
});

Once the domain is added, Vercel attempts to issue an SSL certificate automatically. Each custom domain gets its own certificate, separate from your wildcard certificate.

If the domain is already in use on Vercel, the user needs to set a TXT record to prove ownership of it.

You can check the verification status and trigger manual verification:

import { VercelCore as Vercel } from '@vercel/sdk/core.js';
import { projectsGetProjectDomain } from '@vercel/sdk/funcs/projectsGetProjectDomain.js';
import { projectsVerifyProjectDomain } from '@vercel/sdk/funcs/projectsVerifyProjectDomain.js';
 
const vercel = new Vercel({
  bearerToken: process.env.VERCEL_TOKEN,
});
 
const domain = 'customacmesite.com';
 
const [domainResponse, verifyResponse] = await Promise.all([
  projectsGetProjectDomain(vercel, {
    idOrName: 'my-multi-tenant-app',
    teamId: 'team_1234',
    domain,
  }),
  projectsVerifyProjectDomain(vercel, {
    idOrName: 'my-multi-tenant-app',
    teamId: 'team_1234',
    domain,
  }),
]);
 
const { value: result } = verifyResponse;
 
if (!result?.verified) {
  console.log(`Domain verification required for ${domain}.`);
  // You can prompt the tenant to add a TXT record or switch nameservers.
}

Some tenants might want www.customacmesite.com to redirect automatically to their apex domain customacmesite.com, or the other way around.

1. Add both customacmesite.com and www.customacmesite.com to your Vercel project.
2. Configure a redirect for www.customacmesite.com to the apex domain by setting redirect: customacmesite.com through the API or your Vercel dashboard.

This ensures a consistent user experience and prevents issues with duplicate content.

If you offer both tenant.acme.com and customacmesite.com for the same tenant, you may want to redirect the subdomain to the custom domain (or vice versa) to avoid search engine duplicate content. Alternatively, set a canonical URL in your HTML <head> to indicate which domain is the "official" one.

If a tenant cancels or no longer needs their custom domain, you can remove it from your Vercel account using the SDK:

import { VercelCore as Vercel } from '@vercel/sdk/core.js';
import { projectsRemoveProjectDomain } from '@vercel/sdk/funcs/projectsRemoveProjectDomain.js';
import { domainsDeleteDomain } from '@vercel/sdk/funcs/domainsDeleteDomain.js';
 
const vercel = new Vercel({
  bearerToken: process.env.VERCEL_TOKEN,
});
 
await Promise.all([
  projectsRemoveProjectDomain(vercel, {
    idOrName: 'my-multi-tenant-app',
    teamId: 'team_1234',
    domain: 'customacmesite.com',
  }),
  domainsDeleteDomain(vercel, {
    domain: 'customacmesite.com',
  }),
]);

The first call disassociates the domain from your project, and the second removes it from your account entirely.

Here are a few common issues you might run into and how to solve them:

After pointing your nameservers to Vercel or adding CNAME records, changes can take 24–48 hours to propagate. Use WhatsMyDNS to confirm updates worldwide.

If you add a tenant's domain but never verify it (e.g., by adding a TXT record or using Vercel nameservers), SSL certificates won't be issued. Always check the domain's status in your Vercel project or with the SDK.

For *.acme.com, Vercel needs access to DNS challenges to issue and renew the wildcard certificate. Check that the apex domain uses Vercel's nameservers, or follow Use wildcard domains with an external DNS provider to delegate _acme-challenge to Vercel.

Each DNS label has a 63-character limit. If you have a very long branch name plus a tenant subdomain, the fully generated preview URL might fail to resolve. Keep branch names concise.

If the same site is served from both subdomain and custom domain, consider using canonical tags or auto-redirecting to the primary domain.

A small typo can block domain verification or routing, so double-check your domain spelling.