Custom domains

A custom domain is a domain you own, such as shop.example.com, that serves one of your applications, static sites or load balancers over HTTPS. You add it on the service’s Domains tab, prove you own it with DNS records, then point it at Sevalla, and Sevalla issues and renews its SSL certificate. Every service also gets a free Sevalla domain, such as storefront-x7k2m.sevalla.app, that works from the start.

​

How custom domains work

Sevalla serves every domain through Cloudflare, in front of your service, using Cloudflare for SaaS custom hostnames. A custom domain goes through three steps, shown in the DNS records sheet as Add domain, Verify domain and Point domain: Sevalla checks a domain in Verification or Pointing every 30 minutes for 7 days after you add it, and every 10 seconds while its DNS records sheet is open. A domain still in Verification after 7 days becomes Timed out. In the API, the statuses are VERIFICATION, POINTING, ACTIVE and TIMED_OUT.

​

Sevalla domains and differences between services

Every application, static site and load balancer gets a Sevalla domain when you create it, listed under Sevalla domains on its Domains tab. It’s the service’s primary domain until you make another one primary, and it’s covered by Sevalla’s own certificate. <name> is the service’s generated name, like storefront-x7k2m. Services created long ago can still have a kinsta.app or kinsta.page domain, which works the same way. Object storage buckets are different: a bucket with public access gets a <bucket-name>.sevalla.storage domain and can’t have custom domains. An application’s web process on the H1 size (the Hobby size) can’t have custom domains: the Custom domains card says Custom domains aren’t available on the Hobby size. Move the web process to a larger size to add one., with a Modify process button. The other way round, Sevalla refuses to move a web process to the Hobby size while the application has a custom domain. See Scaling.

​

Before you begin

• Access to the DNS settings of the domain, at your registrar or DNS provider.
• Permission to update the service. People who can only view it can open a domain’s DNS records but not change anything.
• For an application, a web process on a size larger than H1, and a payment method or credits. Without them, Add custom domain is disabled with Add a payment method or credits to add custom domains.

​

Add a domain

The domain appears under Custom domains with the status Verification, and its DNS records sheet opens. Reopen it later with Show DNS records next to the status, or from the domain’s ⋯ menu.

​

Verify the domain

The Verify domain step lists two records that prove you control the domain and let the certificate authority issue its certificate. Each Name shows twice: the full name and the short one. Some DNS providers, such as Namecheap and Squarespace, add your domain to the name for you; use the short one there. Verification usually completes within minutes, and can take hours with some DNS providers. When it does, both records show Verified, the status changes to Pointing, and the Point domain records appear. If the last check found problems, the sheet lists them under The last check found problems. If your domain’s DNS is on Cloudflare, the verification record is the pointing record instead: see Domains on Cloudflare DNS.

​

Point the domain

The Point domain step shows the record that sends the domain’s traffic to Sevalla. Its type depends on where your DNS is: A wildcard domain gets a second record of the same type for *. the domain, such as *.example.com. When Sevalla sees the record, the status changes to Active, the shield icon appears, and https://shop.example.com serves the service. For applications and static sites, Sevalla redirects http:// requests to https:// with a 301. Open the domain in a private window to check.

​

Root domains and subdomains

Each hostname is its own domain in Sevalla, with its own records, and Sevalla doesn’t redirect one to another. For a root domain such as example.com, use the A record from the Point domain step: most DNS providers don’t allow a CNAME record on the root. To send visitors from one hostname to the other, redirect in your application, or use redirects on a static site.

​

Wildcard domains

A wildcard domain serves the domain and every subdomain of it with one certificate: example.com with Wildcard also serves app.example.com, blog.example.com and any other subdomain. You choose it when you add the domain; to change it, delete the domain and add it again. A wildcard domain needs three records: the ownership TXT record, an _acme-challenge CNAME record (not TXT) that lets the certificate renew, and the pointing record for both the domain and *. the domain. An application gets the requested hostname in the Host header, so it can tell subdomains apart. The Custom domains list shows a Wildcard badge on it.

​

Domains on Cloudflare DNS

If your domain’s nameservers are Cloudflare’s, Sevalla detects it and changes the records:

• The Verify domain step asks for the CNAME pointing record instead of the ownership TXT record. The _acme-challenge record stays.
• The Point domain step uses a CNAME record, which Cloudflare also accepts on the root domain.

Set the CNAME record to DNS only (grey cloud) until the domain is Active: a proxied record hides its target, so verification can’t complete. Once it’s active, you can turn the proxy back on (orange cloud). Your traffic then passes through your Cloudflare zone and Sevalla’s, which has two consequences:

• Your zone’s cache sits in front of Sevalla’s CDN and edge caching, and purging Sevalla’s cache doesn’t purge yours. Purge both when you troubleshoot stale content.
• Your zone’s SSL/TLS mode must be Full or Full (strict). With Flexible, your zone connects to Sevalla over HTTP, Sevalla redirects to HTTPS, and visitors get a redirect loop.

For most setups, leave the record on DNS only and use Sevalla’s own caching.

​

SSL certificates

Sevalla issues a certificate for every custom domain once it’s verified, and renews it automatically while the _acme-challenge record is in place. You don’t upload or renew anything. If your domain has CAA records, they must allow the certificate authority: add CAA 0 issue "pki.goog" (and CAA 0 issue "letsencrypt.org" for an internationalized domain), or remove the CAA records. Otherwise the certificate isn’t issued and the domain stays in Verification. To use your own certificate, add the domain with the API and send custom_ssl_cert and custom_ssl_key (PEM) with it: see Add application domain. The dashboard doesn’t take certificates.

​

Set the primary domain

The primary domain is the address Sevalla shows and links to for the service. It doesn’t redirect your other domains: all of them keep serving the service. Only one domain is primary, and only an enabled domain with the status Active can become primary. A new custom domain doesn’t become primary on its own. The domain gets the Primary badge, and the service’s header shows it as its address.

​

Rename a Sevalla domain

You can change the part of a Sevalla domain before .sevalla.app, .sevalla.page or .sevalla.net. The service answers on the new name, and the old name stops working right away. Update every link and integration that used it. Only an enabled Sevalla domain can be renamed.

​

Disable a Sevalla domain

Disabling the Sevalla domain makes the service stop answering on it, for example once your custom domain is live. Make the custom domain primary first. The domain shows Disabled. To serve the service on it again, open its menu, click Enable, then Enable domain. Custom domains can’t be disabled, only deleted.

​

Delete a custom domain

The domain stops serving the service right away and disappears from the list. If it was the primary domain, the Sevalla domain becomes primary again. Remove its records at your DNS provider. You can add the domain again later, to this or another service; deleting and adding it again is also how a Timed out domain starts over.

​

IP addresses

The IP address in the A record belongs to Cloudflare, which runs in front of every Sevalla service. It doesn’t show where your service runs and doesn’t add latency: your service runs in the location you chose. Sevalla’s IP addresses are shared by Sevalla customers only. We don’t offer dedicated IP addresses.

​

API and CLI

The CLI commands for static sites and load balancers are the same under sevalla static-sites domains (with --site-id or <site-id>) and sevalla load-balancers domains (with --lb-id or <lb-id>). The CLI adds domains without the wildcard option; use the dashboard or the API for wildcard domains.