CNAME.Cloud

Pass-through · Secure · Global

Cross-cloud failover for TCP services, with TLS. Just point a CNAME.

Point a CNAME at cname.cloud and every connection goes to a healthy server, on whichever cloud it runs. TLS passes straight through: your certificates and your keys, never ours.

Get started How it works
Five edge regions
World map showing edge regions in Las Vegas, New York, Luxembourg, São Paulo and Singapore
Edge regions
5
Health checks
Every region
TLS terminated
Never

DNS Configuration

No nameserver changes required.

TypeNameValueTTL
CNAMEapi.mydomain.comapi-mydomain-com.cname.cloud300s
CNAMEapp.mydomain.comapp-mydomain-com.cname.cloud300s
TXT_cname.app.mydomain.comcname-verify=7f3a9c…300s

Once your account is approved, open your cname.cloud address (for example app-mydomain-com.cname.cloud) in a browser to receive the TXT token. Once it is in place, the hostname is registered to your account and no other account can route it. A bare domain (mydomain.com) cannot hold a CNAME record; use your DNS provider's ALIAS record or CNAME flattening instead.

  1. Point a CNAME
  2. Set up your routing
  3. Verify failover
  4. You're live

More than failover

Failover, load balancing and geo-steering for your servers.

Why it exists

Your app stays up when a cloud goes down.

You run your app on two servers so that one can fail. Something then has to decide which server receives traffic, and that is a load balancer. One load balancer is a new single point of failure. Two need a floating IP, a failover script and a third machine to break ties. Across two clouds, there is no floating IP at all.

cname.cloud is that layer, already running in five regions, so you do not have to build it, duplicate it or be paged for it.

Building it yourself

  • Two load balancers per site
  • A floating IP, which does not exist across clouds
  • Failover scripts and a tiebreaker node
  • An on-call rotation for all of it

With cname.cloud

  • One CNAME per hostname
  • Health checks from five regions
  • Failover between any providers
  • Nothing extra to run or patch

How it works

An L4 edge that never decrypts your traffic.

Accounts are approved before activation. Request yours; once it is approved, setup takes three steps.

  1. 1

    Point a CNAME

    app.yourdomain.com → app-yourdomain-com.cname.cloud. Your nameservers stay where they are.

  2. 2

    Verify the hostname

    Open your cname.cloud address in a browser. It shows a token to add as a TXT record, and the hostname is registered to your account.

  3. 3

    Add your servers

    Enter the IP address and port of each server, on any cloud. Every region checks them, and a server that fails its checks stops receiving new connections until it recovers. Servers must be reachable from the public internet.

How a connection is routed Browsers, apps and your own services connect through the cname.cloud edge. The edge reads only the hostname, sends traffic to the healthy server in Cloud A and stops sending it to the failing server in Cloud B. TLS runs end to end, from the client to your server. Browsers apps and APIs Your services in other sites TLS cname.cloud edge Five regions · reads only the hostname Cloud A any provider Healthy Cloud B any provider Failing checks TLS ends on your server, with your key

Protocol support

Web applications and APIs on the same edge.

How each protocol is routed

HTTPS, HTTP/2, gRPC, WebSockets over TLS
By hostname (SNI)
Plain HTTP
Redirected to HTTPS; Let's Encrypt HTTP-01 challenges still reach your origin
Redis over TLS (rediss://), MQTT over TLS, custom TCP over TLS
By hostname, on any port
PostgreSQL 17+ clients with sslnegotiation=direct
By hostname
Older PostgreSQL clients, MySQL, plaintext Redis and TCP
Dedicated port (no hostname is sent)

Compared with a CDN

Use a CDN for your website. Use cname.cloud for failover.

CDNs are excellent at what they do, and many of our users run one too. The two solve different problems: use cname.cloud when you need failover across clouds without giving up your TLS, or for non-HTTP traffic that CDNs typically proxy only on enterprise plans, if at all.

FeatureTypical CDNcname.cloud
TLSTerminates TLS at the CDN's edge and can inspect traffic; that is how caching and WAF workPassthrough: TLS terminates on your server, with your certificate
Your private keysThe CDN holds an edge certificate for your domainWe never hold one
Non-HTTP TCP (Postgres, Redis, MQTT, custom)Usually HTTP and HTTPS only; arbitrary TCP is limited to specific protocols or enterprise add-onsAny TLS protocol, on every plan
Failover between serversOften a paid add-on; health checks for non-HTTP services are commonly enterprise featuresIncluded: health-checked failover from every region
CDN, caching, WAF, bot protectionYesNo. Put a CDN in front of your website and use cname.cloud for everything else

Describes common CDN offerings in general; features and plans vary by provider.

TLS termination compared with passthrough A TLS-terminating proxy decrypts traffic at its edge and re-encrypts it to your server. cname.cloud passes the encrypted connection straight through to your server and reads only the hostname. TLS-terminating proxy client decrypts, can inspect server cname.cloud passthrough SNI client reads hostname only your key

Who uses it

One edge, many reasons.

Plain facts

What it does and does not do.

Limits

  • What we can see: the hostname you connect to, IP addresses, timing and byte counts. Never the contents.
  • Public endpoints only: your servers must be reachable from the internet, and clients connect through a public hostname.
  • Postgres: hostname routing requires Postgres 17+ clients using direct TLS (sslnegotiation=direct); older clients use a dedicated port.
  • Plaintext protocols (plain Redis, MySQL, raw TCP) carry no hostname, so they need a dedicated port.
  • Failover applies to new connections. A connection open to a server that fails is closed and the client reconnects; most database drivers and HTTP clients do this automatically.
  • Lock down your origin: accept connections only from our edge IP addresses, so traffic cannot bypass the edge.

Coming soon

  • ComingPrivate backends. One small container in your network routes to services with no public IP: no open ports, and it works behind NAT.
  • ComingStatus page and alerts. Uptime history and alerts from the same checks that drive failover.
  • ComingSafe database failover. Promote a replica when the primary's server fails, without split brain or lost committed writes.
  • ComingClient IP addresses passed to your server through the PROXY protocol.

FAQ

Frequently asked questions.

Do I need to change nameservers?
No. You add one CNAME per hostname at your existing DNS provider.
Do you terminate TLS?
No. TLS terminates on your server. We read only the hostname from the handshake to choose a server.
What about certificates?
Your server keeps its own certificate. Let's Encrypt HTTP-01 and TLS-ALPN-01 challenges pass through to it, so renewals continue to work.
How fast is failover?
A server that refuses connections is skipped immediately. A server that stops responding is removed once it fails its health checks, so the delay depends on your check interval (one minute on the free tier).
Will my backend see the client's IP address?
Not yet: today your backend sees the address of our edge. Passing the client's IP address through the PROXY protocol is on the roadmap.
Can I route to private services?
Not yet. Your servers must be reachable from the public internet. Private backends, reached through a small container in your network, are on the roadmap.
What happens if cname.cloud has an outage?
The five edge regions run independently, so losing one moves traffic to the others. If every region were unavailable, point your DNS record directly at a server; a low TTL on the record makes that switch quick.
How much does it cost?
The free tier includes 100 GB of egress per month on one root domain, with five health checks at one-minute intervals. Beyond that, egress is $0.20 per GB, prepaid with credits from $5, and ingress is free. If your bandwidth is exhausted, your hostnames fall back to DNS routing rather than going offline. See pricing.