Answer
How to deploy an app from an AI agent without building a Docker image
Push source to a git remote and let the platform build it. Most agents cannot produce a container image — there is no Docker daemon in the sandbox, no registry credentials, and no CI to borrow — but essentially every coding agent can run git push. Slipdock hands each workspace a free private git repository that is also the deploy source: push, we build it with buildpacks, and you get an HTTPS URL back. No Dockerfile required, no registry, no pipeline.
$ curl -s https://api.slipdock.ai/v1/repos -H "$AUTH" \ -d '{"name":"my-app"}' {"clone_url":"https://git.slipdock.ai/ws_7f3a/my-app.git"} $ git init -b main && git add -A && git commit -m "initial" $ git remote add slipdock \ https://ws_7f3a:$SLIPDOCK_TOKEN@git.slipdock.ai/ws_7f3a/my-app.git $ git push -u slipdock main → detected runtime → built → deployed → https://my-app.slipdock.app (HTTPS, scale to zero)
Why this shape and not a container push
- Agents already have git. It is in the sandbox, the credentials are the same API token, and the agent has almost certainly used it in this session already.
- A container push needs four things an agent usually lacks: a working daemon or buildkit, a registry it is allowed to write to, an image name it can reason about, and a way to authenticate to both.
- The repo is something the agent receives, not something we promise. It exists in its first minute, before any payment, and it is a plain git remote — clone it and take it elsewhere whenever you like.
Getting a real domain onto it
$ curl -s https://api.slipdock.ai/v1/dns/example.com/point-at-app \ -H "$AUTH" -d '{"app":"my-app"}' {"records":["A example.com","CNAME www"],"tls":"issuing"} # one call: DNS written, certificate issued on first request
Because the domain, the DNS and the app are in the same workspace under the same token, there is no copying of nameservers between two dashboards and no waiting for a human to paste a record. That is the aggregation argument in one call.
What you should know before relying on it
- Cold starts. The free and standard app plans scale to zero, so the first request after idle takes a couple of seconds. An always-warm plan keeps an instance running. We would rather sell that difference than hide it.
- Quotas throttle, they do not bill. A free workspace that exceeds its allowance slows down; it does not generate an invoice.
- Paid plan prices are not published yet. The ladder is being revised because the previous draft included more bandwidth than the price covered. The free tier is unaffected and the pricing page says so plainly rather than quoting a number we would have to raise.
- This is pre-launch. The push-build-deploy path works end to end in staging, but state durability and public DNS delegation are not finished. Full status.
Related questions
Do I need a Dockerfile?
No. Buildpacks detect common runtimes from the source. If you do have a Dockerfile, that is fine too.
What credentials does git push need?
The workspace id as the username and your API token as the password. One credential for the REST API and for git, deliberately — there is no second thing to manage or leak.
Can I move the app somewhere else later?
Yes, and this is a written commitment rather than a courtesy. The repository is a plain git remote with your source and history in it — clone it and deploy anywhere. Databases dump with pg_dump, DNS exports as a zone file, billing history exports from the ledger, and none of it costs anything or requires talking to a person. Export works even while a workspace is suspended for non-payment. The full commitment.