Which Deploy Path Should You Use? A Five-Way Decision Guide
There are five ways to get an app running, and the right one is decided almost entirely by what you already have. If you have source code and don't want to write a Dockerfile, upload a zip and let the build agent work it out. If you have a Dockerfile, push by git. If you already build images, push the image. If you want Postgres, use the template. If you want to run software someone else published, point at their image. The rest of this is the constraints that make one of those wrong for your case — because each path has exactly one thing that will stop you, and they're easy to check up front.
The docs have a short version of this; what follows is the same decision with the constraints that actually decide it.
The five paths at a glance
| Path | You bring | The catch |
|---|---|---|
| Runny AI Agent (Simple tab) | Source in a zip | Python, Node.js, or prebuilt .NET only |
| Git Push (recommended) | A repo with a Dockerfile | Needs a Dockerfile at the root |
| Docker Push | An image you build locally | You need Docker on your machine |
| Prefab Template | Nothing | Currently just Postgres |
| Existing Image | A public image reference | Pulls from a third-party registry |
Runny AI Agent — you have source, not a Dockerfile
Zip your project, upload it, and an agent reads the source, infers the runtime and dependencies, builds it, and deploys. If the first attempt fails it reads the logs and makes one corrective attempt.
Pick it when you want something running today and don't want to think about containers.
The constraint: it handles Python, Node.js, and prebuilt .NET publish output. Go isn't supported on this path, nor is anything else exotic — those need a Dockerfile. The zip is capped at 50 MB, and builds are metered per day, so it's not the path for a tight edit-deploy loop.
Details: what the agent decides for Node, and for .NET.
Git Push — you have a Dockerfile
Add a remote, push a branch, and the platform builds your Dockerfile and restarts the app, streaming the build output back into your terminal.
Pick it when you want repeatable deploys and control over the image. It's the recommended path for a reason: your build is explicit, and pushing is one command.
The constraint: there must be a Dockerfile at your repository root — the push is rejected with a clear message if not. Also worth knowing: the remote is push-only (you can't clone from it), only the deploy and build branches do anything, and one push at a time per app.
That build branch is underrated — it builds the image and attaches it without restarting, so you can bake on every merge and roll out deliberately. Details: deploying by git push, and from GitHub Actions.
Docker Push — you already build images
Log in to your account's private registry, build locally, push. The registry and the runtime are the same system, so there's no cross-provider pull and no pull rate limit.
Pick it when your build is already tuned, or you build in CI and want the artifact to be the thing you ship.
The constraint: you build it, so you need Docker where you're building. Auto-deploy is opt-in — tick it on the app's Deployment tab and push a tag ending _autodeploy; without that, a push stores the image and changes nothing.
Details: private registry and Docker push.
Prefab Template — you want a database
One click, pre-configured. The constraint is the catalogue: right now it's Postgres and nothing else. If that's what you want, it's the fastest path there is; if it isn't, this path has nothing for you yet.
Details: running your own Postgres.
Existing Image — you're running someone else's software
Point at a published image, set env vars, volumes, and ports in the create form, and start it. Uptime Kuma, a database, a self-hosted tool — anything on a registry.
The constraint: this is the one path that keeps pulling from a third-party registry, so Docker Hub's pull limits apply to it in a way they don't to the others. It's also the path where you are responsible for knowing what the image needs — which directory to persist, which port it listens on.
Details: self-hosting a tool from an image.
Deciding in thirty seconds
- Just want it running, wrote it in Python or Node? → Runny AI Agent.
- Wrote it in Go, Rust, or something unusual? → Dockerfile + Git Push.
- Already have a Dockerfile? → Git Push.
- Already build images in CI? → Docker Push.
- Want a database? → Prefab Template.
- Running published software? → Existing Image.
If two look equally right, pick Git Push. It's the one that stays correct as a project grows, and a Dockerfile is the most portable thing you can own — it works the same here, on your laptop, and anywhere else.
You can switch later
None of this is a commitment. An app is a container plus its configuration; how the image got built isn't baked in. A project that started as a zip upload can move to git push by adding a Dockerfile, and its env vars, volumes, and ports come along unchanged.
The usual trajectory is exactly that: zip to get it live, Dockerfile once you know what the container should be. Starting on the fast path doesn't cost you anything later.
FAQ
Which deploy method should I use?
Whichever matches what you already have: source without a Dockerfile → zip upload; a Dockerfile → git push; a built image → Docker push; a database → template; someone else's software → existing image.
Can I deploy Go without a Dockerfile?
No. The zip path's agent supports Python, Node.js, and prebuilt .NET. Go needs a Dockerfile, which is a small one — it's a static binary.
What's the difference between Git Push and Docker Push?
Git Push sends source and the platform builds your Dockerfile. Docker Push sends an image you already built. Use git push unless you need control over where the build runs.
Do I need Docker installed?
Only for Docker Push. The zip and git paths build server-side.
What templates are available?
Currently one: Postgres. For anything else, use Existing Image with the published image reference.
Can I change how I deploy later?
Yes. The app keeps its configuration, volumes, and ports regardless of how the image is produced, so switching paths is just a different way of supplying a new image.
Wrapping up
Five options sounds like a decision, but it collapses to one question — what do you already have — and each path fails loudly and early if it's the wrong one, rather than halfway through. Start with whatever gets you running today, and move to a Dockerfile when you actually care what's in the container. That's the sequence most projects want anyway.