Skip to main content

Custom domains

Every web service you deploy gets an instant URL on computesphere.app — for example, d-silver-cobra-ab12c.computesphere.app. A custom domain lets you serve that same web service from your own domain (example.com or app.example.com) instead, with SSL handled for you.

You add the domain in ComputeSphere, then add one DNS record at your domain provider that points it back to your web service. Once the record resolves, ComputeSphere issues and renews the SSL certificate automatically. For an ordinary domain there is no certificate file to upload and no verification record to copy. A wildcard needs a certificate record too.

For how service and environment addresses, path routing and certificates fit together, see Domains and certificates.

note

Custom domains apply to web services — the service type that serves HTTP traffic on a public URL. Other service types (such as cron jobs) don't have a public address.

How it works​

  1. Add the domain to your service in ComputeSphere (Console, CLI or API).
  2. Point your domain at your service by adding a DNS record at your provider — a CNAME for a subdomain, or an ALIAS or ANAME for a root domain (on Cloudflare, a CNAME) — see Choose your record. The Console shows the exact records to add for your DNS provider, so you can copy them straight across.
  3. ComputeSphere detects the domain, issues an SSL certificate, and starts serving your service over HTTPS. The certificate renews automatically for as long as the record stays in place.

Your traffic is always served through ComputeSphere's edge, which provides TLS termination and DDoS protection — you never point your domain directly at an origin server.

Add the domain​

  1. Open the Console → Domains, or go to a service and open its Domains section.
  2. Click Add custom domain.
  3. Enter the domain — for example www.example.com or example.com — and click Add domain.
  4. ComputeSphere shows the DNS record(s) to create. Add them at your domain provider (next section), then return; the status moves to Active once the record resolves and the certificate is issued.

From the CLI: csph deployments domains add, then csph deployments domains dns for the records and csph deployments domains verify to check again.

A root domain's www is added for you.

Choose your record​

Which record you add depends on whether you're connecting a subdomain or a root (apex) domain — and, for an apex, on what your DNS provider supports.

Throughout this page, <target> is your ComputeSphere service address — the hostname shown in the Console when you add the domain, e.g. d-silver-cobra-ab12c.computesphere.app. The Console always shows the exact records for your provider; this page explains the shape of each one.

ConnectingAt any providerNotes
Subdomain — www.example.com, app.example.com, api.example.comCNAME <label> → <target>On Cloudflare, set the record to DNS only (gray cloud).
Root / apex — example.comALIAS or ANAME @ → <target> (on Cloudflare, a CNAME)If your provider offers none of these, use A + AAAA — see Root / apex domains.

Subdomains are simplest​

A subdomain is a single CNAME record and works on every DNS provider:

Type    Name    Value
CNAME   www     d-silver-cobra-ab12c.computesphere.app

That's the whole setup — no other records. If your DNS is at Cloudflare, set the record's proxy status to DNS only (gray cloud) so ComputeSphere can issue the certificate.

Root / apex domains​

The DNS standard does not allow a plain CNAME on a root domain (example.com). The record that does the same job there is an ALIAS or ANAME (on Cloudflare, a CNAME): the name depends on your DNS provider, the value is the same <target> either way. Pick the row that matches your provider:

Your DNS providerRecommended apex recordHow it points
CloudflareCNAME @ → <target>, DNS only (gray cloud)Cloudflare flattens the apex CNAME for you — no IP addresses needed.
A provider with ALIAS / ANAME — Namecheap, DNSimple, DNS Made Easy, NS1, easyDNS, …ALIAS / ANAME @ → <target>The provider resolves the apex to your service for you — no IP addresses needed.
A provider with neither — GoDaddy, …A @ → 162.159.143.43, 172.66.3.39 and AAAA @ → 2606:4700:7::31b, 2a06:98c1:58::31bPoint the apex directly at these addresses (also shown in the Console).

Whichever path applies, ComputeSphere issues and renews the SSL certificate automatically once the record resolves.

In the API and CLI

For a root domain, the dns_records on a domain show the record type as ALIAS. Create it as an ALIAS or ANAME record (on Cloudflare, a CNAME) with the value shown. For a subdomain the type is CNAME. To get the exact records for your DNS provider, use the Console or the domain-dns endpoint.

Plain registrars — A / AAAA records​

If your provider has no ALIAS/ANAME and isn't Cloudflare, point the apex straight at ComputeSphere's IP addresses with A and AAAA records, using @ (or your bare domain) as the name:

Type    Name    Value
A       @       162.159.143.43
A       @       172.66.3.39
AAAA    @       2606:4700:7::31b
AAAA    @       2a06:98c1:58::31b

Use the exact IP addresses the Console shows when you add the domain — they're listed there for you to copy. Add every A and AAAA address shown; the AAAA records cover visitors on IPv6 networks. The apex is then served directly — no redirect needed.

Universal fallback — make www primary and redirect the root​

This works on every provider, even ones with no apex support at all. Make www your primary address (a single CNAME → <target>) and 301-redirect the root to it using your provider's domain-forwarding feature. Visitors who type example.com are permanently redirected to https://www.example.com, which is served by ComputeSphere.

Configure your DNS provider​

Step-by-step guides for the most common providers:

Automatic SSL​

