Define your stack with Blueprint
A Blueprint is a declarative definition of an app and the managed add-ons it needs, written as code. You never hand-write Kubernetes: pick a ready-made Blueprint from the template catalog, or export your own app as a manifest and commit it alongside your code.
Blueprints are ideal for teams. Infrastructure changes go through code review just like application changes, and anyone can spin up an identical, fully wired environment from a single file. 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.
blueprint.yaml example
# One app: a web process + a background worker
name: my-api
image:
repository: my-org/my-api
tag: latest
web: { replicas: 2 }
worker: { replicas: 1 }
envVars:
- name: NODE_ENV
value: production
volumes:
- mountPath: /data
size: 5Gi
# Attached managed add-ons, wired in automatically
addons:
- type: postgresql
plan: standard
- type: redis
plan: standard
Blueprint deploy flow
Step by step
Start from a template or your own manifest
A Blueprint is a declarative definition of an app and the add-ons it needs. Pick a ready-made Blueprint from the template catalog, or export any app you have already configured as a Blueprint manifest to reuse it.
Pick Standard or High availability
Catalog Blueprints ship in two flavours: Standard runs a single instance of the app and its add-ons, High availability runs replicated, failover-ready instances. Choose the flavour that matches the environment you are deploying to.
Commit the manifest to version control
A Blueprint manifest is your environment's single source of truth. Commit it alongside your application code so infrastructure changes go through code review just like app changes, and reviewers can see exactly what will be added or modified.
Deploy, the app and add-ons come up wired together
When you deploy a Blueprint, StackBlaze creates the app and provisions every attached add-on in one operation. Connection strings are injected into the app as environment variables automatically, no manual linking, no hard-coded credentials.
Reuse it for identical environments
Point the same Blueprint at staging and production, or hand it to a teammate. Everyone gets an identical, fully wired environment from one file, no tribal knowledge required.
Add-ons wire themselves in
Every add-on you attach in a Blueprint publishes its connection details to the app as environment variables at deploy time. You never hard-code a hostname or credential, and rotating them updates the app automatically.
# From the postgresql add-on
DATABASE_URL=postgresql://user:***@my-api-postgres:5432/app
# From the redis add-on
REDIS_URL=redis://my-api-redis:6379
Under the hood
When you deploy a Blueprint, StackBlaze reads the manifest and creates everything it describes in one operation. The app and its add-ons share a single private network scoped to your project.
- web process: gets a public HTTPS endpoint with an automatically provisioned TLS certificate, reachable as soon as the first deploy is healthy.
- worker process: runs privately with no public endpoint, and can reach other apps and add-ons by their internal service name.
- managed add-ons: each is provisioned as its own dedicated instance with persistent storage. Credentials are generated and stored securely, never in your manifest.
- automatic wiring: each add-on's connection string is injected into the app as an environment variable at deploy time. No hard-coded IPs or credentials in your code or config.