Projects and Sites Guide
Optional containers that mirror how your business is organized. Use projects to isolate work by client or brand; use sites to declare redirect targets and bind TDS rules to a specific Cloudflare zone.
When the Flat List Stops Working
For a one-brand operator with 10 domains, a flat list works fine — every redirect, every TDS rule, every postback source is already in one place. The Domain table filter is enough.
Past 20+ domains, multiple clients, or separate environments (prod vs staging), the flat list turns into noise: dropdowns get long, audit trails blur across brands, and the wrong domain assignment becomes easy to make. Projects and sites are the seam that fixes this without forcing premature structure.
Projects
- One project per client, brand, vertical, or environment — whatever boundary matters for billing, isolation, or reporting. Each project shows its domain count and site count at a glance.
- Fields: name (required), description, brand tag, commercial terms, start/end dates. The commercial fields exist for agencies tracking client engagements; ignore them if you do not need them.
- Used as a filter key on Domains, Redirects and TDS. Postbacks are account-wide — a postback source carries no project or site of its own. Scope a bulk action to one project and the rest of the account stays untouched.
Sites
- A site lives inside a project, declares a primary domain (where its traffic lands), and becomes the anchor for redirects and TDS rules deployed to that host.
- Fields: name (required), primary domain, and site locale (BCP 47 — useful when one operator runs multilingual landings). The locale is the field once labelled "tag", not a second one beside it. Status: Active, Paused, or Archived.
- Source domains attach to the site and point at its primary domain. The role check is enforced: the domain serving as the primary cannot also be a source for the same flow.
Practical Setup
- Sync domains first (Cloudflare integration → Domains). Projects and sites read from the synced inventory.
- Create one project per logical boundary — usually one client, brand, or production environment.
- Inside the project, create a site per primary domain (where redirected traffic lands). Most projects have 1–3 sites.
- Attach source domains to the project and to specific sites. Then create redirects and TDS rules — both are scoped to the site, so dropdowns stay short.
When to Stay Flat
Fewer than 10 domains and a single use case? Stay on the "Default Workspace" project and its "Default" site — the pair every account is created with. You are already using them whether you look at this page or not, and you can leave the structure alone until a second brand or client shows up.
Layer structure on when the flat list stops being scannable — usually around 20+ domains or when the same dropdown starts mixing your own brands with a client's. Adding projects later is non-destructive; existing redirects keep working while you re-organize.
FAQ
Do I need a project per domain?
No. One project typically holds dozens of domains. The right granularity is "what would you want to scope a bulk action to" — usually a client, brand, or vertical, not a single domain.
What is a primary domain?
The domain where redirected traffic lands. If example.com → landing.com, landing.com is the primary domain of that site. In the API the field is called acceptor — same thing. Primary domains also host the Cloudflare Worker that runs the site’s TDS rules.
Can I move a domain between projects later?
Yes, but it is a detach and a fresh attach, not a move — the domain does not keep its site. Removing a domain from its project clears the site and drops the role back to backup in the same request. So: on the current project, remove the domain (if it is a site’s primary, choose the replacement first — the last primary cannot be taken away); then open the target project’s "Add domains" drawer, which lists only domains with no project, and add it there; then point it at a site again. There is no bulk "assign to project" in the Domains table.