Taking your work with you

Nothing here needs Aidrop’s permission or a support request. It is written down because a way out that only exists if you ask is not much of a way out.

Your code

Your repository lives in your Team’s own Git service at git.aidrop.cloud, and you hold a credential for it. Ask your agent: repository_get answers the clone URL and the push credential for any repository on that service, and repository_create answered the same when it made one. Then clone as you would any repository:

git clone https://git.aidrop.cloud/<team>/<repository>.git

The credential reaches every repository in your Team’s service, so one clone loop takes all of them. If you connected a GitHub repository instead, it was always yours and Aidrop only ever read it.

Your database

Aidrop keeps no backups. That is a decision rather than a gap, and it is only honest while you can take a copy whenever you want one — so you can, and your agent is how. Everything done to a database happens through the agent, and a copy is no exception.

Two ways, by size:

• Read it over MCP. shared_database_query runs any statement against the instance, or against one database inside it, and answers CSV. One statement is stopped after 30 seconds and its answer cut at 64 KB, so the agent takes a copy table by table, in pages, with the schema from information_schema. Right for a small database: it is the same read the agent uses to check that a migration landed.
• Run pg_dump from inside the Project. The instance sits on a private network with no published port, so nothing outside the Project reaches it — but every Service attached to it is handed a connection string that works from there. Have your agent deploy a small Service that runs pg_dump against that connection string and sends the file over HTTPS to storage you own — an S3 bucket, or wherever you keep copies. A container’s only way out is HTTPS, so that is the path. On a schedule, this is your backup policy.

Either way the copy is yours and Aidrop keeps none of it. There is no retention window to ask about because there is no retention.

Two things worth knowing before you need them:

• The cache has no copy to take, because it holds nothing that survives a restart by design. The queue keeps a volume, but what it holds is work in flight rather than a record, so there is nothing to hand over either.
• shared_resource_delete is confirmed and not recoverable. Take the copy first.

Your images — and why they are not on this list

Aidrop builds your source into a container image and keeps it in a registry service of your own. You cannot pull it, and that is deliberate rather than an omission.

An image is derived from your code: it is what a build produces, not something Aidrop holds on your behalf. With the repository and the database you have both inputs, and any builder — docker build, or the Dockerfile your repository already carries — reproduces the same artefact. Issuing you registry credentials would add an account, a revocation path and a rate limit to maintain, in exchange for a file you can rebuild in a minute.

If your repository has no Dockerfile because Aidrop inferred the build, service_get reports the runtime settings it built under — the port, the health path and the build path — which is the whole of what the build knew.

What Aidrop keeps after you leave

Deleting a Service removes its container and its address, and unlinks it from every backing service without removing the service — another Service may still be mid-transaction against it. The repository stays, and can still be cloned.