First-Time Cloudflare Setup
This guide intentionally brings Command online before the public websites. Follow every step in order.
Before Step 1
- Use the v20.4 package.
- Have a Cloudflare account and a private GitHub/GitLab repository available.
- Have the email you want as the first Super Admin.
- Do not test by double-clicking
index.html; that is intentionally demo mode.
Phase 1 — deploy Command only
Put the package in a private Git repository
Commit the project while keeping command-app/functions/ exactly where it is. Git integration is recommended because Command uses Pages Functions.
Create the Command Pages project
Cloudflare → Workers & Pages → Create → Pages → connect the repository. Use command-app as the project root.
The first deploy may show setup errors. That is expected until D1 and identity are attached.
Confirm Functions were deployed
Open the deployed URL and then /api/command/me. A JSON 401 or 503 is actually useful: it proves the Function exists. A normal HTML 404 means the Functions directory was not deployed correctly.
Phase 2 — create the real database
Create D1
Cloudflare → Storage & Databases → D1 → Create. A name such as iridesceux-command is fine.
Apply the schema
From a terminal in command-app, use Wrangler against the remote D1 database:
Run it once for the new database. The schema uses IF NOT EXISTS for repeat-safe table creation.
Bind D1 to Command
Pages project → Settings → Bindings → D1 database. Binding name must be exactly COMMAND_DB. Configure the environment you are actually testing—Production and/or Preview—then redeploy.
Phase 3 — make the first real login
Set the bootstrap email
In Command's Pages environment variables, add BOOTSTRAP_ADMIN_EMAIL with the exact email that Cloudflare Access will authenticate.
Protect Command with Cloudflare Access
Recommended: attach command.iridesceux.com now and protect that entire hostname with Access. This does not launch the Iridesceux public website. If you stay on pages.dev, configure Access for that Pages hostname/preview environment before expecting the user-email header.
Redeploy and sign in
Visit Command through the Access-protected URL. On the first successful request, if your authenticated email matches BOOTSTRAP_ADMIN_EMAIL, Command creates the first super_admin record.
Run Setup Doctor
Open /setup-doctor.html. You want Functions = good, identity = good, and the D1 checks to pass. Optional integrations may still show not configured.
Phase 4 — turn on real uploads
Create an R2 bucket
Create a private R2 bucket for Command/HVN operational assets.
Bind R2
Bind that bucket to Command as exactly COMMAND_ASSETS for the environment you are testing, then redeploy.
Test one disposable upload
Upload a tiny image/video in Command. Refresh the page and confirm it remains in inventory. Delete or disable the test item afterward.
Phase 5 — only after Command works
Now you may deploy Iridesceux and HVN to staging/preview URLs and bind the shared resources they need. Neither public custom domain has to be launched yet. OBS/broadcast-agent setup comes after that.
v20.4 — required deployed-auth settings
For a deployed Command environment, do not rely on a forwarded email header by itself. Configure the Access application and then set all of these on the Command Pages environment:
COMMAND_ALLOW_HEADER_AUTH=true on the deployed Command site. That escape hatch exists only for deliberate local development/troubleshooting.command-app/public/, while command-app/functions/ stays at the Pages project root. Cloudflare documents that the /functions directory belongs at the project root rather than inside the static output directory.Deployment method matters
Command uses Pages Functions. Keep command-app/functions/ at the Pages project root and deploy with Git integration or Wrangler. Do not use a dashboard drag-and-drop upload as the deployment method for the functional Command application.
After any D1/R2 binding or environment-variable change, redeploy the environment you are testing.
Minimum point where Command is “real”
You do not need Iridesceux, HVN, OBS, analytics, Git integrations, or the vault finished. Command leaves demo mode once it is served from the real backend and can authenticate to its deployed Functions. Setup Doctor now separates CORE requirements from optional systems.