Your AI agent ships the landing page.
You set the boundaries.

Before you start

Use one Outloop Workspace for the client’s brief, site files, approved accounts and operating rules. This walkthrough follows a static-site implementation using Claude Code; other runtimes need their own workflow validation.

You need a private GitHub repository, a Cloudflare account with the intended domain’s zone, Outloop on a company-controlled Mac, a supported agent runtime, and a static export or site framework. R2 activation can require a payment method. Check provider plans and usage limits before enabling paid services.

The owner approves the GitHub App, creates and enters the two provider tokens directly in Outloop, enables R2, and approves production domain routes. Agree in advance which routine page changes the agent may publish. New access, spending and deletion of a whole site remain owner decisions.

1. Create a private repository

In GitHub, choose New repository → Private, add a README and create the repository. A neutral name such as ai-landing-pages makes the purpose clear. Keep each client’s source and configuration in the intended repository.

The reusable framework separates site content from its routing rules:

sites/<site-id>/site.json    domains, redirects and response headers
sites/<site-id>/public/     HTML, images, styles and scripts
src/worker.js               Worker entry point
src/router.js               host routing, redirects and media
scripts/build.mjs          build and validation
scripts/import_zip.py      static-export import
wrangler.jsonc             Worker, assets, R2 and routes

See the completed private repository

2. Connect Workers Builds to GitHub

Owner approval: install the Cloudflare Workers and Pages GitHub App for Only select repositories, and select this repository.

In Cloudflare, open Workers & Pages → Create → Continue with GitHub, select the repository and configure the build:

Setting	Reference configuration
Production branch	main
Build command	npm run build
Deploy command	npx wrangler deploy
Non-production deploy command	npx wrangler versions upload
Non-production branch builds	Enabled
Root directory	/

A production-branch push is a publication action. Use a branch preview when review is required, and confirm the build settings before pushing. The reference project observed about 60 seconds from push to live; build duration is not guaranteed.

See the Worker list and overview

3. Configure the Worker

The framework routes each hostname to its site, serves static files through ASSETS, and serves large videos through an R2 binding named MEDIA. It applies redirects and response headers before serving content.

This is an illustrative configuration. Replace the names and domains with your approved resources. Add production routes only after Step 8 is authorized. Select a compatibility date appropriate to your tested Worker.

{
  "name": "ai-landing-pages",
  "main": "src/worker.js",
  "compatibility_date": "2025-10-01",
  "workers_dev": true,
  "preview_urls": true,
  "assets": {
    "directory": "./dist",
    "binding": "ASSETS",
    "run_worker_first": true,
    "html_handling": "none",
    "not_found_handling": "none"
  },
  "r2_buckets": [{ "binding": "MEDIA", "bucket_name": "lp-media" }],
  "observability": { "enabled": true },
  "vars": { "LP_PROJECT": "ai-landing-pages" }
}

The supplied router handles hostname isolation, path-traversal rejection, 301 redirects that retain query strings, video Range requests, content types and security headers. Its /__lp/health endpoint reports the deployed revision. Confirm these behaviors in your own build; a configuration example is not a substitute for testing.

4. Create the provider tokens

Owner action: create the tokens in the providers’ own interfaces and enter them directly into Outloop. Never paste token values into a prompt, source file or screenshot.

GitHub: one repository

Create a fine-grained personal access token. Select the resource owner and Only select repositories, then the intended repository.

Repository permission	Access in the reference setup
Contents	Read and write
Pull requests	Read and write
Commit statuses	Read
Deployments	Read
Metadata	Read (automatic)

Contents must be read and write for the Git Data API workflow. Organization policies may require approval. Grant only the operations your workflow needs.

Token setup: read the permission warning in this source capture

Cloudflare: review the scope before saving

Open My Profile → API Tokens → Create Token → Create Custom Token. The source project used the permissions below. This is its reference permission inventory, not a universal minimum.

Scope	Permission	Reference access / purpose
Account	Workers Scripts	Edit — Worker versions and deployments
Account	Workers Builds Configuration	Edit — build configuration and triggers
Account	Workers R2 Storage	Edit — media bucket and objects
Account	Workers Observability	Edit — reference telemetry setup
Account	Workers Tail	Read — diagnostics
Account	Account Settings	Read — account information
Account	Workers KV Storage, D1	Optional Edit in the source; omit unless actually used
Zone	Zone	Read
Zone	DNS	Edit only if authorized DNS operations are needed
Zone	Workers Routes	Edit — route setup
Zone	SSL and Certificates	Edit in the source; assess against the intended work
Zone	Zone Settings	Edit in the source; assess against the intended work
Zone	Cache Purge	Purge — when required

Set Account Resources to the intended account and Zone Resources to the specific zone. Remove unused permissions and unused operations from the template. Recheck required permissions against the provider’s current interface; restrict the token as well as the Outloop service.

More token setup screens and scope notes

5. Enable R2 for video

Owner action: enable R2 and approve any billing setup. The agent can then create the approved bucket and upload media through the configured Outloop operations.

