Skip to content

Cloudflare.Pages reference

Source: src/Cloudflare/Pages/Deployment.ts

A direct-upload deployment on a Cloudflare Pages project.

Creating the resource POSTs a new deployment to the project and waits (bounded) for it to reach a successful deploy stage. Deployments are immutable — every prop change triggers a replacement (a brand-new deployment that supersedes the previous one).

The deployment is created with an empty asset manifest: the full direct-upload protocol (asset upload sessions driven by wrangler pages deploy) is not part of the public REST surface, so this resource cannot push file contents. It is useful for provisioning an initial/placeholder deployment on a direct-upload project (so the project’s *.pages.dev subdomain starts serving) and for rolling the active deployment from IaC. For deploying real static sites prefer Cloudflare.Website (Workers Assets).

Deleting the resource deletes the deployment (with force), except when it is the project’s active production deployment — Cloudflare refuses to delete the live deployment, so delete tolerates that case and the deployment is cleaned up when the project itself is deleted.

Production deployment on a direct-upload project

const project = yield* Cloudflare.Pages.Project("site", {});
const deployment = yield* Cloudflare.Pages.Deployment("site-deploy", {
projectName: project.name,
});
// deployment.url === "https://<shortId>.<project>.pages.dev"
// deployment.environment === "production"

Preview deployment from a non-production branch

const preview = yield* Cloudflare.Pages.Deployment("site-preview", {
projectName: project.name,
branch: "feature-x",
});
// preview.environment === "preview"

Source: src/Cloudflare/Pages/Domain.ts

A custom domain attached to a Cloudflare Pages project.

Attaching a domain starts Cloudflare’s validation flow: the domain must resolve to the project (typically via a CNAME record pointing at the project’s *.pages.dev subdomain) before its status becomes active. The resource does not wait for activation — compose it with Cloudflare.DNS.Record to create the CNAME, and certificate issuance completes asynchronously.

Both properties are the attachment’s identity, so every change triggers a replacement (detach + attach).

const project = yield* Cloudflare.Pages.Project("site", {});
const domain = yield* Cloudflare.Pages.Domain("site-domain", {
projectName: project.name,
name: "www.example.com",
});
yield* Cloudflare.DNS.Record("site-cname", {
zoneId: zone.zoneId,
name: "www.example.com",
type: "CNAME",
content: project.subdomain,
proxied: true,
});

Source: src/Cloudflare/Pages/Project.ts

A Cloudflare Pages project (direct-upload).

The project is the container for Pages deployments, custom domains, and per-environment configuration. Created without git source integration, it is a direct-upload project — deployments are pushed via the API or wrangler pages deploy.

The project name is its identity (it forms the <name>.pages.dev subdomain), so renaming triggers a replacement. productionBranch, buildConfig, and deploymentConfigs are all mutable in place.

Minimal project (generated name)

const project = yield* Cloudflare.Pages.Project("site", {});
// project.subdomain === "<generated-name>.pages.dev"

Named project with a build config

const project = yield* Cloudflare.Pages.Project("site", {
name: "my-site",
productionBranch: "main",
buildConfig: {
buildCommand: "npm run build",
destinationDir: "dist",
},
});
const project = yield* Cloudflare.Pages.Project("site", {
deploymentConfigs: {
production: {
compatibilityDate: "2026-08-31",
envVars: {
API_URL: { value: "https://api.example.com" },
API_KEY: { type: "secret_text", value: apiKey },
},
kvNamespaces: {
CACHE: kvNamespace.namespaceId,
},
},
},
});
const domain = yield* Cloudflare.Pages.Domain("site-domain", {
projectName: project.name,
name: "www.example.com",
});