Monorepo Support

FluxNow supports monorepos natively. A single repository can hold multiple apps; you list them under apps[] in fluxnow.yaml, and each becomes a separately built, provisioned, and deployed unit.

Declaring apps

Use kind: Monorepo and list each app under apps[]. Every app has a name, a path (its source directory), and a spec:

fluxnow.yaml

version: v1
kind: Monorepo
metadata:
  name: my-monorepo
apps:
  - name: api
    path: apps/api
    spec:
      runtime: node
      port: 3000
      db:
        enabled: true
      redis:
        enabled: true
  - name: worker
    path: apps/worker
    spec:
      runtime: go
      port: 8080

Apps can have different runtimes (a Node API alongside a Go worker), different ports, and different infrastructure.

Per-app infrastructure (not shared)

Each app provisions its own infrastructure, opt-in per app — they are not shared across the monorepo. Enable a resource under that app’s spec:

• db.enabled: true → its own Postgres database
• s3.enabled: true → its own S3 bucket
• redis.enabled: true → its own dedicated Valkey (Redis) instance

An app that omits a block gets nothing for it. Connection details are injected into that app’s container only. See the individual service docs for the exact environment variables.

Per-app builds

Each app builds its own container image from its path. Set the build strategy under spec.build — railpack (zero-config), dockerfile, or auto — along with optional buildCommand / startCommand / context. See Builds for details.

Cross-app references (refs)

When one app needs to reach another — a frontend calling its backend, a worker calling an API — use refs. It maps an environment variable name to a sibling app’s name, and FluxNow injects that sibling’s public host into the env var at deploy time. You don’t hardcode URLs, and you don’t have to know the host format.

refs sits at the app level (a sibling of spec):

apps:
  - name: api
    path: apps/api
    spec:
      runtime: go
      port: 8080

  - name: web
    path: apps/web
    spec:
      runtime: node
      port: 3000
    refs:
      API_HOST: api          # env var → sibling app name
      # your web app reads process.env.API_HOST

How it resolves

refs are environment-aware — they point at the right instance of the sibling for each environment:

Environment	API_HOST becomes
Staging	<customer>-api.<domain> (e.g. acme-api.openfab.dev)
Preview (PR #42)	<customer>-api-pr-42.<domain>

So in a preview, web talks to the same PR’s api preview — not staging. Open a PR that changes both apps, and the frontend preview automatically hits the matching backend preview. On staging, both point at staging.

Rules

• A ref target must be the name of another app in the same monorepo. Dangling refs are rejected at config-parse time — a typo fails fast instead of injecting an undefined host.
• Refs give you the public host (over the ingress/TLS), so calls work the same way in every environment. Prepend your scheme (https://) in the app as needed.

Incremental deploys

When you push to your default branch, FluxNow rebuilds only the apps whose source files changed (each app’s CI workflow is scoped to its path). Unchanged apps are not rebuilt or redeployed, keeping deploys fast even in large monorepos.

Preview environments

Monorepo preview environments work like single-service previews: each PR gets preview environments for the apps, with Postgres databases branched from staging. S3 and Redis are not provisioned per-preview (see their service docs).