The reference site stored 178 videos, totaling approximately 1.36 GB, in R2. The Worker served them at the site’s existing paths with Range support for seeking. Storage, requests and Worker execution have separate limits; a small media library alone does not establish a zero-cost service.

6. Connect the two Custom APIs in Outloop

In the intended Workspace, open API Access → Add key, search for the service, and choose Add a custom service.

Field	GitHub	Cloudflare
Service name	GitHub API	Cloudflare API
Example service ID	github-api	cloudflare-api
Base URL	https://api.github.com	https://api.cloudflare.com
Authentication	Bearer token	Bearer token
First read path	Leave empty for this setup	Leave empty for this setup
Credential	Owner enters the GitHub token	Owner enters the Cloudflare token

The source walkthrough saves the custom service and its credential in the same form. Then open Edit configuration → Advanced configuration · JSON. Render the template with your own resource identifiers; apply the JSON, validate it, save, and complete Confirm and save. Enable access for the intended Workspace. Enable destructive operations only when the owner has authorized that capability.

API Access before configuration was complete

What the templates contain

The supplied GitHub template has 25 operations: 14 read, 9 write and 2 destructive. They cover repository inspection, Git objects, branch references, file changes, pull requests, merges and deployment status.

The Cloudflare template has 31 operations: 16 read, 11 write and 4 destructive. They cover Worker versions and deployments, builds, routes, domains, DNS, cache and R2.

Scope matters: GitHub paths contain the owner and repository placeholders. Cloudflare paths contain account, zone, Worker or bucket placeholders where applicable. Some list/create operations are account-scoped, and some build/domain identifiers remain parameters. Do not describe every operation as restricted to one Worker or bucket without reviewing its path, body and provider permissions. Remove capabilities you do not intend to grant.

Definition rules used by this walkthrough

• Mark required path properties with "required": true; path parameters cannot introduce / delimiters.
• Bind query parameters explicitly, for example "query": {"per_page": {"parameter": "per_page"}}.
• Put JSON payloads in a body object parameter and set "body_parameter": "body".
• Give arrays items and objects properties. Use "nullable": true for nullable fields.
• Define file uploads with "format": "binary" and "body_sources": ["file"]; use the supported upload verb.
• Mark DELETE operations destructive. The classification does not replace authorization for the task.

Validate the rendered definition in your installed Outloop version. Start with bounded reads such as repository details and Worker versions. Test a write only on an authorized disposable fixture. The source project used repo_get and blob_create for GitHub, plus zone_get and versions_list for Cloudflare. A successful read alone does not prove write access.

7. Import and build the site

Download the reusable skill below and inspect its instructions and scripts before use. Its included framework supplies the import and build tooling. Keep client-specific configuration in the client’s own Workspace.

The following example uses a placeholder site ID and a local static export:

python3 scripts/import_zip.py client-export.zip --site example-site --mode static \
  --media-out ../media-staging/example-site --media-ext mp4,mov,webm,m4v
npm run build
npm test

HTML, images, CSS and JavaScript belong in sites/example-site/public/. Video files go to media staging and then to the approved R2 bucket. The reusable push tool creates Git blobs and trees, then a commit and branch update through Outloop. Review the target branch because updating the production branch triggers deployment.

Configure the site’s domains, redirects and media settings in site.json. Decide indexing rules deliberately: an ads-only page may need noindex, while an organic-search page usually has a different requirement. The source site’s indexing choice should not silently become every client’s default.

8. Approve and attach domain routes

Owner approval: confirm the exact production hostnames and the existing origin before changing routes. Add the hostnames to the site configuration, then add the approved routes to wrangler.jsonc:

{
  "routes": [
    { "pattern": "example.com/*", "zone_name": "example.com" },
    { "pattern": "www.example.com/*", "zone_name": "example.com" }
  ]
}

The reference project used existing proxied DNS records, so switching traffic used Worker routes without changing those records. This depends on the existing DNS/proxy setup. Do not change mail records or assume a different domain is already configured the same way.

Before switching, record the current origin, routes and deployment. Removing routes can restore the previous origin only while that origin and its DNS setup remain available. Version rollback and routing rollback solve different problems.

See the DNS screen with private values blurred

9. Verify the deployed result

Check the build and deployed commit, then the actual public pages. The reusable skill includes the following commands; <skill> means its installed directory, and lp.config.json must point to this Workspace’s approved resources.

python3 <skill>/scripts/wait_deploy.py <commit-sha>
python3 <skill>/scripts/live_check.py https://example.com example-site
python3 <skill>/scripts/selftest.py example-site /approved-test-source/

The self-test creates, publishes, changes and removes a test page. Obtain authorization for those effects and use an approved test location. Validate page status, internal assets, video playback and seeking, redirect destinations and retained query parameters. Check the health endpoint against the commit you intended to deploy.

Record the results and the recovery point. Test forms, analytics, consent behavior and third-party embeds separately when they are in scope; a static-file check does not prove a complete conversion journey.