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.
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
- Add the domain to your service in ComputeSphere (Console or API).
- Point your domain at your service by adding a DNS record at your provider — a
CNAMEfor 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. - 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
- Open the Console → Domains, or go to a service and open its Domains section.
- Click Add custom domain.
- Enter the domain — for example
www.example.comorexample.com— and click Add domain. - 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.
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.
| Connecting | At any provider | Notes |
|---|---|---|
Subdomain — www.example.com, app.example.com, api.example.com | CNAME <label> → <target> | On Cloudflare, set the record to DNS only (grey cloud). |
Root / apex — example.com | Depends on your provider — see Root / apex domains | Plain 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 provider | Recommended apex record | How it points |
|---|---|---|
| Cloudflare | CNAME @ → <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::31b | Point 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).
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:
| Status | Meaning | What to do |
|---|---|---|
| Validating | ComputeSphere is waiting for your DNS record to resolve and is issuing the certificate | Add 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. |
| Active | The domain is live and served over HTTPS | Nothing — 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.
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:
| Record | Name | Value | Purpose |
|---|---|---|---|
CNAME | _acme-challenge | <id>.verify.computesphere.app | Certificate validation — lets ComputeSphere prove control and issue the wildcard certificate. |
CNAME | _cf-custom-hostname | <id>.hostname.computesphere.app | Domain-ownership validation. |
CNAME | * | <target> | Routes every subdomain to your service. |
| Apex | @ | Apex record for your provider — see Root / apex domains | A 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.
_acme-challenge / _cf-custom-hostnameThese two validation records exist only for wildcard domains. For a normal subdomain or apex you never add them — SSL is automatic. See Automatic SSL.