Docker
Deploy with a Dockerfile
If your repository contains a Dockerfile, StackBlaze uses it as the authoritative build definition. Your image is built inside an isolated BuildKit pod running in the cluster, no external CI, no Docker daemon on your machine required.
After a successful build the image is pushed to StackBlaze’s private internal registry and deployed as a Kubernetes Deployment behind an Ingress with automatic TLS. Layer caching is preserved between builds so only changed layers are rebuilt, keeping build times fast.
Example, multi-stage Node.js Dockerfile
# ── Stage 1: build ─────────────────────────────────────────
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --frozen-lockfile
COPY . .
RUN npm run build
# ── Stage 2: runtime ───────────────────────────────────────
FROM node:20-alpine AS runner
ENV NODE_ENV=production
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
USER node
CMD ["node", "dist/index.js"]
Build & deploy pipeline
Under the hood
Every Dockerfile build runs inside a dedicated BuildKit pod spun up in the build namespace. The pod has no network access to your workloads and is destroyed after the build completes, ensuring your build environment is hermetically sealed.
- Layer caching: BuildKit mounts a persistent cache volume. Unchanged layers (e.g. npm install) are skipped, cutting build time by 60–80% on subsequent pushes.
- Immutable tags: images are tagged with the Git commit SHA (e.g.
:sha-abc1234). Rolling back is as simple as pointing the Deployment at an earlier tag. - Rolling update strategy: the Kubernetes Deployment uses
maxSurge: 1, maxUnavailable: 0by default. New pods must pass their readiness probe before old pods are terminated. - Private registry:
registry.stackblaze.iois an in-cluster OCI registry. Images never leave the cluster network; pull credentials are injected as imagePullSecrets automatically.
Step by step
Add a Dockerfile to your repo root
StackBlaze looks for a file named exactly Dockerfile (no extension) at the root of your repository. It supports all standard Dockerfile instructions including multi-stage builds, ARG, LABEL, and HEALTHCHECK. Multi-stage builds are strongly recommended, they keep your final image small by separating build-time dependencies from runtime artifacts.
Push to GitHub - auto-detected on connect
When you connect your repository, StackBlaze scans for a Dockerfile and immediately selects the "Docker" service type. No manual configuration needed. If both a Dockerfile and a package.json are present, the Dockerfile takes precedence. You'll see a confirmation in the dashboard before the first build starts.
Configure the exposed port
StackBlaze routes traffic to port 3000 by default. If your server listens on a different port, set the PORT environment variable in the dashboard (Settings → Environment) or hardcode the EXPOSE instruction in your Dockerfile. StackBlaze reads the first EXPOSE declaration and uses it as the container port for the Kubernetes Service.
Every push to main triggers a deploy
A GitHub webhook fires on every push to your configured branch (default: main). StackBlaze queues a BuildKit job, builds the image with layer caching enabled, tags it with the short commit SHA, pushes to the internal registry, then issues a Kubernetes rolling update. Old pods are terminated only after new ones pass their readiness probe.