Domains & TLS

How traffic reaches your service

Every request to a Parslinks-hosted application follows the same path:

Browser
  → Cloudflare (TLS termination, proxied wildcards)
    → Edge service origin (Host-based routing)
      → Regional platform endpoint VIP
        → Ready replicas only

Routing is Host-header based. You never create one DNS record per deployment; hostnames resolve through derived router entries that edge-service keeps in sync automatically.

Platform hostnames

Parslinks mints three categories of hostname from its configured platform roots:

The critical rule: a domain routes only through an alias. There is no path from a user hostname straight to a deployment — that's what makes rollbacks and promotions instant for every domain at once.

Adding a custom domain

1. Add the domain to your service instance in the dashboard.
2. Create a CNAME record pointing to the bound alias hostname.
3. Edge verifies ownership (a TXT record under _parslinks.{hostname} when automated verification is configured) and tracks ownershipStatus per domain row.
4. Once verified, the domain joins the routing table and TLS covers it.

Domains are scoped to an environment, so preview and production domains never collide.

TLS

• Visitor side: Universal SSL on each platform zone at Cloudflare.
• Origin side: Full (strict) mode with origin CA is preferred; edge stores per-domain tlsStatus so you can see certificate state in the dashboard.

You don't upload certificates or renew anything manually.

Private networking

Inside a project, services reach each other over project-scoped private DNS:

{serviceSlug}.{environmentName}.internal

These names are region-local and resolve to the platform endpoint — not to any individual replica. Public TCP exposure (for non-HTTP protocols) is a network setting you toggle per instance; it binds on the platform endpoint once, not on each replica.