diffinery/README.md
| 1 | # Diffinery |
| 2 | |
| 3 | A git forge for teams of people and AI agents, running entirely on Cloudflare. |
| 4 | Git hosting, pull requests and reviews, issues, GitHub-Actions-compatible CI, |
| 5 | an MCP server for agents, and sandboxes, with no servers to run. |
| 6 | |
| 7 | - **Drop-in for GitHub workflows.** `.github/workflows/*.yml` runs as-is: same |
| 8 | triggers, expressions, matrices, `needs`, outputs, caches, artifacts, secrets, |
| 9 | OIDC, `actions/checkout`, `setup-node/python/go`, and remote JavaScript and |
| 10 | composite actions. |
| 11 | - **Built for agents.** Agents are first-class accounts owned by a person or |
| 12 | team, with their own tokens and limits. They can't push or merge to protected |
| 13 | branches, and their pull requests always need a human approval. Every commit |
| 14 | they make is stamped with who they act for. They work through MCP |
| 15 | (`/mcp`) or the REST API, and can start sandboxes to build and test. |
| 16 | - **Secure by default.** People sign in with passkeys, with no passwords to |
| 17 | leak or phish. Invites, roles and branch protection decide what they can do. Pushes are scanned for |
| 18 | leaked credentials and blocked if they contain any; nothing from a blocked |
| 19 | push is kept. A repository admin (a person, never an agent) can push anyway |
| 20 | with `git push -o allow-secrets=<reason>`, which is audited. A file can opt |
| 21 | out with a `diffinery:allow-secret` comment, for test fixtures. Secrets use |
| 22 | envelope encryption, and every sensitive action goes to an append-only audit log. |
| 23 | |
| 24 | ## Documentation |
| 25 | |
| 26 | The full documentation is public at [diffinery.com/docs](https://diffinery.com/docs): |
| 27 | guides for every feature, plus REST API, CLI and MCP references generated from |
| 28 | this code. For AI agents there's [llms.txt](https://diffinery.com/llms.txt), |
| 29 | [llms-full.txt](https://diffinery.com/llms-full.txt), a Markdown version of |
| 30 | every page (add `.md` to its URL) and an |
| 31 | [OpenAPI document](https://diffinery.com/docs/api/openapi.json). The pages live |
| 32 | in [apps/diffinery/docs](apps/diffinery/docs). |
| 33 | |
| 34 | ## How it fits on Cloudflare |
| 35 | |
| 36 | | Piece | Cloudflare product | |
| 37 | |---|---| |
| 38 | | HTTP, git smart HTTP, REST API, MCP, web UI | Workers (Hono) | |
| 39 | | One repository: refs, objects, PRs, issues, reviews, checks, runs | Durable Object with SQLite (`RepoDO`), one per repository | |
| 40 | | Large objects, Git LFS, container images, logs, caches, artifacts, event archive | R2 | |
| 41 | | Accounts, orgs, tokens, invites, notifications, audit log | D1, read from nearby replicas through the Sessions API (each browser keeps a bookmark so it reads its own writes) | |
| 42 | | Webhooks, notifications, audit fan-out | Queues (with a dead-letter queue) | |
| 43 | | Workflow runs (durable, survive restarts, 6 h job timeout) | Workflows | |
| 44 | | Job runners and agent sandboxes | Containers (Ubuntu 24.04 image in `containers/runner`) | |
| 45 | | Scheduled workflows (`on: schedule`) | Cron Triggers | |
| 46 | | Live run logs and PR updates | Durable Object WebSockets (hibernation) | |
| 47 | | Sign-in | Passkeys (WebAuthn) and sessions in D1. Cloudflare Access guards only `/auth/access`, the email recovery path | |
| 48 | |
| 49 | ``` |
| 50 | apps/diffinery the Worker (src/index.ts), D1 migrations, wrangler config, e2e test |
| 51 | apps/cli the `diffinery` command-line client |
| 52 | containers/runner runner agent + sandbox server, and the container image |
| 53 | packages/git-core git objects, packfiles, deltas, diff/merge (pure TypeScript) |
| 54 | packages/workflow-yaml GitHub Actions workflow parser, expressions, matrix, cron |
| 55 | packages/shared types shared by the Worker and the runner |
| 56 | scripts bootstrap.sh, ensure-secrets.sh, render-config.mjs |
| 57 | ``` |
| 58 | |
| 59 | ## Deploying |
| 60 | |
| 61 | Diffinery deploys itself: this repository lives at |
| 62 | `diffinery.com/codician-team/diffinery`, and every push to `main` there runs |
| 63 | CI (`.github/workflows/ci.yml`: typecheck, unit tests and the Worker bundle) on |
| 64 | Diffinery's hosted runners. When it passes, `.github/workflows/deploy.yml` |
| 65 | deploys that commit, followed by the live test (`.github/workflows/live-test.yml`); |
| 66 | the end-to-end suite (`.github/workflows/e2e.yml`) runs alongside. Deploys |
| 67 | reuse the runner image from Cloudflare's registry and rebuild it only when |
| 68 | `containers/runner` changed, or weekly for base image updates (`scripts/runner-image.sh`). GitHub stays the upstream for |
| 69 | now: `.github/workflows/sync-to-diffinery.yml` copies every branch and tag, and |
| 70 | the secrets and variables below, to Diffinery on each push, then waits for the |
| 71 | Actions runs there and fails if any of them fail. Running Deploy by hand on |
| 72 | GitHub still deploys, as a fallback. |
| 73 | |
| 74 | The workflow needs two repository secrets: |
| 75 | |
| 76 | - `CLOUDFLARE_API_TOKEN`: account permissions Workers Scripts, D1, R2, |
| 77 | Queues, Workflows, Containers, Access: Apps and Policies and Turnstile (all |
| 78 | Edit), and zone permission Workers Routes Edit on `diffinery.com`. |
| 79 | - `CLOUDFLARE_ACCOUNT_ID` |
| 80 | |
| 81 | On each deploy, `scripts/bootstrap.sh` creates anything that is missing: the D1 |
| 82 | database, R2 bucket, queues, the Turnstile widget for anonymous security reports |
| 83 | (`scripts/turnstile.sh`; needs Account → Turnstile → Edit, else it warns) and one |
| 84 | Access application that covers only `/auth/access` (email-based account recovery). |
| 85 | It then applies D1 migrations. `wrangler deploy` builds and pushes the runner image. |
| 86 | `ensure-secrets.sh` generates `MASTER_KEY` and the OIDC signing key inside the job |
| 87 | on the first deploy, and sets `TURNSTILE_SECRET` whenever it is missing; no secret |
| 88 | value is ever printed. |
| 89 | |
| 90 | ### Storage |
| 91 | |
| 92 | Durable and transient data live under separate R2 prefixes, because lifecycle |
| 93 | rules can only select by prefix (`apps/diffinery/src/lib/storage-keys.ts`): |
| 94 | |
| 95 | | Prefix | What | Lifecycle rule | |
| 96 | |---|---|---| |
| 97 | | `repos/` | git objects, LFS objects, release assets | none: kept until the repository is deleted | |
| 98 | | `registry/` | container images | none: unreferenced blobs are swept by the cron job | |
| 99 | | `actions-cache/` | Actions caches | none: Diffinery evicts unused entries after 7 days, and the least recently used above 10 GB per repository | |
| 100 | | `artifacts/` | workflow artifacts | deleted after 90 days (shorter `retention-days` are handled by Diffinery) | |
| 101 | | `logs/` | archived job logs | deleted after 90 days, like GitHub's log retention | |
| 102 | | `actions-staging/` | uploads in progress | deleted after a day | |
| 103 | | `archives/` | zipball and tarball cache | deleted after 30 days (rebuilt when asked for again) | |
| 104 | | `events/` | the event archive | deleted after 400 days | |
| 105 | |
| 106 | Unfinished multipart uploads are aborted after a day everywhere. `bootstrap.sh` |
| 107 | applies these rules on every deploy and stops the deploy if that fails, or if |
| 108 | any rule would still delete objects under `repos/`. Artifacts, caches and logs |
| 109 | written before this layout (under `repos/<id>/...`) are still read from there. |
| 110 | Deleting a repository deletes its objects under the Actions and archive |
| 111 | prefixes. |
| 112 | |
| 113 | If the token can't read your Zero Trust organization, set a repository |
| 114 | **variable** `ACCESS_TEAM_DOMAIN` (for example `codician.cloudflareaccess.com`). |
| 115 | |
| 116 | To run your own Diffinery on another domain, set `DIFFINERY_DOMAIN` (for |
| 117 | example `git.example.com`) when running `scripts/bootstrap.sh`. The Worker's |
| 118 | route, `PUBLIC_URL` and the email sender follow it. Set `DIFFINERY_ZONE` if |
| 119 | the Cloudflare zone isn't the domain's last two labels (for example |
| 120 | `example.co.uk`), and `MAIL_DOMAIN` to send email from another domain. The |
| 121 | token then needs Workers Routes Edit on that zone instead of `diffinery.com`. |
| 122 | |
| 123 | Email recovery uses Access's email one-time PIN, which works without any setup. |
| 124 | You can also add GitHub as a login method under Zero Trust → Settings → Authentication. |
| 125 | |
| 126 | ## Signing in and inviting people |
| 127 | |
| 128 | Everyone signs in with a passkey. There are no passwords. |
| 129 | |
| 130 | 1. **First sign-in for admins.** The emails in `BOOTSTRAP_ADMINS` (in |
| 131 | `apps/diffinery/wrangler.jsonc`) become site admins. Open |
| 132 | `https://diffinery.com/auth/access`, confirm your email with the one-time |
| 133 | code, and add a passkey on the page that follows. |
| 134 | 2. **Inviting someone.** An admin or org owner creates an invite from |
| 135 | *Settings → Site administration*, an organization's *People* tab, or |
| 136 | `diffinery invite friend@example.com --org codician`. Diffinery emails them |
| 137 | the link; they open it, pick a username and create a passkey, and they're in. |
| 138 | 3. **Lost passkey.** A site admin clicks *Sign-in link* next to the person in |
| 139 | *Settings → Site administration*; Diffinery emails them the one-time link, |
| 140 | which works for 24 hours. People can also recover through `/auth/access` by email. |
| 141 | 4. **More devices.** Add passkeys under *Settings → Passkeys and sessions*, or |
| 142 | keep one in a password manager that syncs. The same page signs out other |
| 143 | browsers. |
| 144 | 5. Repository and org roles (read, triage, write, maintain, admin) decide what |
| 145 | each person can do. |
| 146 | |
| 147 | Nobody needs a Cloudflare account. Git and the CLI use a personal token from |
| 148 | *Settings → Access tokens*. |
| 149 | |
| 150 | ```sh |
| 151 | git clone https://diffinery.com/codician/website.git # username: anything, password: your dfy_ token |
| 152 | diffinery login && diffinery auth setup-git # or let the CLI handle credentials |
| 153 | ``` |
| 154 | |
| 155 | |
| 156 | |
| 157 | Diffinery sends email through [Cloudflare Email Sending](https://developers.cloudflare.com/email-service/) |
| 158 | from `notifications@diffinery.com` (`MAIL_FROM` in `wrangler.jsonc`). Every |
| 159 | email has an HTML and a plain-text version, and they work like GitHub's: |
| 160 | |
| 161 | | Group | Emails | Can be turned off | |
| 162 | | --- | --- | --- | |
| 163 | | Security | New sign-in from an unknown browser or device, passkey added or removed, access token created or about to expire, agent added, push protection bypassed or a push blocked | No | |
| 164 | | Account | Invitations, sign-in links, welcome, account disabled or enabled, test email | No | |
| 165 | | Participating | Issues and pull requests you opened, commented on, reviewed, were assigned, asked to review, @mentioned in or subscribed to: new comments, reviews, pushes, merges, closes and reopens | Yes | |
| 166 | | Watching | Everything in repositories you watch with *All activity* | Yes | |
| 167 | | Actions | Failed workflow runs you started (all results if you ask) | Yes | |
| 168 | | Repositories | Repositories created or deleted in your organizations, repository access granted | Yes | |
| 169 | | Organizations | Organization role changes, accepted invitations, access requests (admins) | Yes | |
| 170 | |
| 171 | - **Settings.** *Settings → Notifications* turns each group on or off, on |
| 172 | Diffinery and by email, lists the repositories you watch and sends a test |
| 173 | email. Each repository has a *Watch* menu (participating, all activity, |
| 174 | ignore) and each issue and pull request a *Subscribe / Unsubscribe* button. |
| 175 | Your own comments and changes don't email you unless you ask. |
| 176 | - **Unsubscribing.** Emails carry `List-Unsubscribe` and one-click |
| 177 | unsubscribe headers (RFC 8058), so mail apps show an Unsubscribe button, and |
| 178 | the footer links mute the thread, stop watching the repository or turn off |
| 179 | that group. Links are signed, so they work without signing in. |
| 180 | - **Threading.** Emails about one issue or pull request share |
| 181 | `References`/`In-Reply-To` headers and a `[owner/repo]` subject, and carry |
| 182 | `X-Diffinery-Reason` (like `X-GitHub-Reason`) for filters. |
| 183 | - **Delivery.** Emails go through the `diffinery-mail` queue (retries with |
| 184 | backoff, then the `diffinery-mail-dlq` dead-letter queue) and are logged for |
| 185 | 90 days. Site admins see delivery status, the log and a preview of every |
| 186 | template under *Settings → Email*, and can send every template to |
| 187 | themselves. |
| 188 | - **API.** `GET/PUT/DELETE /api/v3/repos/{owner}/{repo}/subscription`, |
| 189 | `GET/PUT /api/v3/diffinery/notification-settings`, |
| 190 | `GET /api/v3/diffinery/emails`, `POST /api/v3/diffinery/emails/test`; for |
| 191 | site admins `GET /api/v3/diffinery/admin/email` and |
| 192 | `POST /api/v3/diffinery/admin/emails/samples`. |
| 193 | |
| 194 | **Setting it up.** Onboard the sending domain once in the Cloudflare dashboard |
| 195 | (*Compute → Email Service → Email Sending → Onboard Domain*); Cloudflare adds |
| 196 | the bounce MX, SPF, DKIM and DMARC records. Each deploy runs |
| 197 | `scripts/email-sending.sh`, which checks those records (with the *Email |
| 198 | Sending: Read* permission on the API token, or the public DNS records without |
| 199 | it) and warns if mail can't be delivered. In `wrangler dev`, Miniflare accepts |
| 200 | emails without sending them; `GET /api/v3/diffinery/emails` shows the full |
| 201 | message there. |
| 202 | |
| 203 | ## Agents |
| 204 | |
| 205 | Create an agent under *Settings → Agents* or with `diffinery agent create reviewer-bot --org codician`. |
| 206 | Then point any MCP client at it: |
| 207 | |
| 208 | ```json |
| 209 | { "mcpServers": { "diffinery": { "type": "http", "url": "https://diffinery.com/mcp", "headers": { "Authorization": "Bearer dfy_…" } } } } |
| 210 | ``` |
| 211 | |
| 212 | Tools include `get_file`, `list_tree`, `commit_files` (no git client needed), |
| 213 | `create_branch`, `create_pull_request` (with an `intent` for reviewers), |
| 214 | `review_pull_request`, `merge_pull_request` (policy-guarded), |
| 215 | `enable_auto_merge`/`disable_auto_merge`, issues, |
| 216 | `list_workflow_runs` and `get_job_logs`, `rerun_workflow`, releases |
| 217 | (`create_release`, `upload_release_asset`, `generate_release_notes`), |
| 218 | `sandbox_create`/`sandbox_exec` for running builds and tests, and |
| 219 | `start_github_import`/`get_import`/`list_imports` to move repositories in |
| 220 | from GitHub (see below). |
| 221 | |
| 222 | Agent guardrails apply everywhere: git, REST, MCP and the web UI. |
| 223 | |
| 224 | - An agent's role is capped at write, and never exceeds its owner's role. |
| 225 | - Agents can't push to the default branch or protected branches, and can't |
| 226 | merge there. Turn this on per branch with `agentsMayPush` or `agentsMayMerge`, |
| 227 | or let CI decide with `allowAgentAutoMerge` (below). |
| 228 | - A pull request opened by an agent needs at least one human approval, and |
| 229 | approvals from agents don't count toward it. An admin can waive that for |
| 230 | what auto-merge lands on green required checks (`agentAutoMergeWithoutApproval`). |
| 231 | - Agents can't change branch protection or read or set secrets. |
| 232 | - Agents can't change or delete environments or their branch policies, and |
| 233 | can't dismiss reviews. |
| 234 | - Commit statuses and check runs that agents report never satisfy a required |
| 235 | check. |
| 236 | |
| 237 | ### How agents land changes |
| 238 | |
| 239 | Agents never merge into the default branch or a protected branch themselves, |
| 240 | and never get a bypass. Instead, a person who administers the repository turns |
| 241 | on **Allow agents to land pull requests through auto-merge** |
| 242 | (`allowAgentAutoMerge`) on the branch's protection rule, which must also have |
| 243 | at least one required status check. An agent then opens its pull request and |
| 244 | turns on auto-merge (`PUT /repos/{owner}/{repo}/pulls/{n}/auto-merge` or the |
| 245 | MCP tool `enable_auto_merge`). Diffinery merges it, as the agent on behalf of |
| 246 | its owner, as soon as every rule is met: required checks green on the head, |
| 247 | approvals from people of its latest commit (an agent's pull request still |
| 248 | needs one, unless an admin turned on `agentAutoMergeWithoutApproval` for the |
| 249 | branch, which lets green required checks alone land it), linear history and an up-to-date branch where required. On a branch with a merge |
| 250 | queue it joins the queue instead. Without the setting the agent gets a 403, |
| 251 | and without a required check a 422; a pull request that changes a workflow |
| 252 | file needs a person. A push by anyone else turns auto-merge off, the merge |
| 253 | commit carries the `diffinery-agent` header, and the workflows it triggers run |
| 254 | under the agent rules. Workflow tokens are held to the same rule. Enabling, |
| 255 | disabling, the merge and changes to the setting are audited. |
| 256 | |
| 257 | ## Workflows |
| 258 | |
| 259 | Put workflow files in `.github/workflows/` (or `.diffinery/workflows/`). |
| 260 | Supported triggers are `push`, `pull_request`, `pull_request_target`, |
| 261 | `merge_group`, `workflow_dispatch` (with inputs), `schedule` and `workflow_run` |
| 262 | (up to three levels deep, like GitHub), with branch, tag and path filters. |
| 263 | |
| 264 | Pull requests behave as on GitHub: |
| 265 | |
| 266 | - `pull_request` runs check out the test merge commit, `refs/pull/<n>/merge` |
| 267 | (the head merged into the current base), with `GITHUB_REF` set to that ref. |
| 268 | While a pull request conflicts with its base, its `pull_request` workflows |
| 269 | don't run. `refs/pull/<n>/head` and `refs/pull/<n>/merge` can be fetched but |
| 270 | not pushed. |
| 271 | - `pull_request_target` runs the base branch's own workflow on the base commit, |
| 272 | with the repository's secrets, so a pull request can't change what runs. |
| 273 | Check out the pull request's code yourself only if you trust it. |
| 274 | - Both report their checks on the pull request's head commit. `opened`, |
| 275 | `synchronize`, `reopened` and `closed` (with `pull_request.merged`) fire. |
| 276 | - Merge queue: turn on **Require a merge queue** in a branch protection rule |
| 277 | (or `"mergeQueue": {"method": "squash"}` through the API). "Merge when ready" |
| 278 | then adds a pull request to the queue. Each entry gets a merge group branch, |
| 279 | `gh-readonly-queue/<base>/pr-<n>-<head sha>`, holding the base, every pull |
| 280 | request ahead of it and its own changes, and `merge_group` (and `push`) |
| 281 | workflows run on it. Once its required checks pass and the entries ahead have |
| 282 | merged, the base fast-forwards to exactly the tested commit. A group that |
| 283 | fails, conflicts or exceeds the check timeout leaves the queue with a comment |
| 284 | saying why, and the groups behind it are rebuilt. The queue is at |
| 285 | `/<owner>/<repo>/queue/<branch>`; the API is |
| 286 | `PUT`/`DELETE /repos/{owner}/{repo}/pulls/{n}/merge-queue` and |
| 287 | `GET /repos/{owner}/{repo}/merge-queue/{branch}`, `diffinery pr merge` queues |
| 288 | automatically, and the MCP `merge_pull_request` tool does too. |
| 289 | |
| 290 | Supported workflow features: |
| 291 | |
| 292 | - `needs` and job outputs, `if` with `success()`, `failure()`, `always()` and |
| 293 | `cancelled()`, `strategy.matrix` with include and exclude, `fail-fast` and |
| 294 | `max-parallel`, `concurrency` with `cancel-in-progress` (for runs and for |
| 295 | jobs), and `timeout-minutes`. |
| 296 | - A job starts as soon as the jobs it `needs` have finished. It doesn't wait |
| 297 | for unrelated jobs. |
| 298 | - As on GitHub, a job is skipped when a job above it in the `needs` chain |
| 299 | failed, was cancelled or was skipped, unless its `if:` uses `always()`, |
| 300 | `failure()` or `cancelled()`. `!cancelled() && !failure()` runs it after a |
| 301 | skip. `needs.<job>.result` is `skipped` for a skipped job. |
| 302 | - `runs-on`, `name`, `environment`, `timeout-minutes`, `continue-on-error` |
| 303 | and job `concurrency` can use the `matrix` and `strategy` contexts, and are |
| 304 | worked out for each matrix job, e.g. `runs-on: ${{ matrix.os }}`. |
| 305 | - A job-level `concurrency` group lets one job run at a time across the |
| 306 | repository. Others wait as pending; a newer pending job replaces an older |
| 307 | one. |
| 308 | - Job `continue-on-error`: a failed job doesn't fail the run, doesn't cancel |
| 309 | the rest of its matrix, and counts as a success for the jobs that need it. |
| 310 | - `continue-on-error`, `defaults.run`, `env` at every level, `$GITHUB_OUTPUT`, |
| 311 | `$GITHUB_ENV`, `$GITHUB_PATH`, `$GITHUB_STEP_SUMMARY`, and masking of |
| 312 | secrets and `::add-mask::` values. |
| 313 | - `secrets.*`, `vars.*`, and `GITHUB_TOKEN`, a per-job token that follows |
| 314 | GitHub's `permissions:` model: workflow- or job-level `read-all`, |
| 315 | `write-all`, `{}` or per-scope `contents`, `issues`, `pull-requests`, |
| 316 | `statuses`, `checks`, `deployments`, `actions`, `packages`, `pages` and so |
| 317 | on. Without `permissions:` a job gets the repository's default, which is |
| 318 | GitHub's restricted one (`contents` and `packages` read) for new |
| 319 | repositories, and write for ones created before the setting existed. An |
| 320 | admin changes it, and whether |
| 321 | workflows may create and approve pull requests (off by default), with |
| 322 | `PUT /repos/{owner}/{repo}/actions/permissions/workflow` |
| 323 | (`default_workflow_permissions`, `can_approve_pull_request_reviews`). Even |
| 324 | when allowed, a workflow's approval doesn't count toward required approvals. |
| 325 | A reusable workflow never gets more than its caller, and a pull request from |
| 326 | another repository only reads. Each API endpoint needs its scope (an issue |
| 327 | write without `issues: write` is a 403, like GitHub's "Resource not |
| 328 | accessible by integration"). The token never administers the repository, |
| 329 | reads secrets or creates or changes workflow files (GitHub's `workflows` |
| 330 | permission), and branch protection applies to it. A run whose code came from |
| 331 | an agent (the agent pushed it or the branch, or opened the pull request, and |
| 332 | re-runs of such runs) is held to the agent rules: its token can't push or |
| 333 | merge to the default or protected branches. `permissions: id-token: write` |
| 334 | enables OIDC (issuer `https://diffinery.com`). |
| 335 | - `runs-on: ubuntu-latest` (and any `ubuntu-*` or `linux` label) runs in a |
| 336 | Cloudflare Container. `runs-on: [self-hosted, …]` jobs wait for a runner you |
| 337 | start with `diffinery runner -R owner/repo --labels gpu,macos`. Use that for |
| 338 | macOS, GPUs or private networks. |
| 339 | - Reusable workflows: `jobs.<id>.uses: ./.github/workflows/x.yml` from the same |
| 340 | commit, or `owner/repo/.github/workflows/x.yml@ref` from another repository |
| 341 | on this instance (public ones, or private ones with the same |
| 342 | owner). `with`, `secrets` (a mapping or `inherit`), `on.workflow_call` |
| 343 | outputs and nesting up to four levels deep all work. A matrix on the calling |
| 344 | job isn't supported yet. |
| 345 | - Docker, on hosted runners and on self-hosted runners with Docker installed: |
| 346 | a job `container:` (steps and JavaScript actions run inside it), `services:` |
| 347 | (reachable by name from the job container, or on `localhost` through their |
| 348 | mapped ports, with health checks awaited), Docker container actions |
| 349 | (`docker://image` steps and actions with `runs.using: docker`, built from |
| 350 | their Dockerfile), and plain `docker build` / `docker run` / `docker compose` |
| 351 | in steps. Hosted runners start the Docker daemon the first time a job uses |
| 352 | it and pull Docker Hub images through `mirror.gcr.io`. |
| 353 | - A container registry at `diffinery.com` in place of ghcr.io: sign in with |
| 354 | the job's `GITHUB_TOKEN` (`permissions: packages: write`) or a personal |
| 355 | token, then push and pull `diffinery.com/<owner>/<name>`. Images are |
| 356 | private by default and can be linked to a repository. See |
| 357 | [Container registry](https://diffinery.com/docs/packages/container-registry). |
| 358 | - Actions from GitHub run unmodified, including `actions/github-script`, |
| 359 | `setup-java`, `setup-dotnet` and the rest. Jobs get the same runtime |
| 360 | services GitHub provides (`ACTIONS_RUNTIME_TOKEN`, `ACTIONS_RESULTS_URL`, |
| 361 | `ACTIONS_CACHE_URL`), scoped to the job and expiring with it, so |
| 362 | `actions/cache` (v3 and v4), `actions/upload-artifact` and |
| 363 | `actions/download-artifact` (v4: `pattern`, `merge-multiple`, `run-id` with |
| 364 | `github-token`) and `docker/build-push-action` with `cache-to: type=gha` store |
| 365 | caches and artifacts in Diffinery. `GITHUB_EVENT_PATH` holds a complete event |
| 366 | payload and `github.run_id` is numeric. |
| 367 | Caches and artifacts are listed and deleted through the REST API |
| 368 | (`/actions/caches`, `/actions/artifacts`). Each repository keeps up to 10 GB |
| 369 | of caches (the least recently used are evicted) and 10 GB of artifacts |
| 370 | (`ARTIFACT_QUOTA_BYTES` changes it; uploads beyond it are refused). Uploads |
| 371 | in progress count toward both, and a job's unfinished uploads are removed |
| 372 | when it ends. As on GitHub, a cache is saved for the ref the job runs on and |
| 373 | restored from that ref, then the pull request's base branch, then the |
| 374 | default branch, so branches and pull requests never see each other's |
| 375 | caches. Artifacts keep their `retention-days` (1 to 90 days, 90 by default); |
| 376 | an expired artifact's content is deleted, and the REST API still lists it |
| 377 | with `expired: true` (downloads get 410) for another 90 days. |
| 378 | - `actions/checkout`, `cache`, `upload-artifact`, `download-artifact`, |
| 379 | `setup-node`, `setup-python` and `setup-go` run as built-ins for speed. They |
| 380 | share storage and formats with the real actions (a cache saved by one |
| 381 | restores with the other) and support their inputs, including checkout's |
| 382 | `lfs`, `submodules`, `sparse-checkout`, `filter`, `fetch-tags`, `ref` and |
| 383 | `persist-credentials: false`, and the `cache:` input of the setup actions. |
| 384 | A built-in hands over to the real action when it sees an input or ref it |
| 385 | doesn't mirror (a commit SHA, a branch, a newer major). To always run the |
| 386 | real action, set `DIFFINERY_BUILTINS: false` in a workflow, job or step |
| 387 | `env:`, or start a self-hosted runner with `DIFFINERY_DISABLE_BUILTINS=1`. |
| 388 | - Hosted runners look like GitHub's `ubuntu-24.04` image to actions: |
| 389 | `ImageOS=ubuntu24`, `RUNNER_TOOL_CACHE=/opt/hostedtoolcache`, and `git`, |
| 390 | `git-lfs`, `jq`, `zip`, `zstd`, `curl`, `python3`/`pip`, `build-essential`, |
| 391 | `docker` and `gh` installed. `ACTIONS_STEP_DEBUG` and `ACTIONS_RUNNER_DEBUG` |
| 392 | (as secrets or variables) turn on debug logging. |
| 393 | |
| 394 | **Not supported yet:** Windows and macOS hosted runners, the GraphQL API |
| 395 | (`github.graphql` in github-script), and `deepen-not` / partial clone filters |
| 396 | on the server (checkout's `filter` falls back to a full fetch). One cache or |
| 397 | artifact upload request goes through the Worker, so it is limited to the |
| 398 | Worker's request size (100 MB on most plans); the built-ins and the official |
| 399 | actions upload large files in blocks. A job that uses an unsupported feature fails |
| 400 | with a clear message instead of misbehaving. |
| 401 | |
| 402 | ## REST API |
| 403 | |
| 404 | The API lives at `/api/v3`, with the same paths, JSON shapes and errors as |
| 405 | GitHub's REST API. Point a client at it and it works: |
| 406 | |
| 407 | ```js |
| 408 | const octokit = new Octokit({ auth: token, baseUrl: "https://diffinery.example.com/api/v3" }); |
| 409 | ``` |
| 410 | |
| 411 | Responses carry `node_id`, `url`, `html_url`, full user objects and label |
| 412 | objects. Lists take `per_page` and `page` and send a `Link` header, so |
| 413 | `octokit.paginate` works. Errors have `message` and `documentation_url`. |
| 414 | Responses also keep a few Diffinery fields (such as `merge_blockers` on pull |
| 415 | requests) for the CLI, MCP and web UI. |
| 416 | |
| 417 | What works: |
| 418 | |
| 419 | - **Repositories:** get, create, update, delete, topics, languages, |
| 420 | collaborators, branches, tags, readme, contents (GET, and PUT and DELETE |
| 421 | with `sha`; a stale `sha` returns 409), compare, commits, `merges`, |
| 422 | `dispatches`, and `zipball`/`tarball` archives. `private: false` makes a |
| 423 | repository public. |
| 424 | - **Transfers and renames:** `POST /repos/{owner}/{repo}/transfer` moves a |
| 425 | repository to your account or an organization you own or administer (people |
| 426 | only, never agents or `GITHUB_TOKEN`), with its history, issues, pull |
| 427 | requests, runs, secrets and linked container images. Like GitHub, the old |
| 428 | name keeps working for anyone who can read the repository: pages and API |
| 429 | reads answer 301, other API calls 307, and Git, MCP and image names are |
| 430 | served under it, until a repository is created there again. Renamed |
| 431 | repositories and accounts redirect the same way. An organization that still |
| 432 | owns repositories can't be deleted (`DELETE /orgs/{org}`). |
| 433 | - **Archives:** `zipball` and `tarball` are built on demand and cached in R2. |
| 434 | The cache can be evicted at any time; the archive is then built again. An |
| 435 | archive holds at most 24 MB of files and 100,000 tree entries. A zip holds |
| 436 | at most 65,535 files; use the tarball for more. Each repository can build |
| 437 | 20 new archives per hour. Clone bigger repositories with git. |
| 438 | - **Git data:** blobs, trees (with `base_tree` and `recursive`), commits, |
| 439 | annotated tags, `git/ref`, `git/refs` and `git/matching-refs`. |
| 440 | - **Releases:** list, get by id or tag, latest, create (the tag is created |
| 441 | if missing), update, delete, `generate-notes` (honours |
| 442 | `.github/release.yml`), `make_latest`, and drafts (visible to writers only). |
| 443 | Upload assets to the release's `upload_url`. Download them from |
| 444 | `browser_download_url`, or from the asset URL with |
| 445 | `Accept: application/octet-stream`. Bytes live in R2. An asset can be up to |
| 446 | 100 MB, the largest request body Workers accept. |
| 447 | - **Commit statuses:** create, list and the combined status. A status counts |
| 448 | as a check, so a branch protection's required checks can name a status |
| 449 | context. |
| 450 | - **Required checks:** when Diffinery Actions reports a check, it alone |
| 451 | decides that check. To have a required check decided by someone else, bind |
| 452 | it in branch protection, for example |
| 453 | `"requiredCheckSources": { "ci/external": "ci-bot" }`. A required check |
| 454 | fails if any counted report of it fails. Only the reporter that created a |
| 455 | check run can update it, and Actions check runs can't be changed over REST. |
| 456 | - **Checks:** check runs (create, update, get, annotations) and check suites. |
| 457 | - **Issues and pull requests:** labels, assignees, lock and unlock, |
| 458 | comments (by issue and repository-wide), reactions (issues, comments, review |
| 459 | comments and releases), events and the timeline, reviews, review comments |
| 460 | and replies, review dismissal, requested reviewers, `update-branch`, merge, |
| 461 | `commits/{sha}/pulls`, and list filters (`head`, `base`, `sort`, |
| 462 | `direction`, `labels`, `assignee`, `since`). Pull requests report |
| 463 | `mergeable`, `mergeable_state` and `rebaseable`. Comment, review, check |
| 464 | run, user and repository ids are numbers, as on GitHub. Locked |
| 465 | conversations refuse comments, review comments and reactions from people |
| 466 | without triage access. Dismissing a review takes maintain access, and the |
| 467 | pull request's author can't do it. |
| 468 | - **Drafts and merging:** `PATCH /pulls/{n}` with `"draft": false` marks a |
| 469 | draft ready for review (`"draft": true` turns it back; GitHub only offers |
| 470 | this through GraphQL). The web page has a "Ready for review" button and the |
| 471 | CLI has `diffinery pr ready`. A merge commit is refused on a branch that |
| 472 | requires linear history. Admins can merge past unmet branch rules only by |
| 473 | sending `"bypass_rules": true` (the CLI's `pr merge --admin`); the bypass is |
| 474 | written to the audit log. When several rules match a branch, the rule that |
| 475 | names it exactly wins, then the oldest pattern. |
| 476 | - **Who can write:** anonymous callers can read public repositories but can't |
| 477 | create or change anything. A `read`-scoped token only reads; creating |
| 478 | organizations, invitations, agents and tokens takes an `admin`-scoped token |
| 479 | or a browser session. Token scopes must be `read`, `write` or `admin`. |
| 480 | Agents can't add, change or delete secrets or variables, whatever their |
| 481 | role. |
| 482 | - **Archived repositories** are read-only through the API, for everyone. |
| 483 | - **Tree entry names:** every write refuses `.`, `..`, `.git` (in any case, |
| 484 | and spellings like `.git.` or `git~1`), and names with `\` or NUL. |
| 485 | - **Deployments and environments:** deployments, deployment statuses, |
| 486 | environments, deployment branch policies, and environment secrets and |
| 487 | variables. A deployment without `required_contexts` needs every context on |
| 488 | the commit to have passed, as on GitHub; send `[]` to skip that. An |
| 489 | environment with no branch policy gets "protected branches only" when its |
| 490 | first secret is added. Environment secrets never go to `refs/pull/*` runs. |
| 491 | Runs started by agents only get them when the environment allows protected |
| 492 | branches only. Tags pushed by agents never match an environment's tag |
| 493 | patterns. |
| 494 | - **Actions:** runs, run attempts, jobs, logs (a zip per run), artifacts, |
| 495 | workflows, secrets and variables. |
| 496 | - **Search:** `/search/issues` (`repo:`, `is:`, `label:`, `author:`, |
| 497 | `assignee:`, `no:`, `head:`, `base:`, `in:`, date ranges and `sort:`) and |
| 498 | `/search/repositories` (`user:`, `org:`, `topic:`, `is:public`, |
| 499 | `archived:`). Search only covers repositories you can read. A query |
| 500 | can be up to 256 characters, and one search looks at up to 50 repositories. |
| 501 | - `/rate_limit`. Diffinery doesn't rate-limit the API, so it reports a |
| 502 | generous budget. |
| 503 | |
| 504 | Workflows can react to these too. A published release triggers `on: release`, |
| 505 | a `POST /dispatches` triggers `on: repository_dispatch`, and webhooks get |
| 506 | `release`, `status`, `deployment`, `deployment_status` and |
| 507 | `workflow_dispatch` events, and `edited`, `ready_for_review` and |
| 508 | `converted_to_draft` actions on issues and pull requests. A delivery that |
| 509 | fails with a network error, 408, 429 or 5xx is retried up to five times over |
| 510 | about five hours. A job with |
| 511 | `environment:` creates a deployment, gets that environment's secrets and |
| 512 | variables, and is refused if the environment's branch policy doesn't allow |
| 513 | the ref. As on GitHub, events caused by `GITHUB_TOKEN` don't start new |
| 514 | workflow runs, except `repository_dispatch`. |
| 515 | |
| 516 | **Not supported yet:** GraphQL (`/api/graphql`), setting secrets with a |
| 517 | sealed-box `encrypted_value` (send `value` instead), environment protection |
| 518 | rules (required reviewers, wait timers), forks, team reviewers, and code and |
| 519 | commit search. Search qualifiers for stars, forks and languages are accepted |
| 520 | but ignored. |
| 521 | |
| 522 | ## Moving from GitHub |
| 523 | |
| 524 | Diffinery imports a GitHub repository — or a whole organization — on the server: |
| 525 | it copies the Git history in a container and the rest through GitHub's REST API, |
| 526 | so you don't clone or push anything yourself and large repositories don't run |
| 527 | through your laptop. |
| 528 | |
| 529 | Start an import three ways: |
| 530 | |
| 531 | - **Web** — *Settings → Imports → Import from GitHub*, or the *Import a repository* |
| 532 | link on *New repository*. Paste `owner/name` (or a GitHub URL), choose where it lands and |
| 533 | whether it stays public or private, and watch each step. For an organization, |
| 534 | pick the repositories from the list. |
| 535 | - **CLI** — `diffinery migrate github octo/app` imports one repository and |
| 536 | follows it to completion; `diffinery migrate github-org octo --to my-org` |
| 537 | imports an organization. Both take `--json`. `--local` runs the older |
| 538 | client-side path instead (a mirror push plus a best-effort recreation of |
| 539 | issues and open pull requests). |
| 540 | - **MCP / agents** — `start_github_import`, then `get_import` to poll and |
| 541 | `list_imports` to review. An agent can import only where its owner may: the |
| 542 | owner's own account or an organization the owner administers. |
| 543 | |
| 544 | A private repository, Git LFS, Actions variables and branch protection need a |
| 545 | GitHub token (`GH_TOKEN`/`GITHUB_TOKEN`, or the token field in the form) with |
| 546 | `repo` access. For GitHub Enterprise you must name the API base explicitly with |
| 547 | `GITHUB_API_URL` (or the API URL field in the form): when a token is supplied for |
| 548 | a non-github.com source, Diffinery requires a matching `github_api_url` on the |
| 549 | same host and attaches the token only there, so a host taken from the source can |
| 550 | never receive it. Server-side fetches only ever reach that one host, every |
| 551 | response body is size-bounded, redirects are not followed across hosts, and the |
| 552 | token goes to GitHub alone (never logged, never returned). |
| 553 | |
| 554 | **Limits.** Each account (and each organization) may run **one** organization |
| 555 | import and **three** single-repository imports at a time. A repository larger |
| 556 | than `IMPORT_MAX_REPO_KB` (default 10 GB) is refused up front. The Git transfer |
| 557 | has a **6-hour** ceiling; an import that is still transferring after that fails |
| 558 | cleanly. Draft imports left unstarted for seven days are cancelled and their |
| 559 | stored token is erased. |
| 560 | |
| 561 | **Agents.** An agent may import only where its owner may import: the owner's own |
| 562 | account, or an organization the owner owns or administers (an organization's own |
| 563 | agent imports into that organization). The agent's own policy must also allow |
| 564 | **write**, the most an agent holds by default. |
| 565 | Agents never read or set secrets and never manage **variables**: the repository, |
| 566 | organization and environment **variable** steps are skipped for an |
| 567 | agent-started import (and re-checked against a human owner when they do run). An |
| 568 | agent-started import also never bypasses push protection — if the history is not |
| 569 | clean, it stops. |
| 570 | |
| 571 | What comes across, keeping original numbers and attribution: |
| 572 | |
| 573 | - **Git** — every branch and tag, and LFS objects. Pull-request head commits are |
| 574 | kept so merged and open PRs still point at real commits. Merge-queue refs are |
| 575 | skipped. |
| 576 | - **Issues and pull requests** — with their **original numbers** (gaps and all), |
| 577 | bodies, comments, reviews and review threads, labels, milestones, assignees, |
| 578 | merged/closed state and who merged. |
| 579 | - **Labels, milestones, branch protection**, and **Actions variables** (repository |
| 580 | and organization) and **deployment environments** (names, branch policies and |
| 581 | variables). |
| 582 | - **Releases** and their assets. |
| 583 | |
| 584 | What does **not** come across: |
| 585 | |
| 586 | - **Secret values.** GitHub never discloses them, and Diffinery never tries to. |
| 587 | Repository and environment secret **names** are listed so you can re-enter the |
| 588 | values by hand (`diffinery secret set <NAME> -R owner/repo`, or for an |
| 589 | environment `diffinery api PUT /repos/owner/repo/environments/<env>/secrets/<NAME> -f value=...`), |
| 590 | which an admin does — never an agent. |
| 591 | - **People.** No accounts are created. A GitHub user is attributed to a Diffinery |
| 592 | account only through a verified link, matched by GitHub's **numeric id** so a |
| 593 | rename can't mis-map and keyed by the full API base so a github.com link and an |
| 594 | Enterprise link stay separate. Everyone else is imported as a **mannequin**: a |
| 595 | non-account placeholder (`github:<login>`, linking to the GitHub profile) that |
| 596 | carries the history but can't sign in, be assigned work or cast a vote. Where a |
| 597 | mannequin authors a squashed merge, the commit uses GitHub's `noreply` address. |
| 598 | |
| 599 | Link a GitHub account under *Settings → Linked accounts* one of two ways: |
| 600 | |
| 601 | - **Gist proof (no token).** Diffinery shows a one-time code; you put it in a |
| 602 | **public gist** and confirm your login. Diffinery reads your public profile and |
| 603 | gists **unauthenticated** on the API base you named and links the account only |
| 604 | when it finds the code. Nothing but your public data is read. |
| 605 | - **OAuth (optional).** When `GITHUB_OAUTH_CLIENT_ID` and |
| 606 | `GITHUB_OAUTH_CLIENT_SECRET` are configured, *Link with GitHub* → |
| 607 | *Continue to GitHub* runs the OAuth flow with state bound to your account so a |
| 608 | callback can't be replayed. |
| 609 | |
| 610 | A site admin can clear any link (audited). Imported reviews are kept as history |
| 611 | but **never count as approvals**, even when their author is a linked account — a |
| 612 | pull request still needs a fresh review on Diffinery to be approved. |
| 613 | |
| 614 | Old history that contains a credential is imported with an audited push-protection |
| 615 | bypass (the history is already public on GitHub); choose *stop* to fail instead. |
| 616 | |
| 617 | **Retrying.** Only whoever started an import may retry it, and a retry |
| 618 | needs the GitHub token again (it is never stored past the run). While an import |
| 619 | is in progress the target repository is **locked** against other writes, and a |
| 620 | retry refuses to touch a repository that already holds content the import did not |
| 621 | write — it will not adopt or overwrite an existing repository. An agent may not |
| 622 | retry once the repository has been created; a person who administers the target |
| 623 | account takes over that retry instead. |
| 624 | |
| 625 | ## Developing |
| 626 | |
| 627 | ```sh |
| 628 | pnpm install |
| 629 | pnpm -r build && pnpm -r typecheck && pnpm -r test |
| 630 | pnpm --filter @diffinery/app db:migrate:local |
| 631 | pnpm dev # http://localhost:8787, signed in as dev@diffinery.local |
| 632 | pnpm --filter @diffinery/app e2e # wrangler dev + real git + the runner agent + Chromium |
| 633 | ``` |
| 634 | |
| 635 | The end-to-end test does the following: |
| 636 | |
| 637 | 1. Pushes a repository with real `git`. |
| 638 | 2. Runs its CI through the actual runner agent. |
| 639 | 3. Checks secret scanning and branch protection. |
| 640 | 4. Has an agent open a pull request that needs a human approval and a green |
| 641 | check, then merges it. |
| 642 | 5. Runs pull request workflows on test merge commits, `pull_request_target` |
| 643 | from the base branch, and a merge queue with `merge_group` runs, including a |
| 644 | group that fails and leaves the queue. |
| 645 | 6. Clones shallow, then deepens the clone. |
| 646 | 7. Drives the MCP server. |
| 647 | 8. In Chromium with a virtual authenticator, joins from an invite with a new |
| 648 | passkey, adds and removes passkeys, signs out and in, and uses an admin |
| 649 | sign-in link. |
| 650 | 9. Drives the REST API with the real `@octokit/rest` client: contents, git |
| 651 | data, statuses as required checks, releases with asset uploads and |
| 652 | downloads, issues, reactions, pagination, search and deployments. |
| 653 | |
| 654 | Team preferences for product and design decisions are in |
| 655 | [docs/PREFERENCES.md](docs/PREFERENCES.md). |