Install the Checkpoint Gateway on a domain that already serves content from Vercel, DreamHost, WordPress, or similar hosts

When to use this guide

Use this setup if your domain already serves a live site from a hosting provider (Vercel, Netlify, Cloudflare Pages, Railway, Render, DreamHost, WordPress, Squarespace, cPanel, etc.) and you want to put the Checkpoint Gateway in front of it without downtime.

The challenge: once you point your domain at the Gateway, your hosting provider can no longer serve content on that hostname — DNS now resolves to Cloudflare's edge instead of their servers. The Gateway needs somewhere to forward traffic to. That's what the origin sidecar subdomain is for.

Before:
  yourdomain.com → [Hosting Provider] → your site

After:
  yourdomain.com         → [Checkpoint Gateway] → detects agents
                                               ↓
  origin.yourdomain.com  → [Hosting Provider] → your site

The visitor still types yourdomain.com. They never see origin.*. The Gateway uses it internally to reach the real backend.

Prerequisites

A Checkpoint project
Access to your domain's DNS
Access to your hosting provider's domain settings

Time Estimate

10 minutes plus DNS propagation.

Steps

Pick the sidecar hostname

Choose a subdomain prefix for the hidden backend. Convention: origin.

If protecting example.com → sidecar is origin.example.com
If protecting shop.example.com → sidecar is origin.shop.example.com

Keep this hostname unpublished — it's only used by the Gateway.

Attach the sidecar to your hosting provider

Tell your hosting provider: "also serve the existing site at origin.yourdomain.com."

Open your Vercel project → Settings → Domains
Click Add Domain, enter origin.yourdomain.com
Vercel shows required DNS records. You can use either:
- CNAME → cname.vercel-dns.com (Vercel's recommendation), or
- A record → 76.76.21.21 (Vercel's anycast IP — interchangeable)
Copy whichever target Vercel displays — you'll add it in the next step.

Netlify site → Domain management → Add domain alias
Enter origin.yourdomain.com
Netlify will instruct you to add a CNAME to <site>.netlify.app or an A record to their load balancer IP.

Pages project → Custom domains → Set up a custom domain
Enter origin.yourdomain.com
Cloudflare auto-configures DNS if the domain is on Cloudflare.

Hosting panel → Manage Websites / Add Domain
Add origin.yourdomain.com pointing at the same document root as your current site
Your hosting provider will give you either a shared IP (A record) or a hostname (CNAME) to use in DNS.

Add the sidecar DNS record

In your DNS provider, add the record your host asked for:

Type:   A (or CNAME — whichever your host specified)
Name:   origin
Target: <IP or hostname from host>
Proxy:  DNS only (grey cloud on Cloudflare)
TTL:    Auto

Verify before continuing:

curl -I https://origin.yourdomain.com
# Should return 200 OK and serve your existing site.

Do not proceed until origin.yourdomain.com returns 200 and shows your site. If the Gateway has nothing to forward to, your main domain will 502 after you add the gateway CNAME.

Register the Gateway in the Checkpoint dashboard

Dashboard → Settings → Enforce → Add Gateway
Hostname: yourdomain.com (or the apex/subdomain you want protected)
Origin URL: https://origin.yourdomain.com ← the sidecar, not the hosting-provider hostname directly
Submit

The dashboard returns three records: an apex CNAME, an _acme-challenge CNAME, and a _cf-custom-hostname TXT.

Add the three Gateway records to DNS

Paste the dashboard values into your DNS provider. All records are DNS only (grey cloud on Cloudflare):

Type:   CNAME
Name:   @  (or yourdomain.com)
Target: cname.checkpoint-gateway.ai   ← from dashboard
Proxy:  DNS only

Type:   CNAME
Name:   _acme-challenge
Target: <hash>.dcv.cloudflare.com      ← from dashboard

Type:   TXT
Name:   _cf-custom-hostname
Value:  <token>                        ← from dashboard

On Cloudflare DNS, all records must stay grey-cloud (DNS only). Orange cloud proxies your Gateway through another Cloudflare layer and breaks SSL/routing.

Verify end-to-end

Wait 1–5 minutes for DNS + SSL provisioning, then:

# Sidecar still working standalone:
curl -I https://origin.yourdomain.com
# 200 OK, served by hosting provider

# Apex now flows through the Gateway:
curl -I https://yourdomain.com
# 200 OK, cf-ray header present, origin content returned

# Simulate an AI agent to confirm enforcement:
curl -I -H "User-Agent: GPTBot/1.0" https://yourdomain.com
# 403 (if policy blocks AI agents)

Dashboard → Analytics should show traffic appearing for the new project.

Final DNS state

After complete setup, your DNS should contain (at minimum):

Type	Name	Target	Proxy
CNAME	`@`	`cname.checkpoint-gateway.ai`	DNS only
CNAME	`_acme-challenge`	`<hash>.dcv.cloudflare.com`	DNS only
TXT	`_cf-custom-hostname`	`<token>`	—
A or CNAME	`origin`	Your hosting provider's IP/hostname	DNS only

Plus any existing records your host requires (e.g., Vercel's _vercel ownership TXT, email MX records, etc.).

Troubleshooting

`yourdomain.com` returns 502 after adding Gateway CNAME

The Gateway can't reach the sidecar. Check:

origin.yourdomain.com resolves correctly (dig origin.yourdomain.com +short)
It serves 200 standalone (curl -I https://origin.yourdomain.com)
The Origin URL in the dashboard is https://origin.yourdomain.com (with the scheme)

SSL certificate stuck "provisioning"

The _acme-challenge CNAME must be live before issuance
Check for conflicting CAA records at the apex
If on Cloudflare, all records must be DNS only (grey cloud)

Hosting provider says "domain not verified"

Some hosts require an ownership TXT record (e.g., Vercel's _vercel) in addition to the traffic record. Keep those — they don't conflict with the Gateway records.

Apex records keep getting rewritten

If your hosting provider has access to your DNS (e.g., Vercel-managed DNS), it may auto-recreate records you've deleted. Either:

Remove the domain attachment from the hosting provider except for the sidecar subdomain, or
Move DNS to a provider your host doesn't control

Why two subdomains instead of pointing origin directly?

You might wonder: "why not just set Origin URL to https://my-app.vercel.app directly and skip the sidecar?"

You can, and it works. But:

Branding — Logs and analytics will show my-app.vercel.app as the origin, which leaks your hosting choice.
Provider portability — A sidecar hostname you control lets you swap hosts without touching Gateway config.
Consistency across providers — The sidecar pattern works the same whether your backend is Vercel, DreamHost, or bare-metal. Single install flow, single troubleshooting guide.

For a single-provider setup where these don't matter, setting Origin URL directly to the provider-assigned hostname is fine.

Next Steps

Goal	Next Cookbook
Subdomain-only (no sidecar) setup	Gateway Setup
Fine-tune policies	Policy Configuration
Code-level enforcement	Middleware Enforcement

Enforce: Gateway + Origin Sidecar