Docs / Data and networking

Networking and domains

Services in an environment talk to each other over a private network. Traffic from the internet reaches a service through the Dawnrose edge, on a generated domain, your own domain or a TCP proxy port. All of it is under Settings → Networking in the service panel.

Private networking

Each environment has its own private network. Every service in it is reachable from the others at:

<service>.dawnrose.internal

The name is the service’s slug: its name in lowercase, with anything other than letters and digits turned into hyphens, such as api or my-worker. The Private networking field shows it. The short form <service> works too. Connect to the port the service listens on, for example http://api.dawnrose.internal:8080. The name resolves to every running replica, and DAWNROSE_PRIVATE_DOMAIN holds it for each service.

Each environment’s network is separate. Services in other environments, including staging and pull request environments of the same project, are not on it.

A private name only resolves while the service has running replicas. A sleeping service wakes on requests to its public domain or TCP proxy, not on private traffic.

Generated domains

A generated domain is a hostname on the platform domain with HTTPS, live as soon as it is created. It looks like <service>-<random>.up.dawnrose.ai; in environments other than production, the environment name is part of it too. Click Generate domain to add one, or run dawn domain.

After a service’s first successful deploy, Dawnrose generates a domain for it automatically when all of these are true:

• The service answers HTTP on its port. Any response counts, even a 404 or 500.
• It has no domain yet.
• It is not a cron service, has no TCP proxy and did not come from a template (templates decide their own domains).
• It does not look like a data store: the image or repository name is not a known database, cache, queue or search engine, and the port is not a common database port such as 5432, 3306, 6379 or 27017.
• Nobody opted out. Agents can create a service with generate_domain: false.

If the service does not answer HTTP yet, Dawnrose checks again after later deploys.

Custom domains

1. Click Custom domain, enter the hostname, such as app.example.com, and click Add.
2. Create the DNS records listed under the domain at your DNS provider.
3. Click Verify. Dawnrose checks the TXT record and starts routing the domain.

A root domain such as example.com cannot have a CNAME at most DNS providers. Use an ALIAS or ANAME record, or CNAME flattening on Cloudflare. For providers without either, the dashboard also lists A records with the edge’s IP addresses.

DNS changes can take a few minutes. Until the TXT record matches, the domain shows pending DNS and does not route. Domains on the platform domain are always generated, never added as custom domains, and a hostname can be attached to only one service.

From the CLI and for agents:

dawn domain app.example.com
dawn domain verify app.example.com

Agents use add_custom_domain, which returns the records, and then verify_domain.

Wildcard domains

On Hobby and Pro, enter *.example.com (or run dawn domain '*.example.com') to send every subdomain to the service. A wildcard domain needs one more record, so that Dawnrose can issue the wildcard certificate with a DNS challenge:

Target port

Each domain routes to the service’s port by default. To send one domain to a different port of the same service, enter it in the port field of that domain.

HTTPS certificates

Dawnrose issues and renews Let’s Encrypt certificates for every domain. A custom domain gets its certificate once it is verified and its DNS points at the edge; Dawnrose waits for that before asking Let’s Encrypt and tries again later if it is not ready. The domain shows a TLS badge when the certificate is active, and a TLS error under the domain if issuing failed. A failure also sends a domain.certificate notification. Certificates are renewed when they have less than 30 days left.

Once a domain has a certificate, requests to it over plain HTTP are redirected to HTTPS.

One-click DNS with Cloudflare

If a custom domain’s DNS is on Cloudflare, Dawnrose can create the records for you.

1. Under the pending domain, click Connect Cloudflare.
2. In Cloudflare, open My Profile → API Tokens and click Create Token. Use the Edit zone DNS template, and under Zone Resources choose your domain or all zones.
3. Paste the token and click Connect and add records.

Dawnrose adds the CNAME, the TXT record and, for wildcards, the _acme-challenge record, all as DNS only (not proxied). It leaves out the A records because Cloudflare flattens a CNAME at the root. Then it verifies the domain.

The token is stored encrypted for the workspace, so later domains that the token can reach only need Add records in Cloudflare. Connecting Cloudflare needs the admin role. You can revoke the token in Cloudflare at any time, or replace it with Use another Cloudflare token. Agents use configure_domain_dns once the workspace is connected.

TCP proxy

For traffic that is not HTTP, such as a database or a game server, a TCP proxy opens a public port on the edge and forwards it to a port of the service. Enter the service port under TCP proxy and click Enable TCP proxy; the dashboard shows the public host:port. Click Disable to close it.

With a TCP proxy, the service gets DAWNROSE_TCP_PROXY_DOMAIN, DAWNROSE_TCP_PROXY_PORT and DAWNROSE_TCP_APPLICATION_PORT. Redeploy services that use these variables after enabling it. Databases start without one, so they have no public address until you turn it on; see Databases.

How the edge handles requests

• Requests are spread across the service’s replicas in turn.
• WebSocket connections are supported.
• The app receives X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto and X-Real-IP headers.
• If the service is not running, the edge answers with a 503 page. If the app does not accept the connection, it answers with a 502 page that suggests checking PORT and 0.0.0.0.