Git Hosting
The remote every Remy app pushes to, the S3 tar that makes each push durable, and what a stale pod is allowed to show once its copy falls behind.
Every Remy app is a git repository, and the platform is its remote. The git role serves git over smart HTTP, keeps each repository on local NVMe while it is active, mirrors every push to S3 in the workspace's region, and turns a push to the default branch into a release. This chapter covers the server, its durability model, and how it stays consistent across pods.
#The Remote
An app's repository URL is on the platform's git host. Authentication is HTTP Basic with a workspace API key as the password, or a short-lived clone token the build service mints. The server checks that the key's owner has edit permission on the app before any ref is read or written.
The git role runs as its own Deployment on nodes with local NVMe formatted as a scratch volume, so repository copies are bounded by a sized disk and can never fill the node. It serves info/refs, upload-pack for clones and fetches, receive-pack for pushes, and platform routes for initializing, forking and rebuilding a repository.
#S3 Is the Source of Truth
A repository's durable form is a tar of its bare repository in the private bucket of its region, plus a version counter in Redis. Every pod's local copy is a cache of that tar: a pod hydrates a repository on first touch, prefers its local copy while its version matches, and evicts copies that go idle so per-pod disk stays bounded.
A push is durable before it is a release. receive-pack takes a per-repository push lock, lets git update the refs, and snapshots the repository to a tar. It uploads that tar under a separate sync lock, which serializes the whole backup: newest wins, the upload is safe across pods, and it never blocks the next push. Only then does post-receive run.
When a synchronous backup cannot land, because a sibling push holds the sync lock or S3 refused, the push is parked in a per-pod store. The store marks the repository dirty and retries on a debounce with a ceiling; the deferred post-receive runs once the repository is durable. On graceful shutdown, the store flushes everything pending before the pod deregisters.
Alongside the tar, every push mirrors the branch's files to S3 as individual objects, so the platform can serve a file from a commit through a signed URL without a bare repository on any disk.
#Stickiness
A repository is pinned to one git pod while it is active. The edge Worker that fronts the git host stores the load balancer's stickiness cookie per app and injects it on every request, so a clone, a push and its backup all land on the pod that holds the local copy. Stickiness is an optimization: the locks and the version counter are what make the system correct if it breaks.
#Consistency Fences
Two fences protect what a reader sees.
A stale-hydration fence. A pod whose local copy came from a backup that is behind the platform's record refuses to answer reads for that repository, because a clone from it would show a rewound default branch and missing branches. Pushes stay open, since an ordinary push onto the stale copy is exactly what repairs the backup.
A high-water mark. The platform's record of a repository's branches is updated only with the refs a push actually moved, measured by comparing the repository before the push to after it. A stale pod taking a branch push can never rewind the record's default branch.
#From Push to Release
Post-receive runs once the pushed commits are durable. It records the moved refs, mirrors the files, and creates releases: a main push produces a release that will be promoted to live, and a push to another branch produces a preview release. The default branch is always built; a push of many branches is capped so it cannot trigger an unbounded number of build sandboxes at once. The build itself is described in Build and Deploy.
Post-receive also reads the manifest from the pushed commit, computes the diff for the deploy record, and publishes the commit messages that become the changelog.
#Working Copies Across Regions
A repository whose home region is not the compute region follows the same working-copy model as app databases: a hot tar in the compute region while the repository is active, checkpointed back to the home region at least hourly, and finalized on cold. A hot marker in Redis, refreshed before every backup, tells the orphan sweep that a live pod is backing the repository.