Getting Started
Blueprint: infrastructure as code
A stackblaze.yaml file in your repository root defines all your services, databases, and environment variable wiring as code. Push the file, and StackBlaze creates everything in a single operation, no clicking through dashboards, no manual linking.
Blueprints are ideal for teams. Infrastructure changes go through code review just like application changes. New team members clone the repo and run one command to get a fully wired environment. One PR, one blueprint update.
One PR, one blueprint update
Infrastructure changes go through code review like everything else. Reviewers can see exactly what services will be added, removed, or modified before the blueprint is deployed.
stackblaze.yaml example
services:
- name: web
type: web
runtime: node
buildCommand: npm install && npm run build
startCommand: npm start
envVars:
- key: NODE_ENV
value: production
- key: DATABASE_URL
fromService:
name: postgres
property: connectionString
# ─────────────────────────────────────────
- name: worker
type: worker
runtime: node
startCommand: node worker.js
# ─────────────────────────────────────────
- name: postgres
type: postgres
plan: starter
# ─────────────────────────────────────────
- name: redis
type: redis
plan: starter
Blueprint deploy flow
Step by step
Create stackblaze.yaml in your repo root
Add a stackblaze.yaml file to the root of your repository. Define all your services, databases, and how they connect to each other. The example below creates a full stack: a web service, a background worker, a PostgreSQL database, and a Redis cache, all wired together.
Push to GitHub - StackBlaze detects it automatically
When you push a branch that contains a stackblaze.yaml, StackBlaze detects the blueprint file on the next webhook event. A banner appears in the dashboard indicating a blueprint was found, and a "Deploy Blueprint" button is shown alongside a diff of what will change.
Click "Deploy Blueprint" or run the CLI
Trigger the blueprint deploy from the dashboard or run "stackblaze deploy" in your terminal. StackBlaze validates the blueprint, resolves all service references, and begins creating resources simultaneously.
All services are created and linked in one operation
Rather than provisioning services one by one, StackBlaze creates them as a single atomic operation. Services with "fromService" references wait for their dependency to be ready before their env vars are injected. You can watch the progress live in the dashboard.
Check it in to version control
The stackblaze.yaml file is your infrastructure's single source of truth. Commit it alongside your application code. Team members cloning the repo for the first time can spin up an identical environment with a single command, no tribal knowledge required.
fromService references
The fromService key wires one service's output into another's environment variable. StackBlaze resolves these at deploy time, you never hard-code connection strings.
# postgres service properties
connectionString # Full DSN including credentials
host # Internal cluster hostname
port # 5432
database # Database name
# redis service properties
connectionString # redis://:password@host:6379
host # Internal cluster hostname
port # 6379
Under the hood
When you deploy a blueprint, StackBlaze parses the YAML server-side and creates Kubernetes resources for each service entry. All resources share a single Namespace named after your project.
- web type: creates a Kubernetes Deployment plus an Ingress with automatic TLS via cert-manager. The service is publicly reachable immediately after the first deploy.
- worker type: creates a Kubernetes Deployment with no Ingress. The pod runs in the private project namespace and can reach other services by their cluster DNS name.
- postgres / redis types: create Kubernetes StatefulSets with persistent volumes. The operator provisions credentials, stores them in a Secret, and the connectionString property resolves to the Secret value at deploy time.
- fromService references: resolved by creating a Kubernetes Service DNS entry and injecting it as an environment variable into the referencing pod. No hard-coded IPs or connection strings in your code or config.