The Basics

These are the building blocks you work with on StackBlaze.

In a nutshell

• Dashboard — every project under your account.
• Project — a canvas of services that share a private network in each environment.
• Service — a deploy target: Git repo, Docker image, template, or database.
• Variables — config and secrets for a service. Database URLs can be wired from an attached database.
• Deployment — a built image rolled out to a service.
• Volume — disk that survives restarts, attached to one service.
• Environment — an isolated copy of the canvas (production, a custom phase, or a pull-request preview).

Dashboard

The dashboard lists your projects. Open a project to land on its canvas.

Projects

A project is the unit you compose infrastructure in. Think of it as an application stack: an API, a worker, Postgres, and Redis as tiles on one board.

Services in the same environment are on a private network scoped to that environment. They reach each other by service name (for example postgres:5432). Traffic does not cross projects on that network.

The canvas

The canvas is mission control. From + Service you add:

Action	What it adds
Git repository	A service built from GitHub or a public git URL
Docker images	A service from a registry image
Templates	A pre-wired group of services and databases
Databases	A managed database on the same canvas
Import	Compose, render.yaml, or fly.toml mapped onto services

New tiles and config edits are staged. Deploy applies them.

Services

A service is a container that StackBlaze builds and runs. Source is a Git repo, a Docker image, or a template. If the repo has a Dockerfile, that file is used; otherwise Nixpacks detects the runtime.

A service can:

• Listen for HTTP and get a public domain (public HTTP)
• Run continuously with no public domain (private services)
• Run on a cron schedule until it exits (cron jobs)

Databases are services on the canvas too. They are managed add-ons (Postgres, Valkey/Redis, MariaDB, and others), not app processes.

Click a tile for source, variables, networking, volumes, metrics, and logs.

Variables

Variables are injected at build and runtime. Set them on the service. In stackblaze.yaml, point a key at a database with fromDatabase instead of hardcoding a URL.

Shared groups can be referenced from config as code (fromGroup). Prefer that over copying the same secret onto every service.

Deployments

A deployment builds the service image and rolls it out in the current environment. Triggers:

• Deploy on the canvas (staged changes)
• A push to the connected branch when auto-deploy is on
• Deploy hooks or POST /api/deployments/build/{project}/{environment}/{service}

You can restart without rebuilding, and roll back to a previous revision. Automate with the CLI, the API, or MCP.

Volumes

Volumes keep data across restarts. Attach one to a service and set the mount path. A volume is bound to that service instance; it is not a shared filesystem across replicas.

Environments

Each project has one or more environments. Production is created with the project. You can add more. Pull-request previews use a review environment and clone the source service so previews do not share production data.

See Environments.

Regions

A project is pinned to a region (default us-east-1). Services and databases in that project run there.

Names in the API

The dashboard copy says project, environment, and service. Some API paths still use Kubero names. They map one-to-one:

In these docs	In the API
Organization	Tenant
Project	Pipeline
Environment	Phase
Service	App
Database	Addon kind (Cluster, Valkey, MariaDB, …)

Address a service as /api/apps/{pipeline}/{phase}/{app}. Do not use kubectl — the dashboard and API are the interface.