First-Time Cloudflare Setup — Every Click

Do not delete persistent data blindly

A clean restart does not mean deleting D1, R2, your DNS zone, or the repaired Zero Trust organization. Those can contain persistent data or account-level configuration.

Keep the current Zero Trust team domain

For this deployment the intended team domain is iridesceux.cloudflareaccess.com. Open https://iridesceux.cloudflareaccess.com in a private window. If Cloudflare shows a valid Access/App Launcher/Welcome page, keep the organization. Do not rename or delete it.

Remove only the stale Command Access application if you are rebuilding Access

If an old Iridesceux Command application was created while the team domain was broken, delete that application only. Do not delete the entire Zero Trust organization.

Preserve or inventory D1 and R2

If iridesceux-command and iridesceux-command-assets already exist, keep them unless you are absolutely certain they contain only disposable test data. The later steps show how to verify/rebind them instead of recreating them unnecessarily.

Decide whether to keep or recreate the Command Pages project

If the existing Command *.pages.dev deployment loads correctly and Functions are deployed, you may keep the project. If you want a completely fresh Pages project, first note its project name, custom domain, bindings, and variables, then remove command.iridesceux.com from Custom domains before deleting the old Pages project.

Remove stale manual DNS for command only if it conflicts

Look specifically for a manually created command A/AAAA/CNAME that points somewhere other than the Pages project. Do not touch unrelated DNS records. When the domain is attached through Pages, Cloudflare can manage the correct record.

Revoke temporary team-repair API tokens

If you created a temporary token only to repair auth_domain, revoke it now unless you still need document 19. A one-time repair credential should not remain active indefinitely.

Start the numbered build from Step 1

From this point forward, make one change at a time and verify the expected result before continuing.

Make a clean working folder

Extract the full release ZIP into a normal folder. Do not run deployment from inside the ZIP viewer.

Install/confirm Git

git --version

If the command is missing, install Apple Command Line Tools when macOS prompts you.

Install/confirm Node and npm

node --version
npm --version

Node/npm are needed for Wrangler and the Broadcast Agent.

Decide your bootstrap email

Pick the exact email that will be your first Command Super Admin and that can receive Cloudflare OTP email. Write it down exactly; no aliases unless you intend to use that alias everywhere.

Create a PRIVATE repository

Name it something like iridesceux-hvn. Set visibility to Private. If you are pushing an existing folder, do not initialize it with a README that will create an unrelated first commit.

Initialize Git in the extracted package

cd "/path/to/Iridesceux-HVN-v20.6-Exhaustive-Documentation"
git init
git branch -M main
git status

Check that secrets are not about to be committed

find . -maxdepth 3 \( -name ".env" -o -name ".dev.vars" -o -name "wrangler.toml" \) -print

Review any results. Real secrets must not be committed. Example/template files are okay if they contain placeholders only.

Commit the monorepo

git add .
git commit -m "Initial Iridesceux HVN deployment package"

Attach the GitHub remote and push

git remote add origin https://github.com/YOUR-OWNER/YOUR-REPO.git
git push -u origin main

If origin already exists, use git remote -v and correct it with git remote set-url origin ....

Open Workers & Pages

Select Create / Create application and choose Pages with Git integration. Connect GitHub if Cloudflare asks.

Select the repository

Choose the Iridesceux/HVN private repository and production branch main.

Set the Command root directory

Open the advanced/root-directory control and enter exactly:

command-app

Set the framework/build settings

Use:

The code does not require a framework build. Cloudflare documents exit 0 as a valid no-op build command when not using a preset.

Deploy Command

Wait for the deployment to finish. Copy the generated *.pages.dev URL somewhere.

Prove Pages Functions deployed

Open https://YOUR-PROJECT.pages.dev/api/command/me.

At this point it may return a JSON error such as missing D1/authentication. That is okay. The key test is that it is a Function response — not your HTML homepage and not a Pages 404.

Create the D1 database

Select Create database. Recommended name:

iridesceux-command

Log Wrangler into Cloudflare

cd "/path/to/repo/command-app"
npx wrangler login

Approve the browser authorization using the same Cloudflare account that owns the project.

Load the entire schema into REMOTE D1

npx wrangler d1 execute iridesceux-command --remote --file=command-schema.sql

Verify tables exist

npx wrangler d1 execute iridesceux-command --remote --command="SELECT name FROM sqlite_schema WHERE type='table' ORDER BY name;"

Bind D1 to Command

Set Variable name exactly:

COMMAND_DB

Select the iridesceux-command database.

Redeploy after adding the binding

Trigger a new production deployment, or push a harmless commit. A binding added after a deployment does not retroactively change that already-running deployment.

Test D1 through Command

Open /setup-doctor.html and /api/command/me. Authentication may still fail, but D1 should no longer show “COMMAND_DB binding is not configured.”

Create the R2 bucket

If Cloudflare asks you to enable R2 billing/subscription, complete that account setup first. Then create a bucket named:

iridesceux-command-assets

Keep it private; R2 buckets are private by default.

Bind R2 to Command

Variable name must be exactly:

COMMAND_ASSETS

Select iridesceux-command-assets.

Redeploy again

Create a deployment after the R2 binding was added.

Do not test uploads yet if Access is not complete

The upload UI requires Command authentication. Continue to custom domain + Access first, then return to the R2 persistence test in Step 49.

Check for a conflicting manual DNS record

