Custom domains for the pages your agent builds.

The link is part of the deliverable

When you send client work as a link, the domain in that link does half the talking. A report at claude.ai/public/artifacts/... or name.openai.chatgpt.site says "a tool made this." The same report at reports.yourstudio.com says "we made this." For agencies and consultants delivering agent-built pages, that difference is the difference between looking like the author and looking like the operator of someone else's software.

Where the platforms stand on custom domains

Verified against each platform's own documentation as of July 2026:

• Claude artifacts. Publishing creates a claude.ai link. Anthropic's support doc covers embedding an artifact on a site, but documents no custom-domain option, and artifacts on Team and Enterprise plans cannot be published publicly at all.
• ChatGPT Sites. Sites live at name.openai.chatgpt.site, with genuine same-URL production deploys, which is real replace-in-place and worth crediting. The docs now document custom domains too (apex or subdomain via DNS, "where available", not for Enterprise-owned sites at launch). The remaining gaps are around the domain, not the domain itself: no account-free gated viewing, no expiry or burn, and publishing is bound to ChatGPT rather than open over API or MCP.
• Vercel Drop. Vercel proper handles custom domains well; that is not the gap. The gap is that each drop creates a new project, so the domain you attached stays pointed at the old drop. Keeping a domain current across iterations means graduating to Git or the CLI.
• Cloudflare Drop. Sites deploy to a public workers.dev URL. Adding a domain sits behind claiming the deployment into a Cloudflare account and doing the Workers DNS configuration yourself.

All four are good at what they lead with. None of them puts an agent-built page on a domain you own as part of the normal flow.

How it works on Stacktree

1. Publish the page. From Claude, Codex, Cursor, any MCP agent, or drag and drop.
2. Add your hostname. The dashboard returns two DNS records: a CNAME and a _stacktree-verify TXT.
3. Create the records, click verify. Stacktree checks the TXT over DNS and registers the hostname with Cloudflare for SaaS.
4. SSL provisions itself. The certificate issues automatically; you never handle a cert file.

From then on the domain is a pointer you control. Re-bind proposal.yourstudio.com to a different site in one call when the next engagement starts, and because a Stacktree page updates in place, revising the deliverable never changes the URL under the domain either.

A domain for one page, or an address for one client

A hostname binds to one of two things. Bind it to a site and it serves that page, which is the flow above. Bind it to a client space and it serves that client's portal at the root, with every deliverable filed for them sitting at its own path underneath. acme.yourstudio.com stops meaning "this month's report" and starts meaning "the place Acme's work lives"; the bookmark holds while the ledger behind it grows. What sits behind the address is on client spaces.

A space address is counted as a client space rather than as a custom domain, so it does not come out of the 1, 10 or 25 above. Activated spaces, meaning ones with a hostname bound or a portal turned on, are 1 on Solo, 10 on Studio and unlimited on Firm. Filing work under a client is free on every plan.

Claim the parent domain once, skip the DNS per client

A CNAME and a TXT per hostname is fine for one or two addresses. It gets tedious when every client gets their own. So you can claim the parent domain instead: verify youragency.com once with a single TXT record, add one wildcard CNAME for *.youragency.com, and from then on each new acme.youragency.com needs no DNS work at all. No per-hostname TXT, no second wait on propagation; add the hostname and verify it in the same sitting.

The claim also reserves the namespace. Once youragency.com is verified to your account, no other Stacktree account can register a hostname beneath it, which matters precisely because a wildcard CNAME points everything under your domain at us. If your DNS is on Cloudflare, set that wildcard record to DNS-only.

White-label, all the way down

The domain is the visible half of white-labelling a client report. The other half: on paid plans, pages render with no Stacktree badge, so nothing on the page names the host. And if you gate the page with a password or an email-domain gate, the link unfurls in Slack and Teams as a locked graphic that leaks no title and no description. Your domain, your work, and no third-party fingerprints for the client to find.

The gate itself is quiet too. On your own hostname, a passcode-protected page asks for the passcode on a plain styled page that names neither us nor the product, rather than the browser's basic-auth dialog. The client types it once; on a client-space address that answer holds for 30 days across every deliverable in the space. There is still no account and no login for them to keep.

Domains an agent can buy for itself

Custom domains are a subscription feature (Solo 1, Studio 10, Firm 25), with one exception built for automation: an agent can purchase a single domain slot for $5 per 30 days over x402, settling in USDC on Base with no card and no human in the loop. A pipeline that publishes client reports can provision its own branded hostname the same way it publishes.