Choose a deploy method
Last updated
Four ways in. The decision is mostly "do you have a Dockerfile, and do you want to build it yourself?"
Quick answer
| Situation | Use |
|---|---|
You have a Dockerfile |
Git Push |
| You don't, and it's Python / Node.js / prebuilt .NET | Upload a zip |
| You already build images in CI | Docker Push |
| You want to run someone else's published image | Existing Image |
| You want Postgres without configuring it | Prefab Template |
You can change your mind later — these are ways of getting an image onto the platform, not permanent commitments.
Git Push
Push your source; the platform builds it. First push creates the app, later pushes update it.
Needs a Dockerfile at the repository root, exactly that name. Two branches matter: deploy builds and ships, build builds without touching your running app — which is what you want while iterating.
Best for: most projects, and anything you'll deploy repeatedly.
Upload a zip
Drop in an archive of your project and an AI agent reads the actual files, works out the runtime and dependencies, writes the container configuration, builds it, then watches the logs to confirm it stayed up. It pauses to ask for secrets rather than guessing.
Handles Python, Node.js and prebuilt .NET. Other languages need a Dockerfile. There's a size cap on the archive and a daily build allowance, both shown in the panel.
Best for: no Dockerfile, or you'd rather not write one.
Docker Push
Build locally or in CI, push to the account's registry, and the platform runs it.
Two things to know: images must be linux/amd64 — an arm64 image built on an Apple Silicon Mac won't deploy, and fails quietly rather than loudly — and auto-deploy on push is opt-in from an existing app's Deployment tab.
Best for: existing CI pipelines, and builds too heavy for the platform's builder.
Existing Image
Point at any published image — postgres, gitea/gitea, your own registry — and set the command, ports, volumes and environment variables at creation time.
The one thing to get right: the run command becomes the image's command, and the image's ENTRYPOINT still runs. For an image whose entrypoint is already the program, the command is just its arguments. See Set the run command.
Best for: self-hosted tools and databases.
Prefab Template
A ready-made application with image, ports, volumes and validated parameters already filled in. The catalogue is small.
Best for: getting a database running without looking up its environment variables.
Whichever you choose
The build gets no environment variables and no build arguments, so anything inlined at build time — NEXT_PUBLIC_*, VITE_* — needs building in CI. And the platform's builder has less memory than your app does, so heavy asset builds and compiles are often happier in CI too.