Connecting a domain
Verify your domain, choose how Iterant pages are served from it, and confirm your proxy is forwarding traffic.
Once you publish, your site is live on an Iterant-provided URL. Connecting your own domain puts your brand in front of visitors and search engines instead.
There are two independent parts: proving you own the domain (a DNS record), and routing traffic on it to Iterant (a proxy rule on whatever already serves that domain). The second part unlocks after the first succeeds.
Prerequisites
- Access to your domain's DNS settings.
- Access to whatever currently serves that domain (your CDN, web server, or hosting platform) if you already have a site there.
Step-by-step
Add the domain
Go to Settings → Domains and click Add Domain. Enter the domain without http:// or www, then Continue.
A domain can only be connected to one Iterant brand. If it's already attached elsewhere, Iterant tells you instead of taking it over.
Add the verification record
Iterant shows you a DNS record to create, with Record Type, Host / Name, Value, and TTL fields and a copy button on each.
The record type is always TXT, and the host is always the _iterant-verification prefix on your domain. The value is unique to your domain, so copy it from the modal. Set TTL to 300, or the lowest your provider allows.
The modal links to record-adding instructions for common providers: Cloudflare, GoDaddy, Namecheap, Google Domains, and AWS Route 53.
Click I've added the record. You can close the dialog, and verification keeps running in the background.
Wait for verification
Iterant checks public DNS resolvers, and retries with growing gaps for a while before giving up.
The domain carries one of three statuses in the list:
| Status | Meaning |
|---|---|
| Pending | The record hasn't been found yet. Checks are still running. |
| Verified | The record matched. Deployment configuration unlocks. |
| Failed | Checking gave up. Fix the record and try again. |
To force a check, open the row menu → View details → Check verification.
DNS changes can take up to 48 hours to propagate, though most are visible within a few minutes. Pending shortly after adding the record is normal.
Configure deployment
Once the domain is Verified, the row menu offers Configure deployment. This is a four-step wizard (Routing, Method, Caching, Setup) that produces the proxy configuration for wherever your domain is served from today.
It does not change your DNS or touch your existing site. It generates the rule you add.
Routing
Choose how Iterant pages appear on your domain:
| Option | Looks like | Requirements |
|---|---|---|
| Path-based | yourdomain.com/feed/* | Works with all providers including Vercel and Netlify. |
| Subdomain | feed.yourdomain.com | Requires a full reverse proxy: Nginx, Apache, or a Cloudflare Worker. Platforms like Vercel and Netlify cannot proxy subdomains. |
The path (or subdomain label) is yours to set, and a URL Preview shows the resulting page URLs as you type.
Method
- Deploy to Cloudflare (recommended) deploys a proxy worker to your own Cloudflare account in one click. No server required, though you need a free Cloudflare account.
- Manual Setup lets you pick your provider, and Iterant generates the config files. Available providers: Cloudflare Worker, Nginx, Apache, Traefik, AWS CloudFront, Netlify, Vercel, Next.js Middleware. Netlify, Vercel and Next.js Middleware are path-based only, so choosing Subdomain routing narrows the list accordingly.
Caching
This step appears only for providers that support edge caching (Cloudflare and AWS CloudFront). Turn on Enable edge caching and pick a Cache Duration (TTL): 1 hour, 6 hours, 24 hours, or 1 week.
Setup
What you see depends on the method:
- Cloudflare (automatic): after the worker deploys, the wizard walks you through adding the route pattern in your Cloudflare dashboard and confirming that a real page loads through it.
- Manual: each config file appears in full with a Download Configuration button, followed by provider-specific setup instructions.
Finish with I've completed the setup.
After setup: the verification checks
The setup step carries three verification sections.
Reachability
"Whether your live pages resolve on your own domain. Checked automatically after each publish."
Iterant probes one real published page per path prefix on your domain and confirms the response came from Iterant. A catch-all page on your own site answering 200 reads as not reachable.
When a prefix fails, the section prints the missing rule inline.
Forms
"Whether a form submission reaches us through your proxy. Run this before relying on lead capture."
Click Check forms. Iterant sends a synthetic submission through your real proxy and confirms the record landed on the other side. A proxy that answers 200 without forwarding the body fails this check.
The classic failure is a CDN that only allows GET and HEAD. On failure the section prints the fix for your specific provider.
Run this before you depend on lead capture. A proxy that drops POST looks identical to a form no one fills in.
Proxy coverage
"The paths you have reverse-proxied to Iterant. We check these against what is actually resolving on your domain."
The wizard records the rules it generated, and you can add your own paths to the list. Each rule reads as proxied and reachable, proxied, not resolving yet, proxied, not checked yet, or reachable, but no recorded rule. The last one means Iterant pages are live at a path you never recorded.
Extra rules you may need
Two cases the wizard flags for you:
- Other languages. Each additional language is served from its own path (for example
/es/…), outside your main folder. The Serving other languages? section takes the language codes you plan to serve and generates the extra rule. Subdomain routing needs nothing here, since it already forwards every path. - Pages at your site root. If some of your pages live at the root (say
/about), the wizard warns rather than generating a rule: a greedy/*proxy captures your entire domain. Set that up by hand only if Iterant owns the whole site.
Removing a domain
Row menu → Remove. This disconnects the domain from your brand, and any deployment configuration is lost. Your DNS records stay where they are, so remove the verification TXT record yourself if you no longer want it.
Troubleshooting
Next
Publishing your site: how preview, publish, and republish work.
Last updated on