|
1 | 1 | --- |
2 | 2 | title: How Artifacts works |
3 | | -description: Understand the distributed architecture behind Artifacts. |
| 3 | +description: Understand namespaces, repos, and durability. |
4 | 4 | pcx_content_type: concept |
5 | 5 | sidebar: |
6 | 6 | order: 1 |
7 | 7 | --- |
8 | 8 |
|
9 | | -Artifacts is built on [Durable Objects](/durable-objects/). Each repository maps to its own isolated unit of stateful compute. |
| 9 | +Artifacts creates Git repos on demand. Each repo is an isolated service with its own identity, access model, and durable state. |
10 | 10 |
|
11 | | -Each repository runs its own Git server and keeps persistent internal state on top of SQLite-backed Durable Object storage. A front-end Worker handles authentication and routing, then dispatches requests to the Durable Object for that repository. |
| 11 | +Each Artifacts repo is its own independent Git server, with its own remote URL, tokens, and durable state. |
12 | 12 |
|
13 | | - |
| 13 | +## Core model |
14 | 14 |
|
15 | | -## Stateful and isolated by repository |
| 15 | +Namespaces are the top-level container for repos. A repo lives inside one namespace, and its name is unique within that namespace. |
16 | 16 |
|
17 | | -Each repository in Artifacts is isolated from every other repository. Repository history, writes, and in-memory state do not need to be shared across unrelated workloads. |
| 17 | +A namespace provides the naming and routing boundary for repos. Together, the namespace and repo name form the repo's stable address, and API responses also return a repo ID. |
18 | 18 |
|
19 | | -[Durable Objects](/durable-objects/concepts/what-are-durable-objects/) fit this model because they combine stateful compute with durable local storage. Artifacts uses that foundation so repository operations run against a consistent, repo-local view of refs, objects, and metadata. |
| 19 | +Like [Durable Objects](/durable-objects/concepts/what-are-durable-objects/), a repo is a single logical instance that Cloudflare can route to from any region. |
20 | 20 |
|
21 | | -Persistent internal state lives on top of [SQLite-backed Durable Object storage](/durable-objects/api/sqlite-storage-api/). This keeps compute and storage together inside the same repository runtime instead of treating Git as a stateless layer in front of external storage. |
| 21 | +Because each repo is isolated, it has its own: |
22 | 22 |
|
23 | | -## Replicated and loaded on demand |
| 23 | +- Git history and refs |
| 24 | +- access tokens and remote URL |
| 25 | +- lifecycle and durable state |
24 | 26 |
|
25 | | -Artifacts repositories are replicated across multiple Cloudflare data centers by default. Repository snapshots are also written to object storage by default, so durable state does not depend on a single active in-memory instance. |
| 27 | +Repos can be created as needed. This lets Artifacts model many small units of work across separate repos. |
26 | 28 |
|
27 | | -A repository does not need to stay active everywhere at all times. Artifacts can load repositories quickly and on the fly when an agent, Worker, or Git client needs access. |
| 29 | +Forking follows the same model. A fork creates a new repo that starts from an existing repo's history, then diverges independently with its own tokens, routing, and lifecycle. |
28 | 30 |
|
29 | | -This separates active execution from durable storage. Repository state remains available even when a repository is not currently loaded in memory. |
| 31 | +Access is also repo-scoped. Each repo has its own tokens, and each token can be limited to a specific level of access: |
30 | 32 |
|
31 | | -## Addressable globally |
| 33 | +- `read` for clone, fetch, pull, indexing, and review |
| 34 | +- `write` for push and other mutations |
32 | 35 |
|
33 | | -Every repository has a unique identity and is addressable globally. Agents can access repositories they are authorized to use no matter where those agents are running. |
| 36 | +Your Worker or API layer decides when to mint those tokens. That keeps authentication and authorization outside the repo while still making the repo usable from Workers, the REST API, or any standard Git client. |
34 | 37 |
|
35 | | -Each repository is globally addressable and is not tied to a single machine or location. The entry Worker routes each request to the correct repository runtime, while Artifacts handles placement and loading behind the scenes. |
| 38 | +## Durability |
| 39 | + |
| 40 | +Artifacts is durable by default. A repo does not depend on one process staying alive or on one data center staying available. |
| 41 | + |
| 42 | +Behind the scenes, Cloudflare replicates repo data synchronously across multiple data centers and copies it asynchronously to object storage and snapshots. You do not need to build your own replication, failover, or snapshot pipeline to keep repository state available. |
| 43 | + |
| 44 | +Artifacts handles the Git server lifecycle and storage infrastructure underneath these Git workflows. |
36 | 45 |
|
37 | 46 | ## Learn more |
38 | 47 |
|
39 | | -For product updates, refer to the [Artifacts changelog](/artifacts/platform/changelog/). For background on the underlying model, refer to [Durable Objects: Easy, Fast, Correct — Choose three](https://blog.cloudflare.com/durable-objects-easy-fast-correct-choose-three/) and [Zero-latency SQLite storage in every Durable Object](https://blog.cloudflare.com/sqlite-in-durable-objects/). |
| 48 | +For repo patterns, refer to [Best practices for Artifacts](/artifacts/concepts/best-practices/). For token behavior, refer to [Git protocol](/artifacts/api/git-protocol/). For product updates, refer to the [Artifacts changelog](/artifacts/platform/changelog/). |
0 commit comments