Skip to content
uploy docs

Deployments & builds

What it is

Section titled “What it is”

A deployment is a single attempt to build and run a specific commit of an app. Builds use Nixpacks: no Dockerfile required.

Build flow

Section titled “Build flow”
  1. GitHub sends a webhook to uploy on push to the configured branch.
  2. uploy records a new deployment and enqueues a build job on NATS JetStream.
  3. A build worker clones the repo, runs Nixpacks to produce an OCI image, and pushes it to the internal registry.
  4. uploy applies updated Kubernetes Deployment and Service manifests referencing the new image tag.
  5. Traefik routes traffic to the new pods once they pass the readiness check.

Supported runtimes

Section titled “Supported runtimes”

Whatever Nixpacks detects: Node.js, Python, Go, Ruby, Rust, PHP, Java, static sites. Version is auto-detected from your package.json, pyproject.toml, go.mod, etc. To pin a version, use the runtime’s standard mechanism (e.g. Node.js engines, Python .python-version).

Logs

Section titled “Logs”

Build logs and runtime logs are streamed to the dashboard in real time. See Logs reference.

Limits & defaults

Section titled “Limits & defaults”
  • No hard build timeout is enforced today. A stuck build occupies one worker slot until it exits (Phase 5 hardening will add an explicit timeout).
  • No per-tier daily build quota is enforced today.
  • Deployment rows are kept indefinitely; one-click rollback to a previous deployment is not yet shipped (see docs/known-technical-debt.md).
Section titled “Related”