Skip to content
Source
Sign inSign up

The code forge with agents built in

Work here. GitHub stays in sync.

TanStack Source is a git forge on Cloudflare. Bring your repositories from GitHub and keep both sides in sync. Keep private files next to the code, host your assets with the repository, and let built-in agents review, fix and triage.

Create your account Source vs GitHub 
curl -fsSL https://source.tanstack.com/install | sh

Needs Node.js 22. Then run src auth login.

An example repository on TanStack Source, in sync with GitHub. Its file list shows git files and private vault files together, and its activity shows a synced issue, a review posted to GitHub, an agent review, a warm CI run and an asset.

tanstack / store

In sync with GitHub
  • Code
  • Issues
  • Pull requests
  • CI
  • Assets
  • Factory
  • Settings
  • .sourceci: start the test job warm
  • docsdocs: the batch API
  • internalSharedOnly in the vault: writers
  • srcfix(store): flush batches before notifying listeners
  • .envPersonalOnly you
  • README.mddocs: the batch API
  • package.jsonchore: release 0.8.2

Today

  1. kdomi opened #812 on GitHub

    Came here in seconds

  2. tanner reviewed #7

    Posted to GitHub as tanner

  3. review on #7

    No findings. Stays only here

  4. test passed on #7

    Warm start: the install took 0 s

  5. launch/hero.mp4, version 3

    Served from the repository

Works with what you use now

01 / GitHub sync

Keep GitHub. Sync it both ways.

Import a repository from GitHub with its issues and pull requests, then turn on sync. GitHub stays the public front door. Your team reads, reviews and merges here.

  • New issues, pull requests and comments on GitHub come here in seconds, through a webhook and a catch-up every 5 minutes.
  • On items from GitHub, what a person does here goes to GitHub first, with their own GitHub account: comments, reviews, labels, closes and merges.
  • Agent comments and reviews stay here, with an "Only here" mark. Agents never post on GitHub.
  • Plain git over HTTPS, and a src CLI with the commands of gh.
An example sync log: an issue and commits come from GitHub, a person's review and merge go to GitHub, and an agent's comment stays on Source.
TanStack/storetanstack/store

  1. From GitHub: kdomi opened issue #812

    Webhook, in seconds

  2. From GitHub: 3 commits on main

    Fast-forward only

  3. To GitHub: tanner reviewed #7

    As tanner, with tanner’s GitHub token

  4. To GitHub: tanner merged #7

    On GitHub, with GitHub’s checks

  5. Only here: triage commented on #812

    Only here. Agents never post on GitHub

02 / Private files

Private docs and keys, in the repo, never in git

Keep the runbook, the draft and the .env next to the code. The vault keeps them encrypted at their paths, and src vault pull writes them into any clone.

  • The code view shows vault files next to the files of git, only to the people who may read them.
  • Keep a file for yourself, or share it with a role: readers, writers or admins. Agents never get personal files.
  • Vault files never enter a commit or a clone, so nobody reads them from the git history.
An example file list with vault files next to git files, and the command that writes the vault files into a clone.

Files on main

tanstack/store
  • docs
  • internal Shared
  • internal/runbook.md Shared
  • internal/launch-draft.md Shared
  • .env Personal
  • README.md
src vault pull

03 / Assets

Your images and videos, hosted with the repo

Each repository has an Assets tab for the files of your site, your docs or a launch. They stay out of git, so a clone stays small, and each file gets a URL you can put on a page.

  • Each upload adds a version, and you can make an older version current again.
  • A versioned URL is cached for a year. The plain URL always serves the current version.
  • A private repository can make its assets public and keep its code private.
  • Upload in the browser, with src asset, or through REST and MCP.
An example folder of the Assets tab with three files and their versions, and the current and versioned URL of one file.

assets / launch

Public
  • hero.mp448 MiBv3
  • og.png212 KiBv7
  • logo.svg4 KiBv1
Current
/tanstack/store/assets/launch/og.png
Pinned
/tanstack/store/assets/launch/og.png?v=7 cached for 1 year

04 / Agent factory

Agents on every pull request, built in

