Docs

Multi-app projects

One repo, many apps — each deployed, scaled, addressed, and configured independently.

Beyond its primary app, a project can run any number of additional apps: more web services from the same monorepo, background workers, static sites, and cron jobs. Apps deploy independently, keep independent histories and rollbacks, and never interfere with each other's releases.

App types

TypeRuns asURLHealth checks
WebContainer with an HTTP listener<project>-<app>.buildfyio.com + custom domainsTCP on the app port
StaticEdge file server (no container)Subdomain + custom domains
WorkerHeadless container — no HTTP neededNone (background)Process liveness only
CronHeadless container on a scheduleNoneProcess liveness only
Workers and crons are first-class: they get no port probes (a queue consumer that listens on nothing is healthy as long as it runs), no public route, and their logs stream in the dashboard like any other app.

Addressing

  • The primary app serves <project>.buildfyio.com.
  • Every web/static app gets its own stable <project>-<app>.buildfyio.com automatically at creation.
  • Custom domains attach per appwww.example.com on the site, api.example.com on the API, from each app's Domains section.
  • Apps inside one project share a private network and can call each other directly; other projects cannot reach them.

Configuration per app

  • Environment: shared variables flow to every app; app-scoped variables override them for that app only. See Environment variables.
  • Build & start commands, root directory, port — editable per app. A worker's start command is typically npm run worker.
  • Instance size and replicas — each app scales on its own (1–3 replicas by default).

Deploy lifecycle

Each app promotes and retires strictly within its own lineage: deploying the admin app never touches the web app's running release. Rollbacks are also per app.

Backing services

Databases and caches (Postgres, Redis, MySQL, Mongo, …) run as dedicated services or image-backed apps (mongo:7, ghcr.io/you/service:tag) — no build step, deployed straight from the image.