Custom domains
Verify a root domain once, then route any subdomain to a bucket, a worker, or a TiniDB database.
Custom domains live under Networking. Add a root domain
such as example.com, prove ownership with one TXT record, then
create as many subdomain routes as you need: media.example.com,
assets.eu.example.com, and so on. Each route points at one
bucket or one worker and reports its own status.
Add a root domain
Choose Add domain and complete the setup flow:
- Domain. Enter the root domain you own, such as
example.com. - Verify. Add the TXT record shown by the wizard at
_anythingcloud.example.com, wait for DNS to update, then choose Verify TXT record. - Connect. Point the wildcard CNAME at the edge.
The Domains table stays compact. Choose Manage on a root to open its TXT record and CNAME target in a popup without leaving Networking. Adding the host that uses the domain is a separate step.
TXT verification
The wizard creates a random token for the root domain. Add this record at your DNS provider:
| Type | Name | Value |
|---|---|---|
| TXT | _anythingcloud.example.com | The token shown in the wizard |
The TXT record proves you control the root domain. It does not route traffic. Verification can take a few minutes while DNS changes propagate. The domain stays in Pending TXT until you choose Verify TXT record and the matching record is visible; it is not polled in the background.
Point DNS at the edge
After verification, point the branch wildcard at the edge:
| Type | Name | Value |
|---|---|---|
| CNAME | *.example.com | edge.anything-cloud.com |
Use DNS only (grey cloud) in Cloudflare. A proxied record can return Cloudflare errors 525 or 1014 during certificate issuance, and it interrupts large uploads. Keep the record DNS-only.
Point the apex (@) at the edge as well if you need it. The
edge issues a certificate for the apex and www whenever they
resolve to it, and shows the default page until a host is added.
For a deeper name such as assets.eu.example.com, a wildcard
for example.com only covers one label. Add a wildcard for that
branch too:
| Type | Name | Value |
|---|---|---|
| CNAME | *.eu.example.com | edge.anything-cloud.com |
Add a host
Choose Add host from Networking. Pick a bucket, worker,
or TiniDB database, choose a verified root domain, and enter the subdomain.
One or more dot-separated labels are allowed, and @ routes the
root domain itself. The page previews the full hostname before you save it.
Worker routes can also be added from the worker's Triggers tab.
A database host serves only that database's HTTP API, and requests still
need one of its tokens. The API paths stay the same under the custom host,
so https://db.example.com/query reaches the database.
A root can have many hosts. Each host is independent, so
media.example.com and assets.example.com can point
at different targets.
When a bucket has a custom host, Networking shows the custom host instead of the default S3 endpoint. The S3 endpoint is still available on the bucket's Access and Settings tabs. If the bucket has S3 Pages turned on, the custom host serves the configured index and error documents. The generated S3 endpoint also serves the site to anonymous browsers, while signed SDK requests keep REST behavior. See S3 Pages.
Statuses
Root ownership and route health are separate:
| Status | Meaning |
|---|---|
| Pending TXT | Root ownership: the TXT record has not been seen yet. |
| Verified | Root ownership: the TXT record matched. |
| Setting up | Route: created, waiting for DNS and the edge certificate. |
| Active | Route: the certificate is installed and the hostname is routed. |
| Ready | Automatic worker address: reserved and ready for the worker. |
| Error | Root or route: open the setup page for the reason. |
Bucket endpoint rows are marked Automatic and show Active while the account is active. The Hosts table shows the hostname and target; bucket visibility is managed on the bucket's Access tab.
Route settings
Open a bucket host from the Hosts table and use the Manage tab. The Target section changes which bucket the hostname serves. The hostname and certificate stay the same, and the route shows Setting up until the edge applies the new target.
The Settings section has two security switches for bucket routes:
- Allow WebSocket connections. Adds the upgrade headers and a longer connection timeout so long-lived WebSocket sessions pass through the edge.
- Block common exploit paths. Rejects scanner traffic such as WordPress probes,
.env,.git, phpMyAdmin, andcgi-binbefore it reaches the bucket. This is on by default for custom bucket hosts.
Worker routes do not have these switches. Their mode is a label chosen when the route is created: HTTP for normal request hosts or Webhook for provider callbacks. Both forward requests to the worker, so the worker should reject methods it does not accept. The route is managed from the worker's Triggers tab.
Database routes have no settings; remove and add the host to use a different subdomain. Requests still carry the database token, so the route never exposes the database without one.
Bucket endpoints keep their own rate limits and abuse protection. The exploit-path switch applies to the routed host because it may front an application later.
Cache rules
Cache rules are configured per host. Open a bucket or worker host from the Hosts table and choose the Caching tab. The page shows the hostname and target at the top, so you always know which site you are editing. Database, instance, and load balancer hosts do not have cache rules.
Each rule matches a file extension and sets how long the edge keeps that response: five minutes, one hour, one day, seven days, 30 days, or one year. Choose Never to keep an extension out of the cache. Bucket hosts default to five minutes; worker hosts default to two hours while their general cache switch is on. Hosts without rules use the default for their type.
Rules are per hostname and apply to the whole site under that host. They are written for the edge on its next configuration pass, so a change can take about a minute to take effect. Worker hosts can cache a few static file types even when their general cache switch is off.
To drop every cached file for a bucket and all of its custom hosts, use Clear cache at the top of the bucket page or on a bucket host's Caching tab. See S3 Pages for details.
Traffic
Networking → Traffic totals requests, edge cache hits, bytes served, and 5xx errors for all of your hosts. Each total shows the percentage change from the previous period, and a small sparkline shows the shape of the window. The charts below break the same data down over time: requests with errors, data served, and cache hit rate.
The table at the bottom shows the same figures per hostname. Switch between 24 hours, 7 days, and 30 days. Hourly samples are rolled into one row per hour and kept for 120 days.
Remove a domain or route
Open a host from the Hosts table and use the Manage tab to disable it or remove it. Disabling keeps the DNS records and stops the edge from serving the hostname; enable it again from the same tab. Removing a route deletes only that hostname. Removing a root domain also removes every route under it, and the edge drops those hosts on its next pass.
Private buckets
A private bucket keeps the same public endpoint. Anonymous reads return
403 AccessDenied; reads and writes signed with your access keys
work normally. The console creates short-lived signed links for objects in a
private bucket. Each signed link expires on its own, and anyone with the full
link can read that object until it expires. Signed links use the same
endpoint as the bucket page.
Targets
Networking routes to buckets and workers. The Add host form lists both under Serve, and the Hosts table shows the target type. A worker route is tied to that worker; deleting the worker removes its routes.