| 1 | --- |
| 2 | title: What g1t can't do yet |
| 3 | description: The limits you can hit on g1t today, why each one exists, what to do instead, and whether it is planned. |
| 4 | --- |
| 5 | |
| 6 | This page lists what g1t cannot do today. Each entry says what you can't |
| 7 | do, why, what to do instead, and where it stands. |
| 8 | |
| 9 | Where it stands is one of: |
| 10 | |
| 11 | - **Planned**: we intend to build it. We don't give dates we can't keep. |
| 12 | - **Depends on Cloudflare**: g1t runs on Cloudflare, and this needs |
| 13 | something the platform does not offer yet. |
| 14 | - **Not scheduled**: no work is planned on it now. |
| 15 | |
| 16 | Several of these depend on Cloudflare; [we wrote to them about it](/about/open-letter-to-cloudflare/). |
| 17 | |
| 18 | If you hit a limit that is not here, tell us at |
| 19 | [g1t.sh/support](https://g1t.sh/support), and we will add it. |
| 20 | |
| 21 | ## Git |
| 22 | |
| 23 | ### No git over SSH |
| 24 | |
| 25 | You can reach repositories only over HTTPS. A `git@g1t.sh:…` remote does |
| 26 | not work. |
| 27 | |
| 28 | - **Why.** SSH needs inbound TCP connections on port 22. g1t runs on |
| 29 | Cloudflare Workers, which accept HTTP, not raw TCP. Cloudflare has a beta |
| 30 | for inbound TCP; we have applied and are waiting. |
| 31 | - **Instead.** Use the HTTPS remote with an |
| 32 | [access token](/guides/git/#authentication). It does everything SSH would: |
| 33 | clone, fetch and push. SSH keys you add under **Settings → SSH keys** are |
| 34 | kept for when SSH arrives. |
| 35 | - **Status.** Depends on Cloudflare. See [Git](/guides/git/#ssh). |
| 36 | |
| 37 | ### Repositories up to 1 GB, files up to 32 MB, no LFS |
| 38 | |
| 39 | A repository can hold up to 1 GB and a single file up to 32 MB. Git LFS is |
| 40 | not supported. A push that would cross either is declined before it is |
| 41 | stored, and git prints why. See [Size limits](/guides/git/#size-limits). |
| 42 | |
| 43 | - **Why.** These are the limits of Cloudflare Artifacts, where every |
| 44 | repository is stored. |
| 45 | - **Instead.** Keep large binaries out of the repository: in a release |
| 46 | bucket, a package registry or object storage, fetched at build time. |
| 47 | - **Status.** Large file storage is planned. Raising the limits themselves |
| 48 | depends on Cloudflare. |
| 49 | |
| 50 | ### Pushes up to 100 MB each |
| 51 | |
| 52 | A single push can carry up to 100 MB. A larger one is refused with HTTP |
| 53 | `413` before g1t sees it. |
| 54 | |
| 55 | - **Why.** Cloudflare's network limits the size of one request body on the |
| 56 | plan g1t.sh is on. |
| 57 | - **Instead.** Push history in steps, oldest first: |
| 58 | `git push origin <older-commit>:refs/heads/main`, then a newer one, then |
| 59 | `main`. Each push sends only what the last did not. |
| 60 | - **Status.** Depends on Cloudflare. |
| 61 | |
| 62 | ### Imports and mirrors up to 40 MB |
| 63 | |
| 64 | Importing or mirroring a repository copies it in one piece of at most |
| 65 | 40 MB, after compression. |
| 66 | |
| 67 | - **Why.** The copy is held in memory while it moves, and a Worker has |
| 68 | 128 MB for everything it is doing at once. |
| 69 | - **Instead.** Clone the repository yourself and push it to g1t, in steps if |
| 70 | it is over 100 MB. See [Import, mirror or move a repository](/guides/github/#what-comes-across). |
| 71 | - **Status.** Streaming the copy, so size stops mattering, is planned. |
| 72 | |
| 73 | ### Partial clone works, but is not promised |
| 74 | |
| 75 | `git clone --filter=blob:none` returns a real partial clone today. We don't |
| 76 | promise it will keep doing so. |
| 77 | |
| 78 | - **Why.** Cloudflare's documentation says filters are not supported, but |
| 79 | they work with git's protocol version 2. We have asked whether that is |
| 80 | intended. |
| 81 | - **Instead.** Use it, and fall back to `--depth=1` for a shallow clone, |
| 82 | which is supported. |
| 83 | - **Status.** Depends on Cloudflare. |
| 84 | |
| 85 | ### No server-side hooks of your own |
| 86 | |
| 87 | You can't run a script of your own on g1t when a push arrives, before or |
| 88 | after its refs move. |
| 89 | |
| 90 | - **Why.** The git store has no hook for this. g1t's own checks run in front |
| 91 | of it, in g1t's code: [protected branches](/guides/git/#protected-branches) |
| 92 | and [push protection](/guides/security/#push-protection). |
| 93 | - **Instead.** Protect the default branch and make your workflows |
| 94 | [required checks](/guides/pull-requests/#required-status-checks). To react |
| 95 | after a push, use a [webhook](/guides/webhooks/) or a workflow on `push`. |
| 96 | - **Status.** Not scheduled for your own scripts. A hook in the store, |
| 97 | which would let g1t enforce more before refs move, depends on Cloudflare. |
| 98 | |
| 99 | ### Very large pushes are scanned after they land, not before |
| 100 | |
| 101 | A very large push is too large for push protection to read before it is |
| 102 | stored, so it is let through, and g1t scans every commit it added |
| 103 | afterwards, in the background. A secret found that way is an open alert |
| 104 | rather than a refused push, and the workspace's owners are emailed when one |
| 105 | looks real. Most pushes are scanned before they land. |
| 106 | |
| 107 | - **Why.** Scanning reads the whole push inside a Worker, which has 128 MB |
| 108 | for everything it is doing at once. Past a certain size, scanning could fail |
| 109 | the push outright, and refusing such pushes would block importing real |
| 110 | repositories. |
| 111 | - **Instead.** To have a large history checked before it lands, push it in |
| 112 | steps (see above), so each push is scanned first. Secrets already in |
| 113 | history are listed under |
| 114 | [Secrets in history](/guides/security/#secrets-in-history). |
| 115 | - **Status.** Planned: scanning while the push streams, at any size. |
| 116 | |
| 117 | ### Deleting history does not free storage |
| 118 | |
| 119 | Storage is counted from what is pushed, and the count only grows. Deleting |
| 120 | a branch, or force-pushing over commits, does not lower it. |
| 121 | |
| 122 | - **Why.** The git store does not say whether or when it reclaims space |
| 123 | from objects nothing points to any more, or report how much a repository |
| 124 | holds. So g1t cannot see it either. |
| 125 | - **Instead.** Keep large mistakes out with a `.gitignore`. If one landed in |
| 126 | a private repository and counts against you, tell us at |
| 127 | [g1t.sh/support](https://g1t.sh/support). |
| 128 | - **Status.** Depends on Cloudflare. See |
| 129 | [private repository storage](/guides/usage-and-billing/#private-repository-storage). |
| 130 | |
| 131 | ## Pull requests and forks |
| 132 | |
| 133 | ### Forks are only for pull requests |
| 134 | |
| 135 | You can't fork a repository into your own workspace. On g1t, a fork is a |
| 136 | pull request's own working copy, made when the pull request is opened. |
| 137 | |
| 138 | - **Why.** We built forks to isolate agents' work, one per pull request. |
| 139 | See [Forks and branches](/concepts/forks/). |
| 140 | - **Instead.** To contribute, open a pull request: it gets its own fork. To |
| 141 | start a copy of your own, clone the repository and push it to a new one |
| 142 | in your workspace; pushing creates it. |
| 143 | - **Status.** Not scheduled. |
| 144 | |
| 145 | ### Pull request forks are removed a day after they close |
| 146 | |
| 147 | A day after a pull request merges or closes, its fork's git data is |
| 148 | removed. The pull request's changes stay readable: its head is kept in the |
| 149 | repository as `refs/pull/<pull request id>/head`. Pushing to the fork, or |
| 150 | reopening the pull request, makes the fork again from there. |
| 151 | |
| 152 | - **Why.** Cloudflare has not documented whether a fork shares stored |
| 153 | objects with its source or copies them, so forks are not kept longer |
| 154 | than they are useful. |
| 155 | - **Instead.** Nothing you need to do. To keep working on a closed pull |
| 156 | request's change, fetch `refs/pull/<pull request id>/head` and push it |
| 157 | to a branch. |
| 158 | - **Status.** Clear fork storage rules depend on Cloudflare. |
| 159 | |
| 160 | ### Some dependency update options are not applied yet |
| 161 | |
| 162 | g1t reads and checks every option of a `dependabot.yml` file, but does not |
| 163 | act on all of them yet: |
| 164 | |
| 165 | - Version update pull requests are opened for npm, Cargo, Go and pip only. |
| 166 | Entries for other ecosystems are checked and listed, and open nothing. |
| 167 | |
| 168 | - A multi-ecosystem group opens one pull request per ecosystem, not one |
| 169 | for the group. |
| 170 | - Registries that sign in with OIDC are not used. |
| 171 | |
| 172 | - **Instead.** Keep a separate entry per ecosystem and directory, and |
| 173 | check the Security page, which lists what each entry reads but does not |
| 174 | act on. See [Dependency updates](/guides/dependency-updates/#options). |
| 175 | - **Status.** Planned. |
| 176 | |
| 177 | ### No conflict resolution in the browser |
| 178 | |
| 179 | You can't resolve a merge conflict on the pull request's page. |
| 180 | |
| 181 | - **Instead.** Ask g1t to resolve it, or fix it on the command line. |
| 182 | See [Conflicts](/guides/pull-requests/#conflicts). |
| 183 | - **Status.** Planned. |
| 184 | |
| 185 | ## Actions and runners |
| 186 | |
| 187 | ### No Docker in g1t's sandboxes |
| 188 | |
| 189 | On g1t's own machines, a job's `container:` image is not used (its steps |
| 190 | run on g1t's runner image instead), and a step cannot run `docker build`. |
| 191 | Docker container actions (`uses: docker://…`, or an action that runs as a |
| 192 | Docker image) and `services:` containers, such as a database, do not run |
| 193 | on any runner yet, self-hosted ones included. |
| 194 | |
| 195 | - **Why.** Jobs run in Cloudflare Containers, which offer no supported way |
| 196 | to run Docker or another image builder inside a container. |
| 197 | - **Instead.** Run `container:` jobs and image builds on a |
| 198 | [self-hosted runner](/guides/self-hosted-runners/). A runner in Docker |
| 199 | mode runs each job in its `container:` image. To build images, register a |
| 200 | runner with `--no-docker` on a machine that has Docker, and its steps can |
| 201 | call `docker build` and `docker push`. Self-hosted time costs nothing. For |
| 202 | a database, start it from a `run:` step on a self-hosted runner. |
| 203 | - **Status.** Docker container actions and `services:` are planned. Image |
| 204 | builds on g1t's machines depend on Cloudflare. |
| 205 | |
| 206 | ### Linux only on g1t's machines |
| 207 | |
| 208 | A job with `runs-on: windows-latest` or `macos-latest` fails on g1t's own |
| 209 | machines. |
| 210 | |
| 211 | - **Instead.** [Self-hosted runners](/guides/self-hosted-runners/) run Linux, |
| 212 | macOS and Windows, on x64 and arm64. |
| 213 | - **Status.** Not scheduled. |
| 214 | |
| 215 | ### Machine sizes, time and storage |
| 216 | |
| 217 | | Limit | Value | |
| 218 | | --- | --- | |
| 219 | | Largest machine | 4 vCPUs, 12 GiB of memory, 20 GB of disk (`g1t-4core`). No GPUs. | |
| 220 | | One job on g1t's machines | 60 minutes. On a self-hosted runner, 24 hours. | |
| 221 | | One cache entry | 2 GiB, compressed. A larger one is not saved. | |
| 222 | | A repository's caches | 10 GiB together. Past it, the entries restored longest ago are removed. | |
| 223 | | One artifact | 60 MB, kept for 14 days | |
| 224 | |
| 225 | The machine sizes are Cloudflare Containers' instance sizes. For more, use a |
| 226 | [self-hosted runner](/guides/self-hosted-runners/). See |
| 227 | [Machine sizes](/guides/actions/#machine-sizes) and [the cache](/guides/actions/#the-cache). |
| 228 | |
| 229 | ### Workflow features not supported yet |
| 230 | |
| 231 | - Reusable workflows from another repository. Ones in the same repository |
| 232 | work. |
| 233 | - Actions that cache through the hosted toolkit's own cache service, such as |
| 234 | `setup-node` with `cache: npm`. They run without it; use `actions/cache`. |
| 235 | - Environments' protection rules: required reviewers, wait timers and branch |
| 236 | limits. A job with `environment:` gets that environment's values and runs |
| 237 | without waiting. |
| 238 | |
| 239 | See [Not yet](/guides/actions/#not-yet). **Status.** Planned. |
| 240 | |
| 241 | ## Deployments |
| 242 | |
| 243 | ### Static sites and Workers only |
| 244 | |
| 245 | Deployments run static sites and Workers projects. You can't deploy a |
| 246 | long-running server, a container, or an app that needs a process that stays |
| 247 | up. |
| 248 | |
| 249 | - **Why.** Apps run on Cloudflare Workers, which run only while they answer a |
| 250 | request. That is why an app nobody visits costs nothing. |
| 251 | - **Instead.** Deploy the server from a workflow to wherever it runs today, |
| 252 | with its credentials in [secrets](/guides/secrets-and-variables/). |
| 253 | - **Status.** A runtime for servers is planned. |
| 254 | |
| 255 | ### Some Workers bindings are not provisioned |
| 256 | |
| 257 | A Workers project deploys without D1, KV, R2, Durable Objects, Queues, |
| 258 | service bindings, Vectorize, Hyperdrive, Workers AI or Workflows, and its |
| 259 | cron triggers are not scheduled. |
| 260 | |
| 261 | - **Why.** Each of these is a resource g1t has to create and bill per |
| 262 | project, and that is not built yet. |
| 263 | - **Instead.** Check that a binding exists before using it. The deployment |
| 264 | lists each binding it left out, and warns when its cron triggers will |
| 265 | not run. |
| 266 | - **Status.** Planned. See [Workers projects](/guides/deployments/#workers-projects). |
| 267 | |
| 268 | ### Build and size limits |
| 269 | |
| 270 | A build stops after 45 minutes. A static site can have up to 20,000 files |
| 271 | and 25 MiB per file, which are Cloudflare's limits. See |
| 272 | [Static sites](/guides/deployments/#static-sites). |
| 273 | |
| 274 | ## Data residency |
| 275 | |
| 276 | You can't choose where a workspace's data is stored. g1t's databases keep |
| 277 | their primary copy in the United States, with read copies in other regions |
| 278 | so pages load fast. Repositories are not pinned to a region. |
| 279 | |
| 280 | - **Why.** Cloudflare fixes the region of a repository store when it is |
| 281 | created, and g1t has one store so far. |
| 282 | - **Instead.** None today, if your data must stay in the EU. |
| 283 | - **Status.** EU residency, with an EU-only repository store and databases, |
| 284 | is planned. |
| 285 | |
| 286 | ## Billing |
| 287 | |
| 288 | ### Some costs are not fully defined yet |
| 289 | |
| 290 | Cloudflare starts billing for Artifacts, where repositories are stored, on |
| 291 | October 14, 2026, and has not yet said exactly which calls count as a |
| 292 | billable operation. |
| 293 | |
| 294 | - **What g1t does.** It counts every clone, fetch and push through its git |
| 295 | endpoints. Each day it checks what Cloudflare billed it for containers and |
| 296 | apps against what was used. When a cost moves, |
| 297 | g1t's price moves with it, and every change is listed with its reason on |
| 298 | [g1t.sh/pricing](https://g1t.sh/pricing). |
| 299 | - **What this means for you.** Prices can change while Cloudflare's beta |
| 300 | products settle. They follow cost. |
| 301 | See [How prices are set](/guides/usage-and-billing/#how-prices-are-set) |
| 302 | and [git operations](/guides/usage-and-billing/#git-operations). |
| 303 | - **Status.** Depends on Cloudflare. |
| 304 | |
| 305 | ### Payments are in test mode |
| 306 | |
| 307 | While payments are in test mode, no real card is charged, so a card check |
| 308 | proves nothing. g1t's hosted models are open only to a few invited |
| 309 | workspaces, g1t's own among them. Every other workspace, trial or not, |
| 310 | runs its agents on its own model provider; without one, assigning an agent |
| 311 | is refused with a message that says so. |
| 312 | |
| 313 | - **Instead.** Connect your own [model provider](/guides/models/). Your |
| 314 | agents then run on your keys, and the provider bills you directly. |
| 315 | - **Status.** Planned: hosted models for every workspace once payments go |
| 316 | live. |
| 317 | |
| 318 | ## Agents |
| 319 | |
| 320 | ### Confidence is a judgement, not a guarantee |
| 321 | |
| 322 | The confidence g1t gives an agent's change, high, medium or low, is |
| 323 | worked out from what g1t can observe: checks, reviews, revisions, the size |
| 324 | and reach of the change. It cannot tell whether the change is correct. |
| 325 | |
| 326 | - **Instead.** Keep **Ask a person before merging low-confidence changes** |
| 327 | on, and make your workflows required checks. A high rating on a |
| 328 | repository with weak tests means less. See |
| 329 | [How sure the agent is](/guides/working-with-g1t/#how-sure-the-agent-is). |
| 330 | - **Status.** The signals and their weights may change as we learn from |
| 331 | real changes. |
| 332 | |
| 333 | ### Agents' model calls go through g1t |
| 334 | |
| 335 | An agent's model requests always pass through g1t's model proxy, |
| 336 | `models.g1t.sh`, with your keys or g1t's. You can't point an agent's sandbox |
| 337 | straight at a provider. |
| 338 | |
| 339 | - **Why.** So that no key is ever inside a sandbox, and so budgets, caps and |
| 340 | the audit log hold. See [Your keys never reach a sandbox](/guides/models/#your-keys-never-reach-a-sandbox). |
| 341 | - **Status.** Not planned. This is by design. |
| 342 | |
| 343 | ## Accounts, status and self-hosting |
| 344 | |
| 345 | ### Sign-up needs an invite |
| 346 | |
| 347 | g1t is invite-only for now. See [Invites](/guides/authentication/#invites). |
| 348 | **Status.** Opening sign-up is planned. |
| 349 | |
| 350 | ### No uptime commitment during the beta |
| 351 | |
| 352 | g1t does not promise a particular uptime or offer a service level agreement |
| 353 | unless you have a written agreement with us. Several of the Cloudflare |
| 354 | products g1t is built on are in beta and have none either. |
| 355 | [status.g1t.sh](https://status.g1t.sh/) shows how each part of g1t is doing, |
| 356 | and every incident. Sandboxes are not checked there yet. See |
| 357 | [Status and incidents](/guides/status/). **Status.** Not scheduled during |
| 358 | the beta. |
| 359 | |
| 360 | ### Self-hosting is early |
| 361 | |
| 362 | [Running g1t yourself](/guides/self-hosting/) gives you the core forge: |
| 363 | accounts, repositories over HTTP, issues and pull requests. g1t's agent, |
| 364 | Actions, deployments, git over SSH, the REST API and MCP are off, and it is |
| 365 | not ready for the open internet. **Status.** Planned, in phases. |
| 366 | |
| 367 | ### Not built yet |
| 368 | |
| 369 | |
| 370 | - **Releases and package registries.** Planned. |
| 371 | - **Wikis.** Not scheduled. Keep docs in the repository. |