Skip to content

Deploy on Cloudflare

The live-qualified Artifact Server deployment path that uses Workers, D1, R2, and Alchemy.

Updated View as Markdown

Cloudflare is Artifact Server’s live-qualified direct-cloud target. The deployment package runs the same product services on Cloudflare infrastructure.

Product need Cloudflare service
Application and HTTP runtime Workers
Durable records D1
Artifact and staged-upload bytes R2
Provisioning and lifecycle Alchemy
Hosted browser and MCP authorization WorkOS
Optional private Git history Cloudflare Artifacts

Current release boundary

The current source revision is newer than the live staging revision. Browser and conformance verification cover the later UI and MCP-link changes. The staging pass did not include manual verification of those changes.

The staging pass verified these operations:

  • Browser sign-in through WorkOS.
  • Publication and exact-version Review.
  • Private HTML, image, and video previews.
  • Pi, OpenCode, Claude Code, and MCP mailbox delivery.
  • Coordinated D1 and R2 recovery.
  • A bounded Cloudflare Artifacts lifecycle.

The Git-history run used 530 fixture bytes. It did not apply quota pressure or load pressure.

The checked-in deployment package lives in deploy/cloudflare. It pins Alchemy, Wrangler, Workers types, and the Cloudflare compatibility date. Team and CI deployments use Cloudflare-hosted Alchemy state.

Deployment shape

artifactserver.com        public Artifact Server home and Nimbus docs
app.example.com           trusted Artifact Server Worker
*.content.example.com     isolated artifact versions

The public site and a deployed Artifact Server installation are separate Workers. Each Worker has its own routing and security policy.

Operate the package

From deploy/cloudflare, authenticate to the approved account. Then use the pinned lifecycle commands:

pnpm plan
pnpm deploy
pnpm destroy

The deployment requires a Cloudflare account, two domains, D1 and R2 bindings, identity-provider settings, and Cloudflare-hosted Alchemy state. Read deploy/cloudflare/README.md before you create resources.

Optional Cloudflare Artifacts history

Cloudflare Artifacts can keep a private Git copy of selected projects. It is off by default. Artifact Server’s D1 and R2 data remains authoritative. The integration creates one repository for each artifact. A durable queue copies new and existing versions. The integration issues bounded read tokens for clones.

Set cloudflareArtifactsNamespace in the deployment input. After deployment, open Projects. Review the estimate. Then enable Git history for each selected project. Disabling Git history preserves the derived repositories. Deleting an artifact queues deletion of its repository.

Read the operational guide for namespace isolation, runtime states, copy limits, recovery, qualification, and clone or purge commands.

Navigation

Type to search…

↑↓ navigate↵ selectEsc close