Search for a record whose name/hostname is command. If you previously created a manual A/AAAA/CNAME for Command and it is not the current Pages-managed record, remove the conflicting record before attaching the Pages custom domain.

Attach the domain from the Pages project

Enter exactly:

command.iridesceux.com

Continue/activate. Because the zone is already in the same Cloudflare account, Pages should manage the required DNS record.

Wait for Active

Do not proceed while the domain says Pending/Verifying/Initializing.

Test the hostname before Access

Open https://command.iridesceux.com. It may be temporarily unprotected for this short test. Verify it resolves to Command and not a 522.

Open Zero Trust

If Cloudflare asks you to initialize a Zero Trust organization, complete the organization setup. The intended team domain for this deployment is:

iridesceux.cloudflareaccess.com

Confirm the team name/domain in Settings

Copy the exact current team domain from Cloudflare. For this deployment it should be:

iridesceux.cloudflareaccess.com

Do not confuse this with command.iridesceux.com. The first is the Access organization domain; the second is the protected application.

Directly test the team domain

Open:

https://iridesceux.cloudflareaccess.com

A valid organization may show an App Launcher, login page, or “Welcome — enable App Launcher” message.

Open Identity providers

Check whether One-time PIN already exists.

Add One-time PIN if missing

Select One-time PIN and save. New Zero Trust organizations may use Cloudflare as the default provider; OTP is not necessarily added automatically.

Enable the Pages Access policy

Find Enable access policy and enable it for the Command Pages project. Cloudflare documents this as the supported way to secure the project *.pages.dev address and preview deployments.

This matters because the package mirrors internal documentation under command-app/public/docs; protecting only command.iridesceux.com would otherwise leave the raw Pages hostname as an alternate path.

Verify both the project pages.dev URL and preview URLs are protected

Follow Cloudflare's Pages procedure: manage the Pages-created Access application, ensure the non-wildcard project hostname is protected, then re-enable preview protection so both the main PROJECT.pages.dev and preview pattern *.PROJECT.pages.dev are covered. Configure the policies so only intended identities can enter; for this setup use One-Time PIN with the same exact bootstrap email while testing.

Then open the raw https://PROJECT.pages.dev URL in Incognito. You should see Access before Command.

Create a new Access application

Select:

Self-hosted and private

Then choose:

Add public hostname

Name the application

Iridesceux Command

Set the protected public hostname

Use:

Blank path means protect the entire hostname.

Create the Allow policy

Use:

Do not use Include → Everyone. Do not use “Emails ending in” unless you deliberately want the whole domain allowed.

Select One-Time PIN

Select One-time PIN. If it is the only login method, instant authentication may be on or off; either can work. For troubleshooting, leaving it off gives you the normal Access login screen.

Set session duration

24 hours

Cloudflare documents 24 hours as the default application session duration. This is reasonable for initial Command setup.

Leave private-network/clientless isolation settings alone

Do not enable Browser Isolation/clientless private-destination options. Command is a public-hostname self-hosted app, not a private-network destination. Leave custom CORS/cookie/block-page settings at defaults unless you have a separate requirement.

Create/save the application

Save the application. If Cloudflare errors about clientless isolation/private destinations, go back to Additional settings and turn that feature off.

Copy the Application Audience (AUD) Tag

Find Application Audience (AUD) Tag. Copy the exact value. Treat it as configuration, not a password, but do not casually publish internal identifiers.

Set Command variables

Add these as normal plaintext variables:

BOOTSTRAP_ADMIN_EMAIL=YOUR-EXACT-LOGIN-EMAIL
CF_ACCESS_TEAM_DOMAIN=https://iridesceux.cloudflareaccess.com
CF_ACCESS_AUD=PASTE_CURRENT_APPLICATION_AUD
COMMAND_REQUIRE_ACCESS_JWT=true

Keep COMMAND_ALLOW_HEADER_AUTH unset or false in production.

Redeploy after variables change

Trigger a new production deployment after changing the variables. Do not test an older deployment.

Start with a fresh Incognito window

Open https://command.iridesceux.com. You should hit Cloudflare Access before the Command app.

Request and enter a new OTP

Enter the exact email allowed in the policy. Request the code. Use the newest code Cloudflare sends.

Verify the backend identity

Open:

https://command.iridesceux.com/api/command/me

The first successful login with the bootstrap email should create/recognize the Command user as Super Admin.

Run Setup Doctor

Open:

https://command.iridesceux.com/setup-doctor.html

Core checks should identify Functions, D1, Access JWT, and R2 configuration. Optional workers/OBS can still be unconfigured.

Test R2 persistence now

Upload one small disposable image/file under the app upload limit, refresh the page, and verify the asset still exists. The generic Command asset route currently enforces a 25 MB limit; use your video/storage workflow for large program masters.

Create Iridesceux Pages project

Connect the same private Git repo. Root public-site, framework None, build exit 0, output public.

Do not attach the production apex until launch rehearsal

Keep the production domain unchanged if the public site is still coming soon/offline. Use the Pages staging URL for testing.

Create HVN Pages project

Same repo. Root hvn-site, framework None, build exit 0, output public.

Bind shared D1/R2 to HVN if required by the deployed functions

Use exact binding names COMMAND_DB and COMMAND_ASSETS where HVN Functions depend on the shared presentation/account/media state. Optional binding: HVN_ANALYTICS. Optional variable: HVN_REALTIME_URL.