Deployments

FluxNow deploys are driven entirely by branch activity. There is no manual deploy button.

Staging deploys

Any push or merge to your default branch (main or master) triggers a staging deploy automatically.

Deploy process

1. Build — FluxNow builds a container image from your repository using the configured build strategy (Dockerfile or Railpack).
2. Push — the image is pushed to the FluxNow container registry.
3. Release — the release command (e.g. database migrations) runs as a pre-deploy step before traffic switches.
4. Rolling update — the new image rolls out in Kubernetes with zero-downtime deploys. Old pods stay running until new ones pass health checks.

Holding the rollout

By default a push builds and rolls out. To build and push the image but hold the rollout (bump the tag / promote manually), set deploy.auto: false in fluxnow.yaml. See Builds & Deploy.

Release command (migrations)

The release command runs once before each deploy — most commonly to apply database migrations, but it works for any pre-deploy task (seeding, cache warm-up, etc.). Set it with spec.release in fluxnow.yaml:

fluxnow.yaml

spec:
  runtime: node
  port: 3000
  release: bun run db:migrate

How it runs:

• As a pre-deploy step (an init container) using your built app image, with the same environment and secrets as your app — so it has DATABASE_URL and everything else your app sees.
• It runs against the target environment’s database (staging, production, or a preview), before the new version receives traffic.
• If it exits non-zero, the deploy halts and the previous version stays live.

Auto-detection

If you don’t set spec.release, FluxNow tries to detect a release command:

• a Procfile release: line (Heroku convention), or

• a framework default — for example:

  Framework	Detected command
  Rails	bundle exec rake db:migrate
  Django	python manage.py migrate
  Elixir / Ecto	mix ecto.migrate
  Prisma (Node)	npx prisma migrate deploy

Set spec.release explicitly to override the detected command, or to run something other than migrations.

Caution

Because a failed release halts the deploy, migrations should be idempotent and backwards-compatible with the currently running version (it keeps serving traffic until the new pods are healthy).

Zero-downtime deploys

FluxNow uses Kubernetes rolling updates. The old version continues serving traffic until the new pods are healthy. There is no maintenance window.

Deploy history and logs

The project dashboard shows a full list of deploys with status, timestamps, and streaming build and runtime logs per deploy.