The factory audits, reviews and fixes pull requests, fixes failing CI, and triages and reproduces issues. The model and its keys stay on the forge, so agents work on pull requests from forks too.

  • Before you read the diff, each pull request answers four questions: is it safe, is it useful, does it fix its issue, and does it conflict?
  • When CI fails, an agent reproduces the failure, fixes the cause and pushes the fix, never by weakening a test.
  • The factory never approves. Settings, prompts and keys stay with admins, and a pull request cannot change them.
  • The security audit, Architecture and PR impact are on by default. Each other agent is off until an admin turns it on. Use Workers AI, or your own key for Anthropic, OpenAI and 6 other providers.
  • Watch each agent run live, the way you watch a CI log. The Agents tab lists every run, and a failed run says why.
An example Factory panel of a pull request: the answers of its agents, then their runs, newest first.

Factory

Runs

  1. Conflict fixerResolved

    38,400 tokens

  2. ReviewNo findings

    61,900 tokens

  3. Fixes the issueFixes #12

    84,200 tokens

  4. Value checkUseful

    22,700 tokens

  5. AuditClean

    47,300 tokens

05 / Safe CI

CI with no secret inside the job

Jobs run in sandboxed containers. A container reaches only the forge and the https hosts you allow, and the forge adds credentials as requests leave. No token or key is ever inside.

  • A job gets a placeholder for each secret. The forge swaps it only in requests to the hosts of that secret.
  • A pull request from a fork runs after a writer approves it, with the untrusted values of each secret.
  • Hidden checks: tests that only admins can see. An agent cannot tune its code to a test it cannot read.
  • Every job has limits: 50,000 outbound requests, and one hour per check.
Example check runs on a pull request, including a hidden check, and the requests that left the sandbox.
  • testpassed in 2m 14s
  • typecheckpassed in 48s
  • agent-evals (hidden, admins only)passed in 4m 02s

Requests out of the sandbox

  • git fetch from the forge allowed: the job token is added on the way out
  • api.anthropic.com allowed: your API key is added from the vault
  • paste.example.net blocked: not on the allowlist

06 / Fast CI

Jobs start warm, not from zero

On GitHub, each job sets up its tools, restores a cache and installs your packages again. Here, a job with the same lockfile mounts the install of an earlier job, and those steps take 0 s.

  • A job runs on 4 vCPU by default, the same as a GitHub runner.
  • Caches restore in parallel parts, compressed with zstd.
  • Workflows are typed TypeScript. src ci run runs a job on your machine, and src ci convert moves your GitHub Actions workflows.
An example CI job that started warm: its setup and install steps were taken from an earlier job and took 0 seconds.
  • Set up Node (warm start)0 s
  • Install dependencies (warm start)0 s
  • Typecheck48 s
  • Test2m 14s

Log of Install dependencies

Taken from the warm start that a job of commit 4b1e9c2 packed. This step did not run.

Source vs GitHub

Everything you keep from GitHub. And what it can’t do.

