Deploying

Supported stacks

Orizon inspects your files to choose how to build and run your app. Here's what it detects and the one rule server apps must follow.

Detection order

Detection runs top-down — the first match wins — so an explicit Dockerfile always takes precedence over framework heuristics:

Docker — a Dockerfile or docker-compose.yml is present.
Next.js — a next.config.* or next in package.json; run as a server.
Go — a go.mod or .go files.
Rust — a Cargo.toml.
PHP — a composer.json or .php files (with an optional public/ docroot).
Python — requirements.txt, pyproject.toml, or .py files.
Node / Bun — a package.json; Bun is used when a Bun lockfile is present.
Procfile — a custom start command via Procfile.
Static — a lone index.html.

You can review and override the detected build in the deploy flow before shipping.

The PORT contract

Every server app on Orizon must listen on the port given by the PORT environment variable. Orizon runs your container with PORT=3000 and proxies public HTTPS traffic to that port. Bind to 0.0.0.0, not localhost.

shell

// Node / Express
app.listen(process.env.PORT || 3000, "0.0.0.0");

# Python / Gunicorn
gunicorn app:app --bind 0.0.0.0:$PORT

// Go
http.ListenAndServe(":"+os.Getenv("PORT"), nil)

Who doesn't need PORTStatic sites and PHP apps are served directly behind Caddy — there's no long-running server you manage, so the PORT contract doesn't apply to them.

Anything else

If your stack isn't auto-detected, add a Dockerfile — that gives you full control over the build and runtime and works for any language or framework.

Dockerfile

The escape hatch for any stack.

Deployments & rollback

How releases roll out and roll back.