Domains and certificates

Every web service gets an HTTPS address the moment it's deployed. You can add your own domains, one at a time or a whole wildcard, to a service or to an environment, and ComputeSphere issues and renews their certificates.

At a glance

	Service	Environment
Default address	d-<service name>-<id>.computesphere.app	e-<id>.computesphere.app
Custom domains	Console, CLI, API	Console, API
Wildcards (*.example.com)	Yes	Yes
Which service answers	The service	The service bound to the request's path (path routing)
Certificate	Issued and renewed for you	Issued and renewed for you

Service addresses

The default address

A web service's default address looks like d-silver-cobra-ab12c.computesphere.app. It's set when the service is created, can't be changed or removed, and is served over HTTPS with nothing to set up. The console lists it as the service's platform domain.

Other service types, such as background workers and cron jobs, have no public address.

Custom domains

Add a domain such as app.example.com or example.com in the console (the service's Domains section), with csph deployments domains add, or with the API. Then add one record at your DNS host:

Connecting	Record
A subdomain (app.example.com)	CNAME to the service's default address
A root domain (example.com)	ALIAS or ANAME to the default address (on Cloudflare, a CNAME), or A and AAAA records if your DNS host has neither

A custom domain, end to end

1 · You add a record

CNAMEapp.example.com

→ d-silver-cobra-ab12c.computesphere.app

2 · Certificate

Issued once the record resolves, and renewed for as long as it stays.

3 · Your serviceweb

https://app.example.comHTTP is redirected to HTTPS.

A root domain's www is added for you. The console shows the exact records for your DNS host; see Custom domains for the steps and the provider guides.

Environment addresses

An environment has its own default address, e-<id>.computesphere.app, and can have custom domains of its own. One environment domain can serve several services, each on its own path: example.com/api from one service and example.com/ from another.

Environment custom domains

Add one in the environment's Domain section with Add custom domain, or with the API (/v2/environments/:id/domains). The records and the certificate work as they do for a service domain, except the records point at the environment's default address. To attach one, use the console or the API; the CLI's domain-path commands then route paths on it.

Path routing

A path binds a prefix, such as /api, on one of the environment's domains to a service:

One environment domain, two services

Environment domain

example.comPoints at the environment: e-7f3k2.computesphere.app

Path routing

/apiapiWeb service

/webWeb service

Each path goes to one service.

• Console: on the service, Domain paths › Add path. Pick the domain (the environment's default address or one of its custom domains) and enter the path. It starts with a slash, for example /api.
• CLI: csph environments domain-path add --environment <id> --domain <hostname> --path /api --deployment <id>. --domain must be a custom domain already attached to the environment.
• API: PUT /v2/environments/:id/domain/path.

An environment custom domain with no paths of its own uses the paths of the environment's default address. A path can be bound to one service per domain. Only services with a public address can be routed.

Wildcard domains

A wildcard such as *.example.com serves every subdomain of example.com from one service or one environment, so each tenant of your product can have its own subdomain without a domain per tenant. Add it like any other custom domain: on a service in the console, the CLI or the API, and on an environment in the console or the API.

A wildcard and its three records

Records at your DNS host

1CNAMEexample.com

→ your service. Shows the domain is yours.

1or TXT_cf-custom-hostname.example.com

→ the value shown. Shows it's yours without pointing example.com here. Pick one of the two.

2CNAME*.example.com

→ your service. Sends every subdomain to it.

3CNAME_acme-challenge.example.com

→ the value shown. Keeps the certificate renewing. Leave it in place.

Your serviceweb

https://acme.example.comhttps://globex.example.com

One level deep: not a.acme.example.com.

The Console and the CLI show the exact values. If your DNS is on Cloudflare, set every record to DNS only.

• One level. *.example.com covers app.example.com, and example.com too if you point the base name here, not a.app.example.com.
• Three records. One shows the domain is yours, one sends every subdomain to you, and one lets the certificate renew. The console and the CLI show their exact values.
• No overlaps. A name that's already in use, or that a wildcard already covers, can't be added, and a wildcard can't be added over names already in use.

See Wildcard domains for the records and statuses, and One subdomain per tenant for when to use one.

Certificates

ComputeSphere issues a certificate for every custom domain once its DNS record resolves, and renews it for as long as the record stays in place. HTTP requests are redirected to HTTPS.

• Nothing to upload. For an ordinary domain there's no verification record to copy.
• Certificate before traffic. To have the certificate ready before you move traffic, add the domain with the API and validation_method: txt. You add a certificate TXT record and an ownership TXT record, and the certificate is issued before your main record points here.
• Wildcards need their certificate record to stay in place, so the certificate keeps renewing.

Limits

• 50 custom domains per account, 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.
• Wildcards on some services. If the console says wildcard custom domains aren't available to set up yourself, contact support and they'll help you enable one.
• Records must be DNS only. If your DNS host is Cloudflare, don't proxy the records.
• One owner per name. A domain serves one service or one environment.

What's next

• Custom domains: the records, statuses and provider guides
• One subdomain per tenant
• Networking: public or restricted access
• Private network: service-to-service traffic
• What is SphereGate?: put a sign-in in front of a domain