Ruust
PricingBountiesDocs
Deploy an Egg ✦
Docsruust.yaml (config as code)

ruust.yaml (config as code)

Declare an Egg's configuration in a ruust.yaml at your repo root: port, health check, replicas, start and release commands, the Node version, and non-secret env defaults, all versioned with your code.

A ruust.yaml in the root of your repo lets you configure a web Egg in code rather than by hand in the dashboard. Ruust reads it during each build (from your cloned commit) and applies what it declares, so your Egg's configuration lives with your code, travels with it across branches, and is reviewed in the same pull request. It is entirely optional: no file means Ruust keeps detecting things the way it always has (a Procfile release line, a Dockerfile EXPOSE, and your dashboard settings).

An example

yaml
# ruust.yaml, at the root of your repo
port: 3000
healthCheckPath: /healthz
replicas: 2
startCommand: node server.js
releaseCommand: npm run migrate
nodeVersion: "20"

env:
  NODE_ENV: production
  FEATURE_NEW_NAV: "true"
Every field is optional; declare only what you want to pin.

The fields

  • port: the port your web app listens on (1 to 65535). Ruust routes and health-checks this port and injects it as PORT.
  • healthCheckPath: the absolute path Ruust probes to decide an Egg is healthy before it goes live (for example /healthz).
  • replicas: how many identical containers run behind the Egg (a database Egg always runs one).
  • startCommand: the command that starts your app, for a Nixpacks build. A Dockerfile CMD always wins.
  • releaseCommand: a one-off command run before each roll (migrations, for example). Overrides a Procfile release: line.
  • nodeVersion: the Node major for a Nixpacks build (for example "20"). Set here it is authoritative, so the dashboard picker is read-only and shows it is managed by ruust.yaml. An engines.node, .nvmrc, or .node-version in your repo works too.
  • env: a map of non-secret defaults, merged into your Egg's environment.

How it settles with the dashboard

The repo is the source of truth for the fields it declares, the same way a Procfile or Dockerfile is: on each build, the declared values are applied. Two deliberate exceptions keep it safe. First, a port you set explicitly in the dashboard wins over a declared port, so a manual override survives a rebuild. Second, env is merged, never replaced: a manifest variable only fills a key you have not already set, and it never overwrites or deletes a value you set in the dashboard.

Deploy on Ruust ->