Keep your repositories in sync with GitHub, and work here. On GitHub, a coding agent usually works with your keys, so as far as GitHub knows, it is you. Source gives every agent an identity of its own and keeps the decisions with people.

  • Where do private docs and .env files go?

    GitHub: Outside the repository. Every file in git can be read by everyone who reads the repository.

    Source: In the vault, at their paths. The code view shows them only to the people who may read them, and they never enter git.

  • Where do your site’s images and videos go?

    GitHub: In the repository, where each version stays in the git history. Or in a release, or on a host you set up, such as a CDN.

    Source: In the Assets tab, outside git. Each file gets a cached URL and versions you can roll back. A private repository can make its assets public.

  • Whose keys does an agent use?

    GitHub: Yours. It works with your token or SSH key, and its commits look like yours.

    Source: Its own: a session token for one repository that lives 8 hours at most. Every commit names the session and you.

  • What can it do?

    GitHub: Anything your token allows, in every repository it reaches.

    Source: What its profile allows: review, investigate or fix. Never more than you.

  • How does it get a narrow token?

    GitHub: You make a fine-grained token with an end time on a settings page, then paste it to the agent.

    Source: It asks with one command. You check the request and click Create. The token works only on the repositories and actions you allow, and expires.

  • Can it change main?

    GitHub: Yes, if you can, unless a branch rule stops you both.

    Source: No. It pushes to its own branches and opens pull requests. A person merges.

  • Can it approve pull requests?

    GitHub: Yes. With your token, it approves other people’s pull requests in your name.

    Source: No. Reviews and approvals are for people only.

  • What if a stranger posts a prompt injection?

    GitHub: Issues and comments reach your agent as they were written.

    Source: An AI model screens it first. Suspected injections wait for a maintainer, and agents never read them.

  • Where are secrets during checks?

    GitHub: Inside the job. Actions hands them to the runner, where the job’s code can read them.

    Source: Outside. The forge adds credentials as requests leave the sandbox, so none are inside.

  • Can you run CI on your machine?

    GitHub: Not as GitHub runs it. Workflows are YAML, and a local run needs a third-party tool such as act.

    Source: Yes. Workflows are typed TypeScript, and src ci run runs a job locally with the same runner.

  • Does every CI job install the dependencies again?

    GitHub: Yes. Each job starts from a clean runner image, restores its cache and runs the install.

    Source: Not with a warm start. A job with the same lockfile mounts the installed dependencies of an earlier job in seconds, and skips those steps.

  • Where do CI jobs run?

    GitHub: In Azure regions that GitHub picks for its hosted runners. To pick a region, you set up your own runners there.

    Source: In the region where the repository was made, so a team in Europe gets jobs in Europe. Each job reads its checkout and cache from storage in that region.

  • Can it read the tests it must pass?

    GitHub: Yes. Tests and workflows live in the repository it works on.

    Source: Not the hidden checks. Their scripts, logs and artifacts are for admins only.

  • Can it post on your GitHub repository?

    GitHub: Yes. With your token, it comments, closes issues and merges as you.

    Source: No. With GitHub sync on, only what people do goes to GitHub, under their own accounts. Agent comments stay on Source.

  • How do public and private repositories work together?

    GitHub: Separate repositories with one pull request in each, or a private monorepo kept in sync with a copy tool such as Copybara.

    Source: Public and private repositories in one monorepo, with no copy tool. Each member keeps its own history and access, one command clones them all, one monorepo pull request changes several members and merges them with one action, and its CI builds each part with the other members next to it.

  • How do you stop it?

    GitHub: Revoke your token, and every other tool that uses it stops too.

    Source: Revoke the session. It stops at once, even in the middle of a push.

  • Do agents work on pull requests from forks?

    GitHub: Not by default. Actions gives a workflow run from a fork no secrets, so an agent there has no model key.

    Source: Yes. The model and its key stay on the forge, and the sandbox with the fork’s code holds no key.

  • Where is the key for your Linear MCP server?

    GitHub: In the agent’s MCP config on your machine, or in an Actions secret that the job’s code can read.

    Source: Encrypted on the forge. The forge calls the server for the agent, so the sandbox never holds the key. On a stranger’s issue or pull request, agents get only the read-only tools.

  • Who can change the agent’s prompts?

    GitHub: The prompts live in workflow files in the repository, and a pull request from one of its branches runs its own copy of them.

    Source: Admins only. Settings and keys stay on the forge, and custom agents come from the vault or the default branch, never from a pull request.

  • Can you build your own agents?

    GitHub: Yes, as an Actions workflow that runs an agent with your model key in its secrets, next to the code it reads.

    Source: Yes, with TanStack AI: your agent’s code runs in a sandbox, and the forge calls the model with the key, counts the budget and runs its tools.

  • Is a pull request safe, and does it fix its issue?

    GitHub: You find out from the diff, or from a review bot that you set up in Actions.

    Source: The Factory panel answers before you read the diff: an audit, a value check, and the issue’s repro run on the base and on the head.

  • What if a pull request has merge conflicts?

    GitHub: You or the author resolve them, in the web editor or on a computer.

    Source: An agent merges the base into the head with a merge commit, never a force-push, when the author allows edits from maintainers.

  • What if CI fails on a pull request?

    GitHub: You read the log and push a fix, or ask a coding agent that works with your token to do it.

    Source: An agent reproduces the failure in a sandbox, fixes the cause and pushes the fix, never by weakening a test. It never sees the hidden checks.

  • How does a newcomer learn how the repository fits together?

    GitHub: From the code, or from an ARCHITECTURE.md that a person writes and keeps up to date by hand.

    Source: From the Architecture tab: an overview, a card for each package with what it uses and what uses it, and diagrams. An agent updates it after merges that change the architecture.

  • Does a pull request change the architecture or the public API?

    GitHub: You find out from the diff, or ask a coding agent that works with your token to read it.

    Source: The Impact tab says, for each push: before and after diagrams of a major architecture change, and what it adds, removes and changes in the public API.

  • What happens to spam accounts?

    GitHub: You block or report each account by hand, for your account or your organization.

    Source: An agent closes the spam and bans only on hard proof. It suggests the other bans, and an admin bans or dismisses each one. The banned person sees a banner and can appeal on the web.

  • How do people find your library’s skills?

    GitHub: You publish them as a separate step, for example with gh skill publish.

    Source: Put a SKILL.md folder in the repository. Each push to the default branch makes a new version, and the marketplace lists the skills of public repositories.

  • Does a repository show outdated skills?

    GitHub: Not on the repository page. Each person runs gh skill update on their own machine.

    Source: Yes. Its Skills tab marks each outdated copy, shows the changes, and updates it in one commit.

  • Can you share a private skill with one person?

    GitHub: Only by giving them access to the private repository that holds it.

    Source: Yes. A share link reads one skill for 1, 7 or 30 days, and you can revoke it at any time.