ComputeSphere provisions and renews an SSL certificate for every custom domain automatically once your DNS record resolves — and for your default computesphere.app URL. HTTP requests are redirected to HTTPS. You don't manage, upload, or renew anything.

No validation records for a normal domain

For an ordinary subdomain or apex, you add only the CNAME/A/AAAA/ALIAS record above. SSL is automatic, and there are no validation records to add.

Certificate before traffic​

To have the certificate ready before you move traffic, for example when you move a live site, add the domain with the API and validation_method: txt. ComputeSphere then shows a certificate TXT record and an ownership TXT record. Add both, and the certificate is issued before your main record points here.

Domain status​

In Console → Domains, each domain shows a status:

StatusMeaningWhat to do
Waiting for DNSComputeSphere can't see your DNS record yetAdd the record (if you haven't), then wait — DNS can take a few minutes to a few hours to propagate. Use Verify now to re-check.
ValidatingThe record is visible and ComputeSphere is checking itNothing
Issuing certificateThe certificate is being issuedNothing
ActiveThe domain is live and served over HTTPSNothing — you're done
Action requiredThe record or the certificate needs a fixCheck the record the Console names, fix it, then use Verify now

ComputeSphere checks again on its own after 2, 5 and 10 minutes. If the checks still fail, the domain shows that automatic retries are exhausted; fix the record and use Verify now. If a domain stays in Waiting for DNS, the most common cause is the DNS record not being in place or not yet propagated. Double-check the record name and value against the provider guide.

Multiple domains​

You can connect more than one custom domain to the same service — for example several brands pointing at one app. Each is added the same way and gets its own automatic certificate.

An account can have 50 custom domains across all its services and environments. A wildcard counts as one, and a root domain's automatic www doesn't count. To raise the limit, contact us.

Wildcard domains​

A wildcard domain (*.example.com) serves every subdomain of example.com — app.example.com, acme.example.com, anything.example.com — from one service or one environment, with one setup. If you also point example.com itself at it, it is served too. It is the usual way to give each tenant of a multi-tenant product its own subdomain; see One subdomain per tenant for when to use it and when to add one domain per tenant instead.

Add a wildcard​

  1. Open the service's Domains section, or the environment's Domain section, and click Add custom domain.
  2. Enter *.example.com and click Add domain. For a service, from the CLI: csph deployments domains add '*.example.com' --deployment <id>, then csph deployments domains dns for the records. An environment's wildcard is added in the console or with the API.
  3. Create the records ComputeSphere shows you (below) at your DNS host.
  4. Wait for the status to reach Live, usually a few minutes after the last record is visible.

The records​

#RecordNameValueWhat it does
1Show the domain is yours — pick one
CNAME, or ALIAS/ANAME at a rootexample.comyour service addressPoints the base name at your service
TXT_cf-custom-hostname.example.comthe value shown in the ConsoleThe ownership TXT record: shows the domain is yours without pointing the base name
2CNAME*.example.comyour service addressSends every subdomain to your service
3CNAME_acme-challenge.example.comthe value shown in the ConsoleThe certificate record: lets ComputeSphere issue and renew the certificate with nothing more from you

Your service address is the service's own computesphere.app URL, as everywhere else on this page; for an environment, it's the environment's default address. Copy the ownership TXT record's name and the certificate record's value exactly as shown. The certificate record appears in the Console about two minutes after you add the domain.

Which one to pick. If your DNS host can't point example.com at a name, use the ownership TXT record. Use it too if you don't want the base name pointing here at all. Otherwise pointing the base name at your service is the simpler choice. With the ownership TXT record the base name is not served by your service; it stays wherever it points today.

Keep wildcard records DNS only

If your DNS is on Cloudflare, a wildcard's records must be DNS only, not proxied. Proxied, the certificate can't be issued and subdomains won't be served.

Status​

StatusMeaningWhat to do
Waiting for DNSThe base name record or the ownership TXT record (1), or the certificate record (3), isn't visible yetCreate the records; the Console says which one it is waiting for. Use Check again after adding one
Issuing the certificateThe records are in place and the certificate is being issuedNothing
LiveOwnership is confirmed and the certificate is active; every subdomain is served over HTTPSNothing — you're done
Needs attentionOwnership couldn't be confirmed, or the certificate couldn't be issuedCheck the record the Console names, then use Check again

A wildcard is only Live when both ownership and the certificate are active. Until then subdomains don't serve.

Limits​

  • Leave the certificate record in place. The _acme-challenge record is how the certificate is renewed; if it is removed, the certificate can't renew.
  • One level. *.example.com covers app.example.com, not a.app.example.com. Add *.app.example.com as its own wildcard if you need the next level.
  • No overlaps. A name that's already in use, or that a wildcard already covers, can't be added: "This domain is already in use, or a wildcard domain already covers it." A wildcard can't be added over names already in use either.
  • Your own records win too. A subdomain with its own record in your DNS (www, mail) keeps going where that record points; the wildcard record only answers for names that have none.
  • The wildcard goes at the start. *.example.com is valid; app.*.example.com is not.
  • An account can have 50 custom domains. A wildcard counts as one. Contact us to increase quota.
  • Not on every service yet. If the Console says "Wildcard custom domains aren't available to set up yourself yet", contact support and they'll help you enable one.