Skip to main content
Laravel Cloud provides two types of domains for each environment: an automatically assigned laravel.cloud domain and any custom domains you connect.
Domain stuck verifying? Read our docs on verifying domains.

Cloud domains

Each environment is assigned a free laravel.cloud domain after its first successful deployment. This is ideal for testing and staging before switching to your own domain. Cloud domains are constructed from your application and environment name. If you rename either, the Cloud domain will change and you will need to redeploy for the change to take effect. Since Cloud domains are frequently used for non-production environments, an X-Robots-Tag: noindex, nofollow header is automatically set on all *.laravel.cloud domains so they are not indexed by search engines. This header is not set for custom domains.

Custom domains

A custom domain lets visitors reach your application at your own address (e.g., example.com) instead of the default laravel.cloud domain. Laravel Cloud automatically provisions and renews SSL certificates for each custom domain so your site is served over HTTPS.

Add a custom domain

In the dashboard, open your environment’s Network settings and select “Add domain”. You’ll be asked to choose:
  • Wildcard support: Whether to accept traffic on all subdomains (for example, *.example.com).
  • Redirect behavior: Whether Cloud should redirect www.example.com to example.com (or the reverse).
  • Downtime preference: Whether brief downtime is acceptable during setup, or whether you need an uninterrupted transition with no gaps in service.
  • Cloudflare DNS settings: Whether your DNS is managed by Cloudflare and whether the hostname is already proxied (routed through Cloudflare’s network).
These choices determine which DNS records Laravel Cloud will ask you to add and in what order.
1

Add the domain in Laravel Cloud

Enter the domain and choose your options.
2

(Optional) Pre-verify ownership and SSL

If you selected the uninterrupted path or enabled wildcard support, add the ownership and SSL validation records first. These records let Laravel Cloud confirm you own the domain and issue an SSL certificate before any traffic is switched over. This option is only available if the hostname is not already proxied through Cloudflare’s network.
3

Point the domain to Laravel Cloud

Add the origin record(s) shown in the UI. Origin records are the DNS entries that direct your domain’s traffic to Laravel Cloud’s servers.
4

Refresh until connected

Use the Refresh action in the dashboard until the domain status shows as connected. Most domains connect within 15 minutes, but DNS propagation can occasionally take longer.

Verification paths

Laravel Cloud supports two verification approaches. The right choice depends on whether you can tolerate a brief gap in service while DNS changes take effect:
  • Real-time verification (flexible): Point the domain to Laravel Cloud first, then Laravel Cloud will verify ownership and issue an SSL certificate. This is the simplest path, but there may be a short window where the domain is not yet serving over HTTPS.
  • Pre-verification (uninterrupted): Prove ownership and issue the SSL certificate before switching traffic. This avoids any downtime or insecure window, but requires additional DNS records up front. Required for wildcard domains. This approach is only available if the hostname is not already proxied through Cloudflare’s network.

DNS records you will see in Cloud

When you open a domain’s configuration, Laravel Cloud will show the exact DNS records required for your setup. You do not need to figure out which records to create on your own — simply copy the record type, name, and value exactly as shown and add them to your DNS provider.

Origin records

Origin records are the primary DNS entries that tell the internet to send traffic for your domain to Laravel Cloud:
  • An A record maps your domain to an IP address and is common when you are not using Cloudflare DNS.
  • A CNAME record maps your domain to another hostname and is common when you are using Cloudflare DNS (Cloudflare supports CNAME flattening at the apex, which allows a CNAME on the root domain).

Ownership verification record

During pre-verification, Laravel Cloud may require a temporary TXT record to confirm that you control the domain. This record looks like: TXT _cf-custom-hostname.<your-domain> -> <value> Once ownership is confirmed, this record is no longer needed, though leaving it in place will not cause any issues.

SSL validation records

