Skip to main content
Public HTTPS requests to Suga services enter through Cloudflare’s global edge before reaching the Suga region that hosts your environment. The edge handles TLS, caching, and filtering, and the region runs your service. TCP proxy traffic takes a different path (see Request Path).

​
Edge Network

HTTPS traffic to a Suga service is served through Cloudflare’s global network. This applies to both auto-generated Suga domains and custom domains. At the edge, you get:
  • TLS termination with automatically provisioned and renewed certificates
  • A managed WAF and DDoS protection
  • Static asset caching and compression
Once the edge has handled the request, traffic is forwarded to the Suga region hosting your environment. See HTTPS Endpoints for the service-level configuration.

​
Regions

Each organization picks a region when its Suga Cloud account is set up, and every environment in that organization runs in that region. The regions currently open to new organizations are:
All environments in an organization share the same region. To run workloads in multiple regions today, contact support. Region migration and multi-region setup are handled manually.

​
Request Path

A public HTTPS request follows this path: The client connects to the closest Cloudflare location, Cloudflare forwards the request to the regional ingress for the environment, and the ingress routes the request to one of your service replicas. TCP proxy traffic skips the edge layer and connects directly to the regional load balancer, since Cloudflare’s HTTPS edge does not apply to raw TCP. See TCP Proxy.

​
DNS Architecture

Suga manages DNS records on your behalf. You don’t need to configure them. They’re documented here so you can understand what gets created when you enable a public endpoint or attach a custom domain. Suga-generated HTTPS domains resolve through Cloudflare to the regional ingress for the environment. This is what backs the auto-generated URL shown in the dashboard. Custom domains use a CNAME target of the form:
The hash is derived from your environment, so the target is different for every environment and you cannot construct it yourself. Copy the exact value Suga shows you when you add the domain, and point your domain (e.g. app.example.com) at it. Your domain then gets the same edge TLS, WAF, DDoS protection, and caching as a Suga-generated one. See Custom Domains for the setup steps. TCP proxy endpoints use a non-proxied DNS record so raw TCP traffic can reach the regional load balancer directly. The hostname is allocated automatically when you add a TCP proxy.

​
TLS and Certificates

Certificates are provisioned and renewed for you, on Suga-generated domains and on custom domains. You never touch a certificate or a private key, and there is nothing to renew or monitor. Traffic is encrypted on every hop between the visitor and the Suga region, in both directions. One case needs something from you. An apex domain, like example.com rather than app.example.com, needs a _suga-verify TXT record to prove you own it. See Custom Domains.

​
What Suga Manages vs What the Edge Manages

Whichever of these features are active depends on Cloudflare’s zone configuration. Suga doesn’t expose per-tenant overrides.

​
Common Questions

Yes. The region is selected when your Suga Cloud account is set up and applies to every environment in the organization. To change region after the fact, contact support.
Not today. All environments in an organization share the same region. If you need workloads in more than one region, contact support.
No. These behaviors are controlled by Cloudflare’s zone configuration, and Suga doesn’t expose per-tenant overrides.
Yes. We add regions over time. Contact support if a specific region matters for your workload.

​
Next Steps

Networking

HTTPS endpoints, TCP proxy, and private networking

Custom Domains

Serve services from your own domain