| 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 up to 40 MB |
| 63 | |
| 64 | Importing a repository copies it in one piece of at most 40 MB, after |
| 65 | 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 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 each pull request's work, so many |
| 139 | people and agents can work at once. |
| 140 | See [Forks and branches](/concepts/forks/). |
| 141 | - **Instead.** To contribute, open a pull request: it gets its own fork. To |
| 142 | start a copy of your own, clone the repository and push it to a new one |
| 143 | in your workspace; pushing creates it. |
| 144 | - **Status.** Not scheduled. |
| 145 | |
| 146 | ### Pull request forks are removed a day after they close |
| 147 | |
| 148 | A day after a pull request merges or closes, its fork's git data is |
| 149 | removed. The pull request's changes stay readable: its head is kept in the |
| 150 | repository as `refs/pull/<pull request id>/head`. Pushing to the fork, or |
| 151 | reopening the pull request, makes the fork again from there. |
| 152 | |
| 153 | - **Why.** Cloudflare has not documented whether a fork shares stored |
| 154 | objects with its source or copies them, so forks are not kept longer |
| 155 | than they are useful. |
| 156 | - **Instead.** Nothing you need to do. To keep working on a closed pull |
| 157 | request's change, fetch `refs/pull/<pull request id>/head` and push it |
| 158 | to a branch. |
| 159 | - **Status.** Clear fork storage rules depend on Cloudflare. |
| 160 | |
| 161 | ### Some dependency update options are not applied yet |
| 162 | |
| 163 | g1t reads and checks every option of a `dependabot.yml` file, but does not |
| 164 | act on all of them yet: |
| 165 | |
| 166 | - Version update pull requests are opened for npm, Cargo, Go and pip only. |
| 167 | Entries for other ecosystems are checked and listed, and open nothing. |
| 168 | |
| 169 | - A multi-ecosystem group opens one pull request per ecosystem, not one |
| 170 | for the group. |
| 171 | - Registries that sign in with OIDC are not used. |
| 172 | |
| 173 | - **Instead.** Keep a separate entry per ecosystem and directory, and |
| 174 | check the Security page, which lists what each entry reads but does not |
| 175 | act on. See [Dependency updates](/guides/dependency-updates/#options). |
| 176 | - **Status.** Planned. |
| 177 | |
| 178 | ### Very large changes are shown in parts |
| 179 | |
| 180 | A pull request, commit or comparison lists at most 300 changed files. Of |
| 181 | those, lines are read for the first ones until about 20,000 lines; the |
| 182 | rest are listed without their counts and load one batch at a time as you |
| 183 | scroll to them. A single file over 512 KB is not shown at all, and one |
| 184 | with a diff over 1,000 lines waits for **Load diff**. |
| 185 | |
| 186 | - **Instead.** For a change of more than 300 files, compare the commits |
| 187 | with git (`git diff --stat base...head`). From the API, ask for the files |
| 188 | a large answer left out by `paths`. |
| 189 | See [Files changed](/guides/pull-requests/#files-changed). |
| 190 | - **Status.** Not planned to change. |
| 191 | |
| 192 | ### No conflict resolution in the browser |
| 193 | |
| 194 | You can't resolve a merge conflict on the pull request's page. |
| 195 | |
| 196 | - **Instead.** Fix it on the command line. |
| 197 | See [Conflicts](/guides/pull-requests/#conflicts). |
| 198 | - **Status.** Planned. |
| 199 | |
| 200 | ## Actions and runners |
| 201 | |
| 202 | ### Docker shares the job's network |
| 203 | |
| 204 | A job's Docker Engine runs its containers on the job's own network, not on |
| 205 | networks of their own. A service is reached at `localhost` and by its |
| 206 | name, as on GitHub, but two containers cannot listen on the same port, and |
| 207 | `docker network create` gives no separation between containers. |
| 208 | |
| 209 | - **Why.** Jobs run in Cloudflare Containers, which let a container run |
| 210 | Docker but not route a container network of its own out, or change its |
| 211 | packet filter. |
| 212 | - **Instead.** Give containers that would clash different ports. |
| 213 | - **Status.** Not scheduled. |
| 214 | |
| 215 | ### No `type=gha` build cache |
| 216 | |
| 217 | Buildx's GitHub Actions cache backend (`cache-to: type=gha`) is skipped on |
| 218 | g1t, and the build runs without a cache. |
| 219 | |
| 220 | - **Why.** It talks to GitHub's cache service, which g1t's cache does not |
| 221 | speak yet. |
| 222 | - **Instead.** Use a registry cache in g1t's container registry |
| 223 | (`type=registry`), or `type=local` with `actions/cache`. See |
| 224 | [caching image builds](/guides/actions/#caching-image-builds). |
| 225 | - **Status.** Planned. |
| 226 | |
| 227 | ### No multi-platform image builds on g1t's machines |
| 228 | |
| 229 | Building an image for another platform, such as `linux/arm64`, needs QEMU's |
| 230 | emulators, which g1t's machines do not have set up. |
| 231 | |
| 232 | - **Instead.** Build other platforms on a |
| 233 | [self-hosted runner](/guides/self-hosted-runners/) of that architecture, |
| 234 | or one with QEMU set up. |
| 235 | - **Status.** Planned. |
| 236 | |
| 237 | ### Linux only on g1t's machines |
| 238 | |
| 239 | A job with `runs-on: windows-latest` or `macos-latest` fails on g1t's own |
| 240 | machines. |
| 241 | |
| 242 | - **Instead.** [Self-hosted runners](/guides/self-hosted-runners/) run Linux, |
| 243 | macOS and Windows, on x64 and arm64. |
| 244 | - **Status.** Not scheduled. |
| 245 | |
| 246 | ### No background steps |
| 247 | |
| 248 | GitHub's background steps (`background: true` on a step, and `wait`, |
| 249 | `wait-all`, `cancel` and `parallel` steps) are refused: a workflow with one |
| 250 | does not run on g1t. A schedule's `timezone`, `concurrency.queue`, |
| 251 | `cancel-timeout-minutes` and `snapshot` are read but not applied: schedules |
| 252 | run in UTC, a concurrency group keeps one run waiting, a cancelled job stops |
| 253 | in its usual time, and no runner image is made from a job. The workflow's |
| 254 | page says so. |
| 255 | |
| 256 | - **Why.** They are newer than g1t's runner, which runs a job's steps one |
| 257 | after another. |
| 258 | - **Instead.** Start a long-running process with `&` in a `run:` step and |
| 259 | stop it in a later one; write a schedule's `cron` in UTC. |
| 260 | - **Status.** Not scheduled. |
| 261 | |
| 262 | ### Self-hosted Windows and macOS jobs run on the host |
| 263 | |
| 264 | On a self-hosted runner, a job native to Windows or macOS runs directly on |
| 265 | the machine, unsandboxed, in host mode, which is deprecated. Only Linux |
| 266 | jobs run in a sandbox of their own, a container inside the runner's own |
| 267 | container under Sysbox. |
| 268 | |
| 269 | - **Why.** Sandboxes for them are not built yet: Windows containers with |
| 270 | Hyper-V isolation, and ephemeral macOS virtual machines (two per Mac at |
| 271 | most, by Apple's licence). |
| 272 | - **Instead.** Run Linux jobs in |
| 273 | [the runner's container](/guides/self-hosted-runners/#run-it-as-a-container), |
| 274 | and keep Windows and macOS runners for repositories whose code you |
| 275 | trust. Host mode refuses public repositories' work. |
| 276 | - **Status.** Planned. See |
| 277 | [Windows and macOS](/guides/self-hosted-runners/#windows-and-macos). |
| 278 | |
| 279 | ### A self-hosted job's Docker can reach its runner's container |
| 280 | |
| 281 | On a runner in its container under Sysbox, a job that uses Docker gets an |
| 282 | engine of its own that is privileged inside the runner's container. It |
| 283 | cannot reach the machine, but it can reach the runner's container, |
| 284 | including the runner's credential. |
| 285 | |
| 286 | - **Instead.** Use ephemeral runners for code you do not trust, or |
| 287 | register with `--no-job-docker`. |
| 288 | - **Status.** Not scheduled. |
| 289 | |
| 290 | ### `actions/checkout` with Git LFS, or without git on a large repository |
| 291 | |
| 292 | `actions/checkout` is the action itself. With `lfs: true`, it finds no |
| 293 | LFS files: g1t keeps none. In a job container whose image has no git, it |
| 294 | downloads the commit as a tarball from |
| 295 | `GET /repos/{owner}/{repo}/tarball/{ref}`, as on GitHub. g1t makes that |
| 296 | tarball when it is asked, of up to 10,000 files and 24 MB, so the |
| 297 | checkout of a larger repository fails there. |
| 298 | |
| 299 | - **Why.** The tarball is made in a Worker, which holds the files and the |
| 300 | archive in memory at once. |
| 301 | - **Instead.** Keep large files out of Git LFS for now. For a large |
| 302 | repository, use an image with git, or install git in a step before the |
| 303 | checkout. |
| 304 | - **Status.** Planned. |
| 305 | |
| 306 | ### No `gh` command in jobs |
| 307 | |
| 308 | The runner does not include the `gh` command, and pointing it at g1t |
| 309 | (`GH_HOST=g1t.sh`) does not work. |
| 310 | |
| 311 | - **Why.** Most of `gh`'s commands use a GraphQL API, and the rest expect |
| 312 | the REST API under `/api/v3` on the same host. g1t's API is REST, at |
| 313 | `api.g1t.sh`. |
| 314 | - **Instead.** Call the API with `curl` and the job's token. See |
| 315 | [calling g1t's API from a job](/guides/actions/#calling-g1ts-api-from-a-job). |
| 316 | - **Status.** Not scheduled. |
| 317 | |
| 318 | ### One Ruby for `ruby/setup-ruby` |
| 319 | |
| 320 | On g1t's machines, `ruby/setup-ruby` finds Ruby 3.3, which the runner |
| 321 | includes, and fails for any other version. |
| 322 | |
| 323 | - **Why.** Its prebuilt Rubies are for other Linux systems, so on Debian it |
| 324 | uses only the Rubies already in `RUNNER_TOOL_CACHE`. |
| 325 | - **Instead.** Use 3.3, run the job in a `container:` with the Ruby you |
| 326 | need (such as `ruby:3.4`), or build it in a step with `ruby-build`. See |
| 327 | [languages and their setup actions](/guides/actions/#languages-and-their-setup-actions). |
| 328 | - **Status.** Not scheduled. |
| 329 | |
| 330 | ### Machine sizes, time and storage |
| 331 | |
| 332 | | Limit | Value | |
| 333 | | --- | --- | |
| 334 | | Largest machine | 4 vCPUs, 12 GiB of memory, 20 GB of disk (`g1t-4core`). No GPUs. | |
| 335 | | Standard machine | 2 vCPUs, 8 GiB of memory, 16 GB of disk (`ubuntu-latest`, every other hosted label, and `g1t-2core`). | |
| 336 | | One job on g1t's machines | 60 minutes. On a self-hosted runner, 24 hours. | |
| 337 | | One cache entry | 2 GiB, compressed. A larger one is not saved. | |
| 338 | | A repository's caches | 10 GiB together. Past it, the entries restored longest ago are removed. | |
| 339 | | One artifact | 5 GiB, zipped. Kept 14 days unless the repository says otherwise, at most 90. | |
| 340 | | A run's artifacts | 10 GiB together. | |
| 341 | |
| 342 | The machine sizes are Cloudflare Containers' instance sizes. For more, use a |
| 343 | [self-hosted runner](/guides/self-hosted-runners/). See |
| 344 | [Machine sizes](/guides/actions/#machine-sizes) and [the cache](/guides/actions/#the-cache). |
| 345 | |
| 346 | ### Workflow features not supported yet |
| 347 | |
| 348 | - Actions that upload or download artifacts with the toolkit's artifact |
| 349 | library themselves. The library refuses to run against any server but |
| 350 | github.com. `actions/upload-artifact`, `actions/download-artifact` and |
| 351 | `actions/upload-artifact/merge` work, as g1t runs them itself. |
| 352 | - A cache entry between 100 and 128 MB saved by `actions/cache` or another |
| 353 | action built on the toolkit, such as `setup-node` with `cache: npm`. The toolkit sends an |
| 354 | entry under 128 MB in one request, and g1t takes at most 100 MB in one |
| 355 | request, as for [pushes](#pushes-up-to-100-mb-each). The step warns and |
| 356 | the job goes on; smaller and larger entries are saved. |
| 357 | - `on: label`: creating, editing or deleting a label starts no workflows. |
| 358 | Putting a label on an issue or a pull request starts `issues` and |
| 359 | `pull_request` workflows with the `labeled` type. |
| 360 | - The `pull_request` activity types `unassigned`, `locked`, `unlocked`, |
| 361 | and `edited` for a new title or description, and the `issues` types |
| 362 | `unassigned`, `locked`, `unlocked`, `pinned` and `unpinned`: g1t starts |
| 363 | no workflows for them. |
| 364 | |
| 365 | See [Not yet](/guides/actions/#not-yet). **Status.** Planned. |
| 366 | |
| 367 | ### No npm trusted publishing or provenance |
| 368 | |
| 369 | A workflow on g1t can't publish to npm with trusted publishing, or with |
| 370 | `--provenance`. |
| 371 | |
| 372 | - **Why.** Both trade the job's OIDC token with npm and Sigstore, which |
| 373 | accept tokens only from the CI services they list. g1t's |
| 374 | [OIDC tokens](/guides/actions/#oidc-tokens) work with any cloud that |
| 375 | lets you add an issuer, and npm does not. |
| 376 | - **Instead.** Publish with a granular access token in a secret |
| 377 | (`NODE_AUTH_TOKEN`); see [npm](/guides/actions/#npm). |
| 378 | - **Status.** Depends on npm. |
| 379 | |
| 380 | ## Deployments |
| 381 | |
| 382 | ### A container is one instance, and keeps nothing |
| 383 | |
| 384 | A container app runs one instance at a time, sleeps after five minutes |
| 385 | without a request, and starts from its image each time it wakes. |
| 386 | |
| 387 | - **Why.** Each app's container is one Durable Object's, and Cloudflare |
| 388 | Containers' disks last only as long as the container runs. |
| 389 | - **Instead.** Keep data in a database or a bucket the app reaches over |
| 390 | the network. A larger **Container size** gives one instance more room. |
| 391 | |
| 392 | ### What a container sends out is not counted |
| 393 | |
| 394 | The data a container sends back to visitors is metered; what it sends to |
| 395 | other hosts on the internet (a database elsewhere, an API) is not. |
| 396 | |
| 397 | - **Why.** It leaves the container without passing through g1t. |
| 398 | - **Instead.** Nothing to do: it is not charged. |
| 399 | - **Status.** A runtime for servers is planned. |
| 400 | |
| 401 | ### Some Workers bindings are not provisioned |
| 402 | |
| 403 | A Workers project deploys without D1, KV, R2, Durable Objects, Queues, |
| 404 | service bindings, Vectorize, Hyperdrive, Workers AI or Workflows, and its |
| 405 | cron triggers are not scheduled. |
| 406 | |
| 407 | - **Why.** Each of these is a resource g1t has to create and bill per |
| 408 | project, and that is not built yet. |
| 409 | - **Instead.** Check that a binding exists before using it. The deployment |
| 410 | lists each binding it left out, and warns when its cron triggers will |
| 411 | not run. |
| 412 | - **Status.** Planned. See [Workers projects](/guides/deployments/#workers-projects). |
| 413 | |
| 414 | ### Build and size limits |
| 415 | |
| 416 | A build stops after 45 minutes. A static site can have up to 20,000 files |
| 417 | and 25 MiB per file, which are Cloudflare's limits. See |
| 418 | [Static sites](/guides/deployments/#static-sites). |
| 419 | |
| 420 | ## Data residency |
| 421 | |
| 422 | You can't choose where a workspace's data is stored. g1t's databases keep |
| 423 | their primary copy in the United States, with read copies in other regions |
| 424 | so pages load fast. Repositories are not pinned to a region. |
| 425 | |
| 426 | - **Why.** Cloudflare fixes the region of a repository store when it is |
| 427 | created, and g1t has one store so far. |
| 428 | - **Instead.** None today, if your data must stay in the EU. |
| 429 | - **Status.** EU residency, with an EU-only repository store and databases, |
| 430 | is planned. |
| 431 | |
| 432 | ## Billing |
| 433 | |
| 434 | ### Some costs are not fully defined yet |
| 435 | |
| 436 | Cloudflare's [Artifacts pricing documentation](https://developers.cloudflare.com/artifacts/platform/pricing/) |
| 437 | lists October 14, 2026 as the billing start, while its launch announcement |
| 438 | lists October 15. The pricing documentation identifies repository operations |
| 439 | such as create, push, pull and clone, and storage measured from daily peaks. |
| 440 | g1t's measurements still need reconciliation against the upstream bill. |
| 441 | |
| 442 | - **What g1t does.** It counts every clone, fetch and push through its git |
| 443 | endpoints. Each day it checks what Cloudflare billed it for containers and |
| 444 | apps against what was used. When a cost moves, |
| 445 | g1t's price moves with it, and every change is listed with its reason on |
| 446 | [g1t.sh/pricing](https://g1t.sh/pricing). |
| 447 | - **What this means for you.** Prices can change while Cloudflare's beta |
| 448 | products settle. They follow cost. |
| 449 | See [How prices are set](/guides/usage-and-billing/#how-prices-are-set) |
| 450 | and [git operations](/guides/usage-and-billing/#git-operations). |
| 451 | - **Status.** Depends on Cloudflare. |
| 452 | |
| 453 | ### Payments in test mode |
| 454 | |
| 455 | A g1t whose payments use Stripe's test mode, such as a self-hosted one set |
| 456 | up with test keys, or g1t.sh before its live payments are switched on, |
| 457 | charges no real card, so a card check there proves nothing. With live |
| 458 | payments, the card check and every charge are real. **Status.** By design |
| 459 | for test setups. |
| 460 | |
| 461 | ## Accounts, status and self-hosting |
| 462 | |
| 463 | ### Tokens for one workspace you belong to |
| 464 | |
| 465 | A personal access token can be made for one workspace only when you are a |
| 466 | member of it. For a repository where you are an outside collaborator, make |
| 467 | a token for all your workspaces. A workspace's |
| 468 | [rules for tokens](/guides/authentication/#a-workspaces-rules-for-tokens) |
| 469 | cover personal access tokens only, not applications you signed in to with |
| 470 | OAuth. **Status.** Planned. |
| 471 | |
| 472 | ### No uptime commitment during the beta |
| 473 | |
| 474 | g1t does not promise a particular uptime or offer a service level agreement |
| 475 | unless you have a written agreement with us. Several of the Cloudflare |
| 476 | products g1t is built on are in beta and have none either. |
| 477 | [status.g1t.sh](https://status.g1t.sh/) shows how each part of g1t is doing, |
| 478 | and every incident. Sandboxes are not checked there yet. See |
| 479 | [Status and incidents](/guides/status/). **Status.** Not scheduled during |
| 480 | the beta. |
| 481 | |
| 482 | ### Self-hosting is early |
| 483 | |
| 484 | [Running g1t yourself](/guides/self-hosting/) gives you the core forge: |
| 485 | accounts, repositories over HTTP, issues and pull requests, the REST API |
| 486 | and MCP, container images, search, webhooks and observability. Hosted |
| 487 | runners, deployments, billing and git over SSH are off. The merge queue |
| 488 | can accept pull requests, but cannot test or land them without g1t's |
| 489 | runner. Use the hosted service to try that integration loop. Self-hosting |
| 490 | is not ready for the open internet. **Status.** Planned, in phases. |
| 491 | |
| 492 | ### Not built yet |
| 493 | |
| 494 | |
| 495 | - **Wikis.** Not scheduled. Keep docs in the repository. |