Skip to main content

Custom domains

Every web service you deploy gets an instant URL on computesphere.app — for example, silver-cobra.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 — there is no certificate file to upload and no verification record to copy.

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 or API).
  2. Point your domain at your service by adding a DNS record at your provider — a CNAME for a subdomain, or the apex equivalent for a root domain (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 ConsoleDomains, 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 from Validating to Active once the record resolves and the certificate is issued.
Prefer to bring your own certificate?

When adding the domain, enable Use custom SSL certificate and paste your certificate and private key. ComputeSphere then serves your certificate instead of issuing one. Most customers leave this off and let ComputeSphere manage SSL automatically.

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
Subdomainwww.example.com, app.example.com, api.example.comCNAME <label> → <target>On Cloudflare, set the record to DNS only (grey cloud).
Root / apexexample.comDepends on your provider — see Root / apex domainsPlain registrars use A + AAAA; ALIAS/ANAME providers and Cloudflare can point the apex directly.

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 (grey 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), so the right record depends on what your DNS provider supports. Pick the row that matches your provider:

Your DNS providerRecommended apex recordHow it points
CloudflareCNAME @ → <target>, DNS only (grey cloud)Cloudflare flattens the apex CNAME for you — no IP addresses needed.
A provider with ALIAS / ANAME — DNSimple, DNS Made Easy, NS1, easyDNS, …ALIAS / ANAME @ → <target>The provider resolves the apex to your service for you — no IP addresses needed.
A plain registrar — Namecheap, GoDaddy, Google Domains, …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.

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 (unless you chose to bring your own certificate).

No validation records for a normal domain

For an ordinary subdomain or apex, you add only the CNAME/A/AAAA/ALIAS record above — there is no _acme-challenge or _cf-custom-hostname record to add. SSL is automatic. The only case that needs those extra validation records is a wildcard domain; don't add them for anything else.

Domain status

In Console → Domains, each domain shows a status:

StatusMeaningWhat to do
ValidatingComputeSphere is waiting for your DNS record to resolve and is issuing the certificateAdd 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.
ActiveThe domain is live and served over HTTPSNothing — you're done

If a domain stays in Validating, 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 a root domain and its www, or several brands pointing at one app. Each is added the same way and gets its own automatic certificate.

Wildcard domains

A wildcard domain (*.example.com) serves every subdomain — app.example.com, api.example.com, anything.example.com — from one custom domain, without adding each one individually.

Wildcards are not yet self-serve — contact support

Wildcard custom domains aren't available in the Console yet. If you need one, contact support and we'll set it up for you. (Self-serve wildcards are coming soon.) The records below are documented so you know what to expect.

Wildcards work differently from a normal domain. Because a * can't be proved by the usual automatic check (there's no single hostname to verify), a wildcard needs two extra delegation records that the Console will show you, on top of the records that point traffic at your service.

Records a wildcard needs

When wildcard support is enabled for your domain, the Console shows all of these:

RecordNameValuePurpose
CNAME_acme-challenge<id>.verify.computesphere.appCertificate validation — lets ComputeSphere prove control and issue the wildcard certificate.
CNAME_cf-custom-hostname<id>.hostname.computesphere.appDomain-ownership validation.
CNAME*<target>Routes every subdomain to your service.
Apex@Apex record for your provider — see Root / apex domainsA wildcard requires the root to point at ComputeSphere too.

The <id> values are unique to your domain and are filled in by the Console — copy them exactly. <target> is your ComputeSphere service address, as everywhere else on this page.

Only wildcards use _acme-challenge / _cf-custom-hostname

These two validation records exist only for wildcard domains. For a normal subdomain or apex you never add them — SSL is automatic. See Automatic SSL.