NubiStack

NubiStack deploys an entire application in one go: several services, their databases and the wiring between them, described in a single nubicloud.yaml file.

Where NubiDeploy deploys one service at a time (and where you copy your database's connection string into the app's variables by hand), NubiStack does the whole round trip:

1. it provisions the declared databases,
2. it builds the services that come from your repository,
3. it wires the environment variables automatically (DATABASE_URL, the URL of a neighboring service, generated secrets),
4. it deploys in the right order, waiting for each dependency to come online.

When to use NubiStack rather than NubiDeploy?

ℹ️ The two coexist: a NubiStack stack is deployed into an environment of a project, exactly like a classic deployment, and its services then show up in NubiDeploy.

Before you start

• A project and at least one environment (see Projects).
• A connected repository if your services are built from a private repo (see Connecting a repository). A public repository can be used without connecting anything.
• Sufficient quotas on the project: the plan adds up the resources of all the blocks before applying.

The journey in three steps

Open NubiStack in the console's side menu.

1. Editor

Choose the target project and environment, then provide your manifest. Three ways:

• Load an example — a commented nubicloud.yaml that you adapt.
• Detect from a repo — the platform analyzes your repository (or its docker-compose.yml) and generates the manifest. See Detecting from a repo.
• Paste your manifest directly.

The environment's existing stacks are listed above the editor: click one of them to reopen its tracking view.

Click Plan.

2. Plan

The plan is a simulation: nothing is created. Block by block, you see:

The plan also shows:

• the wired environment variables — flagged Automatic wiring for those resolved by the platform, and Sensitive value (hidden) for secrets;
• the CPU / memory / storage totals, checked against the project's quota (Quota OK or Quota exceeded);
• the warnings;
• the secrets to provide — the variables declared sync: false, which will be asked of you at the first deployment.

⚠️ Quota exceeded blocks the application of the stack. Reduce a block's resources, or increase the project's quota (Project quotas).

If everything looks right, click Apply. Otherwise, Back to fix the manifest.

3. Stack

You switch to the stack tracking view. Each block progresses through states (Declared → Building → Deploying → Online), automatically, every ~30 seconds. The view refreshes on its own.

The details of the states and the actions (restart, edit, delete) are on Stack lifecycle.

A minimal example

name: demo-shop

databases:
  - name: db
    type: postgres
    resources: { cpu: 0.5, memory: 1, storage: 2 }

services:
  - name: api
    type: web
    framework: python-fastapi
    build:
      repo: https://github.com/you/your-repo
      branch: main
    port: 8000
    exposePublic: true
    resources: { cpu: 0.25, memory: 0.5 }
    env:
      DATABASE_URL: { fromDatabase: { name: db, property: connectionString } }
      SECRET_KEY: { generateValue: true }
      LOG_LEVEL: info

  - name: worker
    type: worker
    framework: python-fastapi
    build:
      repo: https://github.com/you/your-repo
      branch: main
    command: ["celery", "-A", "app", "worker"]
    env:
      DATABASE_URL: { fromDatabase: { name: db, property: connectionString } }

This manifest creates a PostgreSQL database, builds your repository twice (a publicly exposed web service, a background worker), and injects the database's connection string into both — without you having to copy a password.

See also

• The nubicloud.yaml manifest — the full field reference.
• Detecting from a repo — generate the manifest automatically.
• Stack lifecycle — states, restart, editing, deletion, update on git push.