gagarinDocumentation

Leaving

We are new and we are small, and you are thinking about trusting us with something you wrote. “What happens if you disappear?” deserves a command, not a paragraph about our values.

This page used to carry a “promised, not built” label. The command exists: gg eject, available to whoever owns the project.

What you get back

One YAML stream with the Kubernetes manifests for the whole project. The format is not the point; where they came from is. These are the actual objects the platform reconciles the cluster against — not a second generator’s impression of them. A second generator drifts from the first eventually, and an export that has quietly stopped matching production is worse than no export at all: a trust feature turns into a trust incident.

  • Namespace, first — a file that assumes one already exists will not apply to a clean cluster.
  • Deployment, Service, Ingress for each service. Ordinary ones, with none of our annotations and no operators to go and install.
  • NetworkPolicy — your declared dependencies, as rules. The graph moves house with the application.
  • A Secret with the environment, in the clear, because otherwise what you exported will not start at all. That is why only the owner can run this: it is a deliberate export of credentials, not a read of state.

There is no Dockerfile in there, and that is not an oversight — it is already in your repo. We never built your images and we never rewrote them, so there is nothing of yours for us to be holding.

From there it applies anywhere: kubectl apply, move the images, move the domain. An evening’s work rather than a quarter’s.

GG EJECT HANDS OVERNamespaceDeploymentServiceIngressNetworkPolicySecret with the envLEFT OUT OF THE EXPORTDockerfilealready sitting in your repoimagesalways were yours, move themvolume datathe PVC is here, the contents are notcluster, domain, billingyours to sort out
fig. 7 · One line decides what goes in: inside is what the platform reconciles the cluster against — the actual objects, not a second generator’s impression of them, which would drift from the first soon enough.

Why we can do this at all

A model you can read is a model you can export: projects, services, ports and dependencies turn into manifests almost mechanically. The big clouds cannot do this — not because they are holding you hostage, but because there is nothing to translate. The state is spread across four mechanisms and no single coherent description of it exists, for you or for them.

What the export does not give you

The cluster, the domain and the billing are yours to sort out: we hand over a description, not infrastructure. And it is not a backup — eject is a snapshot of the moment you ran it, not a history.

Nor your third-party keys. A database password we minted for this project comes out with everything else — it is only worth anything against a database in the same file, and an export without it does not start. A key from an external resource is a different thing: OpenAI issued it to you, it stays live wherever the file ends up, and it is worth something to anyone who opens the file. Those come out as a placeholder naming the resource they came from, and the header lists exactly which variables to paste back. --with-secrets includes them if you would rather — for a migration you are doing right now, into a file you are about to delete.

The data moves with you too, and you move it. The export does not dump it: a service’s volume shows up as a PersistentVolumeClaim in the manifest, not as its contents. pg_dump against a running database works the way it always has, but the command will not run it for you, and we are not going to imply otherwise on this page.