Small production environment offers a production-ready setup optimized for moderate throughput — two runtime containers per codebase on shared CPU keep rolling deploys zero-downtime, managed services stay single-instance with snapshot backups.
Knowledge Base
Node.jsapi
zerops-recipe-apps/nestjs-showcase-apiObject-storage runs on a MinIO backend
The data plane (PutObject, GetObject, ListObjectsV2, multipart uploads, pre-signed URLs) is S3-compatible end-to-end. Control-plane and AWS-only features aren't on the managed backend: no archival tiers (Glacier, Deep Archive), no Object Lock / WORM, no lifecycle rules, no S3 Select or Inventory, no Transfer Acceleration, no CloudFront integration. Adapting this recipe to a product that needs any of those means planning a separate AWS S3 tier alongside; the rest of the recipe stays intact.
Staticapp
zerops-recipe-apps/nestjs-showcase-app
${API_URL} resolves at project create, not on subdomain rotation
The project-scope API_URL / FRONTEND_URL constants compose from ${zeropsSubdomainHost} once at provision time and don't auto-track if you later swap apistage for a custom domain. The SPA bakes VITE_API_URL: ${API_URL} at build time, so swapping the api origin means updating API_URL in the Zerops UI's project envs AND redeploying prod so a fresh build picks up the new value. Dev is exempt — Vite is long-lived, so a VITE_API_URL change plus a Vite restart is enough.
base: static is Nginx — no Node at request time
The app ships a compiled Vite bundle to an Nginx-backed runtime: ~2 MB RAM per replica, SPA fallback built in. Anything that needs request-time code — server-rendered routes (Next.js / Nuxt server components), dynamic redirects, edge functions, BFF endpoints — requires switching to base: nodejs@22 with an explicit start: and the runtime cost balloons to ~80 MB per replica. If your product is hybrid SSR/SPA, plan the runtime model up front rather than as an afterthought.
Node.jsworker
zerops-recipe-apps/nestjs-showcase-workerMeilisearch is single-node across every tier
The recipe ships mode: NON_HA for the search service on every tier, including HA Production — Zerops's managed Meilisearch is single-node with vertical autoscaling. Production scaling is bounded by the per-instance heap; horizontal sharding isn't a one-yaml-edit upgrade. If your index will grow past ~10M documents or query QPS spikes past single-node throughput, plan a vertical bump (verticalAutoscaling.minRam in zerops.yaml) before the ceiling, or budget for an external search service.
Each DDL-owning codebase needs its own execOnce migrator key
The recipe scopes api and worker migrations under separate ${appVersionId}-api-migrate and ${appVersionId}-worker-migrate execOnce keys so they don't contend on a shared lock. If you add a third codebase that issues DDL on the same database, give it its own role-suffixed key (${appVersionId}-<codebase>-migrate) — sharing the api or worker key burns the per-deploy gate for whichever migrator loses the race.
