Changelog

Artifacts now supports jurisdictions, allowing you to select the European Union or the United States as the only location where repo data is stored and processed.

Select a jurisdiction when you create a namespace. Every repo in that namespace automatically uses the selected jurisdiction.

curl --request POST \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/artifacts/namespaces" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "namespace": "my-eu-namespace",
    "jurisdiction": "eu"
  }'

Jurisdictions cannot be changed after namespace creation. If you omit the jurisdiction, Artifacts creates an unrestricted namespace.

For supported jurisdictions and usage details, refer to Data localization.

You can now run your CI/CD pipeline on your Artifacts repo by defining a CI Workflow with the CI SDK ↗, automatically triggered on Artifacts push events.

This allows you to:

• Automatically build and deploy application code stored in Artifacts.
• Run linting, type checking, tests, and other checks on every push.
• Reuse dependencies when the lockfile (i.e. pnpm-lock.yaml) has not changed.
• Stop deployment when a check or build fails.
• Restrict API token access to the deployment step.
• Deploy the output to a Worker or a Workers for Platforms User Worker.

Define your CI steps with @cloudflare/ci. Each ci.runner() spins up an isolated sandbox, and the cache option reuses installed dependencies across each sandboxed step in your CI job.

Point cache.inputs at your lockfile (i.e. pnpm-lock.yaml, bun.lock), and the install step only runs again when that lockfile changes:

const deps = await ci.runner({
	name: "install",
	command: "bun install --frozen-lockfile",
	cache: { inputs: ["package.json", "bun.lock"] },
});

await Promise.all([
	deps.runner({ name: "lint", command: "bun run lint" }),
	deps.runner({ name: "test", command: "bun run test" }),
	deps.runner({ name: "typecheck", command: "bun run typecheck" }),
	deps.runner({ name: "build", command: "bun run build" }),
]);

await deps.runner({ name: "deploy", command: "bun wrangler deploy" });

const deps = await ci.runner({
	name: "install",
	command: "bun install --frozen-lockfile",
	cache: { inputs: ["package.json", "bun.lock"] },
});

await Promise.all([
	deps.runner({ name: "lint", command: "bun run lint" }),
	deps.runner({ name: "test", command: "bun run test" }),
	deps.runner({ name: "typecheck", command: "bun run typecheck" }),
	deps.runner({ name: "build", command: "bun run build" }),
]);

await deps.runner({ name: "deploy", command: "bun wrangler deploy" });

To start the Workflow automatically after each push, add a cf.artifacts.repo.pushed trigger to your Wrangler configuration:

{
	"triggers": {
		"events": [
			{
				"type": "cf.artifacts.repo.pushed",
				"filter": {
					"namespace": "CI",
					"repoName": "my-repo",
				},
				"target": {
					"scriptName": "my-ci-worker",
					"workflowName": "ci-workflow",
				},
			},
		],
	},
}

[[triggers.events]]
type = "cf.artifacts.repo.pushed"

  [triggers.events.filter]
  namespace = "CI"
  repoName = "my-repo"

  [triggers.events.target]
  scriptName = "my-ci-worker"
  workflowName = "ci-workflow"

To learn more, refer to Build and deploy Artifacts repos.

You can now configure Artifacts namespaces, repos, and tokens directly from the Cloudflare dashboard.

Artifacts is Git-compatible storage that lets you store repos on Cloudflare and interact with them using standard Git workflows.

You can view and create namespaces, which are top-level containers for repos:

You can view, create, fork, and search repos within a namespace:

You can open a repo to view its files and copy its Git remote URL.

You can also provision tokens directly from the dashboard to scope Git access to a single repo, with read tokens for clone, fetch, and pull workflows, or write tokens when a client needs to push changes.

To get started, go to the Cloudflare dashboard ↗ and select Storage & databases > Artifacts.

If you are enrolled in the Artifacts beta, you can use the dashboard to set up Artifacts. If you would like to join the beta, complete the request form ↗.

You can now receive event notifications for Artifacts repository changes and consume them from a Worker to build commit-driven automation.

This allows you to:

• Run custom workflows when a repository is created or imported
• Kick off a build and deploy a change when an agent pushes to a repo
• Trigger a review agent on every push

Available events include:

• Account-level events (artifacts source) — repo.created, repo.deleted, repo.forked, repo.imported
• Repository-level events (artifacts.repo source) — pushed, cloned, fetched

To learn more, refer to Artifacts documentation.

You can now manage Artifacts namespaces, repos, and repo-scoped tokens directly from Wrangler CLI.

Available commands:

• wrangler artifacts namespaces list — List Artifacts namespaces in your account.
• wrangler artifacts namespaces get — Get metadata for a namespace.
• wrangler artifacts repos create — Create a repo in a namespace.
• wrangler artifacts repos list — List repos in a namespace.
• wrangler artifacts repos get — Get metadata for a repo.
• wrangler artifacts repos delete — Delete a repo.
• wrangler artifacts repos issue-token — Issue a repo-scoped token for Git access.

To get started, refer to the Wrangler Artifacts commands documentation.

Artifacts is now in private beta. Artifacts is Git-compatible storage built for scale: create tens of millions of repos, fork from any remote, and hand off a URL to any Git client. It provides a versioned filesystem for storing and exchanging file trees across Workers, the REST API, and any Git client, running locally or within an agent.

You can read the announcement blog ↗ to learn more about what Artifacts does, how it works, and how to create repositories for your agents to use.

Artifacts has three API surfaces:

• Workers bindings (for creating and managing repositories)
• REST API (for creating and managing repos from any other compute platform)
• Git protocol (for interacting with repos)

As an example: you can use the Workers binding to create a repo and read back its remote URL:

# Create a thousand, a million or ten million repos: one for every agent, for every upstream branch, or every user.
const created = await env.PROD_ARTIFACTS.create("agent-007");
const remote = (await created.repo.info())?.remote;

Or, use the REST API to create a repo inside a namespace from your agent(s) running on any platform:

curl --request POST "https://artifacts.cloudflare.net/v1/api/namespaces/some-namespace/repos" --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" --header "Content-Type: application/json" --data '{"name":"agent-007"}'

Any Git client that speaks smart HTTP can use the returned remote URL:

# Agents know git.
# Every repository can act as a git repo, allowing agents to interact with Artifacts the way they know best: using the git CLI.
git clone https://x:${REPO_TOKEN}@artifacts.cloudflare.net/some-namespace/agent-007.git

To learn more, refer to Get started, Workers binding, and Git protocol.