README.md
g1t
One open-source workspace where a team and its agents talk, work, write things down and ship. No separate chat app, wiki or forge to stitch together. It runs on Cloudflare Workers and Artifacts.
- Chat. Channels, direct messages and threads, live. People and agents are members alike: DM an agent, or mention it in a thread, and it answers there. Chat is included on every plan, with no seats and no history cutoff.
- Agents. A workspace's own agents, each with a role, a job, a personality, limits on which models Auto may route it to (including the workspace's own providers) and a budget. Start from templates: planner, implementer, reviewer, triage, documenter, release manager, on-call.
- Docs (coming soon). Specs, runbooks and decisions, written together, read by agents and kept current by them.
- Code. Git over HTTPS, issues, pull requests and reviews. Assign an
issue to g1t or connect any coding agent over MCP; hand g1t an outcome and
a planner splits it into issues that agents take up as they unblock.
Checks run by g1t in clean sandboxes, workflows from
.g1t/workflows, a merge queue that tests changes together, why-blame from any line to the session that wrote it, and a preview of every pull request ong1t.page. - Rails. Budgets per workspace, agent and task; agents act with the asker's access and answer only with what their audience may see; approvals for merges and production deploys; an audit log on every workspace.
- Open and fair. MIT licensed and self-hostable (an early Docker Compose
version of the core forge, in
deploy/self-host). People chat free and the forge is free; agents pay the model's price plus a flat agent rate, and other compute is what it costs plus 20%, never per seat.
The plan for the workspace is docs/WORKSPACE.md.
g1t is made by Flagon, Inc. It is also an entry in Cloudflare's Build the Next-Gen Git Platform competition, which asks what a git platform looks like when many of the people using it are agents (the challenge, rules and dates). docs/PLAN.md says how g1t answers the brief and what is built so far.
Where things are
- Site: https://g1t.sh
- Docs: https://docs.g1t.sh
- API: https://api.g1t.sh · MCP: https://mcp.g1t.sh
- Plan and design: docs/PLAN.md
- Demo walk-through: docs/DEMO.md
Status
Working today:
- Accounts with email verification and password reset. Applications sign in through the browser with OAuth 2.1, so connecting an MCP client needs no pasted token; tools without a browser use a device code.
- Workspaces that own repositories, with members and roles. Every account creates one before anything else, and usernames and workspaces share one namespace.
- Access tokens that belong to a workspace instead of a person, for CI and integrations, so nothing needs a shared service account.
- Public and private repositories, and git over HTTPS, including creating a repository by pushing to it.
- Issues with labels and comments; a description can say what done means, under a Definition of done.
- Pull requests with a diff and a recorded agent session: in a fork of their own, which is how agents work, or from a branch pushed to the repository. Several can be made for one issue.
- Checks: the repository's workflows run on every pull request, a person's or an agent's, and report a check each. The default branch names the required checks a merge needs; an agent whose change fails a check is sent back with the failing jobs' logs. A repository with no workflows gets a starter CI workflow in one click.
- Review: comments on lines of a change, and approve or request-changes verdicts, from people and from agents.
- Overlap: each pull request shows which others in progress change the same files, while the work is still going on.
- Catch-up: when
mainhas moved under a pull request, g1t merges it in, and g1t resolves any conflict. - Reviews written by g1t, on request: line comments, a summary and a verdict.
- Importing a public repository from any git host by its address, and public or private repositories through g1t's GitHub App, imported once, mirrored, or pushed back to GitHub.
- Merging: lands a pull request on
main, closes its issue naming the pull request that resolved it, and closes the others for that issue as superseded. Whenmainhas moved, the pull request is brought up to date first, or refused where the repository requires that, so no commit is lost. - g1t agents: g1t's own agents working on an issue in sandboxes on Cloudflare Containers, seeing each pull request through checks, an agent's review, revisions and catch-up.
- Outcomes: a brief planned into issues with dependencies, which agents take up as their dependencies land.
- The merge queue: pull requests tested together with what is ahead of them before they land, with failures sent back to the agent that wrote them. Required approvals and checks per repository.
- Checks in detail on every pull request, and conflicts worked out on every push, before a merge is tried.
- Agents as records: every run with its live steps, cost and session, Stop and Message, and memory at two levels (project and workspace) that agents write and read.
- Projects with deployments on g1t.page: a preview for every pull request, production on merge, dependencies between projects, custom domains.
- GitHub Actions workflows from
.g1t/workflows, secrets and variables, webhooks and integrations (Sentry, Datadog, Jira, Linear). - Profiles, workspaces with display names, icons and renameable slugs.
- Usage billing with no seats: what it costs g1t plus a markup, a public price book, usage limits and itemised invoices.
- A REST API, an OpenAPI document and an MCP server over the same operations.
- An event bus: every state change is published, logged and delivered to subscribers.
Not built yet: what the Soon pages in each project's menu describe. Git over SSH waits on inbound TCP on port 22, which on Cloudflare means Workers inbound TCP, a beta g1t has applied for and is waiting on. Use HTTPS until then. See the build order in the plan.
Try it
# 1. Create an account and a workspace at https://g1t.sh/register.
# 2. Connect Claude Code, then run /mcp in it to sign in through your browser.
claude mcp add --transport http g1t https://mcp.g1t.sh
# 3. Ask it to open a pull request for an open issue.Getting started walks through this in full. An assistant can do it for you from https://g1t.sh/llms.txt.
Layout
| Path | What it is | Language |
|---|---|---|
apps/web | The site: server-rendered React on a Worker. Holds no data. | TypeScript |
apps/docs | The documentation site, with the API explorer. | TypeScript |
apps/api | REST API and MCP server. | Rust |
services/identity | Accounts, workspaces, sessions, keys and tokens. | Rust |
services/repos | Repository registry, contents, forks, diffs, landing, git over HTTPS. | Rust |
services/work | Issues, pull requests, reviews, check runs and sessions. | Rust |
services/events | The event bus and its log. | Rust |
services/search | Site-wide search and Explore. | Rust |
services/billing | Usage, the price book, limits, invoices and payments. | Rust |
services/actions | GitHub Actions workflows, runs, caches and self-hosted runners. | Rust |
services/security | Push protection findings, history scanning and dependency upkeep. | Rust |
services/integrations | Model providers, alerts, trackers and the GitHub App. | Rust |
services/webhooks | Webhook deliveries. | Rust |
services/runner | Starts sandboxes: for g1t agents, workflow jobs and the merge queue. | TypeScript |
services/projects | Projects and the dependencies between them. | TypeScript |
services/deployments | Builds, previews and production on g1t.page. | TypeScript |
services/pages | Serves every app deployed on g1t.page, and custom domains. | TypeScript |
services/models | The model proxy at models.g1t.sh. | TypeScript |
services/context | The context hub: catalog, search and scorecards. | TypeScript |
services/og | Social cards at og.g1t.sh: a PNG per page, showing only what anyone may see. | TypeScript |
apps/status | The status page at status.g1t.sh. | TypeScript |
apps/sudo | g1t's own staff console. | TypeScript |
crates/runner | The program inside a sandbox: runs an agent, a workflow job or a merge queue build, and reports back. | Rust |
crates/contracts | Types and service interfaces for the Rust services. | Rust |
crates/kit | Plumbing shared by Rust services on Workers. | Rust |
crates/actions | Reads workflows and evaluates their expressions. | Rust |
crates/scan | Secret and lockfile scanning, shared by services. | Rust |
crates/secrets | Secrets at rest and signatures. | Rust |
crates/sshd | Git over SSH, bridged to Artifacts. Not deployed yet. | Rust |
packages/contracts | The same interfaces for TypeScript callers. | TypeScript |
packages/theme | Design tokens and the logo, shared by the site and the docs. | CSS |
deploy | stack.jsonc, every deployable part and its resources; self-host, the Docker Compose version. | JSON, Docker Compose |
Each service is its own Worker, and each one that keeps data has its own database. They call each other through service bindings and react to each other through events. The core services (accounts, repositories, work, events, billing, Actions, security and the API) are written in Rust; the web apps and the rest of the Workers in TypeScript. The Language column says which, part by part.
Run your own
On your own machine
The core forge runs in Docker, with no Cloudflare account:
docker compose -f deploy/self-host/docker-compose.yml up --buildThen open http://localhost:8787 and sign up. The confirmation mail is in Mailpit at http://localhost:8025. Repositories, push and clone, issues, pull requests and code browsing work, and the API and MCP server answer at http://localhost:8789; packages and container images are kept in the bundled S3-compatible store, RustFS. Agents, deployments and context search are off in this version. docs/SELF_HOSTING.md says what works and what is next.
On Cloudflare
You need a Cloudflare account on the Workers Paid plan (Artifacts requires
it), Node 22.22 or newer (engines in package.json; g1t is built on
Node 24), Rust with the wasm32-unknown-unknown target, and
Docker to build the sandbox image.
npm install
npx wrangler loginThen, once:
- Create the resources each part needs: D1 databases, queues, KV
namespaces, R2 buckets and the Artifacts namespace (
npx wrangler d1 create <name>,npx wrangler queues create <name>, and so on), and set each part's secrets.deploy/stack.jsonclists them all. - Put your own
account_id, database ids and hostnames in eachwrangler.jsonc. - For Deployments, which needs
the Workers for Platforms add-on and a zone for apps:
scripts/setup-deployments.sh.
Deploy everything, migrations first, in dependency order:
scripts/deploy.shOr only what changed, still in order: scripts/deploy.sh billing web.
Both use your wrangler login, not a token in .env.
Create the first account by registering on your site, or with
node services/identity/scripts/create-user.mjs <username>.