To issue an SSL certificate for your domain (so it can be served over HTTPS), Laravel Cloud may require one or more validation records: TXT _acme-challenge.<your-domain> -> <value> CNAME _acme-challenge.<your-domain> -> <value> (common for wildcard / DCV delegation) If you are using wildcard support, keep the DCV delegation CNAME record in place permanently. This record allows Laravel Cloud to automatically renew your wildcard SSL certificate — removing it will prevent future renewals.

Understanding verification status

A domain is fully connected once three components are verified:
  • Hostname: Ownership of the domain is confirmed.
  • SSL: An SSL certificate has been issued and is active, enabling HTTPS.
  • Origin: DNS is correctly routing traffic to Laravel Cloud.
As verification progresses, the dashboard will show one of the following statuses:
  • Verifying ownership: Laravel Cloud is waiting for your ownership and SSL validation DNS records to become visible. This is the propagation stage.
  • Verifying: Ownership and SSL are confirmed, but origin routing has not been detected yet. Your origin DNS record may still be propagating.
  • Connected: All three components are verified and your domain is live.
  • Timed out: Verification did not complete within the allowed window. Review your DNS records for errors and retry.
Laravel Cloud retries verification checks for approximately 12 hours before timing out, so there is no need to manually re-trigger during this period. If you are using real-time verification, visiting your domain in a browser can help Laravel Cloud detect traffic flowing through the network and speed up the final verification step.

Wildcard domains

A wildcard domain (e.g., *.example.com) allows any subdomain — such as app.example.com, api.example.com, etc. — to route to your environment without configuring each one individually. Wildcard domains require pre-verification unless the hostname is already being proxied through Cloudflare’s network. When configuring a wildcard domain:
  • Also configure the root domain example.com, so both example.com and its subdomains are covered.
  • Add the DCV delegation record shown in the UI. This record allows Laravel Cloud to continue issuing and renewing wildcard SSL certificates on your behalf.
If your DNS is managed by Cloudflare, ensure DCV delegation records under _acme-challenge are configured as DNS only (grey cloud, not proxied). Proxying these records will block certificate issuance.

Managing domains

From your environment’s domain settings, you can detach and reassign domains between environments in the same organization. You can also set a verified root domain as the primary domain for an environment. Primary domains cannot be moved or removed until they are unset as the primary domain.

Limitations

There are no limitations on the number of Cloud environments that can have a custom domain assigned to them. However, the number of custom domains you can attach to a single environment depends on your plan:
  • Starter: 1 custom domain per environment
  • Growth: Up to 5 custom domains per environment
  • Business: Up to 200 custom domains per environment
  • Enterprise: Custom
If you have a special use case for attaching many domains to a single environment (for example, multi-tenant applications), please contact us to discuss raising your limits.

Troubleshooting

For guided troubleshooting and provider-specific DNS instructions, start with: If you’re diagnosing an issue in production, Laravel Nightwatch can help you confirm whether traffic is reaching your application and whether requests are being served successfully.

Verify DNS from the terminal

You can confirm your records are publicly visible by running the following commands in your terminal. Replace example.com with your actual domain. Both dig and nslookup are shown — use whichever is available on your system:
# Which DNS provider is responsible for your domain?
dig NS example.com +short
nslookup -type=NS example.com

# Are your origin records resolving? (use the record type you configured — A or CNAME)
dig A example.com +short
dig CNAME example.com +short
nslookup -type=A example.com
nslookup -type=CNAME example.com

# Is the ownership verification record visible?
dig TXT _cf-custom-hostname.example.com +short
nslookup -type=TXT _cf-custom-hostname.example.com

# Are the SSL validation records visible? (may be TXT or CNAME depending on your setup)
dig TXT _acme-challenge.example.com +short
dig CNAME _acme-challenge.example.com +short
nslookup -type=TXT _acme-challenge.example.com
nslookup -type=CNAME _acme-challenge.example.com
If a command returns no output, the record is either missing or has not finished propagating.