The GitHub column describes the usual setup: a coding agent on your machine that works with your personal access token or SSH key, and agents on pull requests that run in GitHub Actions with the repository’s secrets.

Also built in

And everything you expect from a forge

  • Agent sessions

    Each agent gets its own token for one repository, capped at your role, and pushes only to its own branches. Revoke a session, and it stops at once.

  • One agents.md

    Every repository serves the instructions of your account or organization, its AGENTS.md or CLAUDE.md, and its skills, over HTTP and MCP.

  • Screening

    An AI model reads posts from people without write access first. Spam is rejected, and suspected prompt injections wait for a maintainer.

  • Skills

    A SKILL.md folder gets a new version on each push, and public ones list themselves in the marketplace. There is no publish step.

  • Plain git over HTTPS

    Clone, fetch and push with any git client, shallow clones included.

  • Import from GitHub

    Bring your repositories, or a whole GitHub organization that you own, with their issues and pull requests. Any public git URL works too.

  • Pull requests and reviews

    Line comments, pending reviews, approvals, conflict detection, merges, and a diff for thousands of files with renames.

  • Live issues

    Markdown with a preview, new comments the moment they are posted, and assignees who each get a note on what to do.

  • Forks

    A fork stores only its own objects, and pull requests work across repositories.

  • Git LFS

    Files up to 100 MiB each, with download rules for each path.

  • Organizations

    Owners and members, and collaborators with read, write or admin roles.

  • Push protection

    Pushes that add .env files or known secret formats are refused.

Under the hood

One Worker. One Durable Object per repository.

Source runs entirely on Cloudflare. Each repository is a Durable Object that keeps its git objects, issues, pull requests and vault together. A git engine written in TypeScript serves every clone and push.

Workers
The pages, git, the REST API and MCP, in one Worker
Durable Objects
One per repository: its git store, issues, pull requests and vault
D1
Accounts, tokens, and the indexes behind search and dashboards
R2
LFS objects, assets, large vault files, and job logs and artifacts
Queues
Repository events into the indexes, with dead letters replayed
Workflows
Screening, and one durable workflow per job
Workers AI
The model that screens posts from strangers, and the default model of the factory
Containers
The sandboxes that run checks and the tools of the factory’s agents

Bring one repository. Keep GitHub in sync.

Create an account, import a repository from GitHub, turn on sync, and turn on your first agent.

Create your account Explore repositoriesRead the guide