Pilot deployment options¶
This guide shows how to pilot deployment options in a reliable, repeatable way.
Who this is for¶
- Developers and platform engineers planning a pilot environment.
- Buyers who want to understand what “running it” entails.
What you will get¶
- A concrete set of pilot deployment shapes
- What each option proves (and what it doesn’t)
- A recommended progression from pilot to production
Option A: Local / developer sandbox (fastest)¶
Use when you want to prove:
- API integration and request/response semantics
- Tenancy isolation and headers/claims handling
- Exposure log creation for later evaluation
Start with:
Option B: Single-tenant pilot environment (staging)¶
Use when you want to prove:
- End-to-end integration from your app to RecSys in a networked environment
- Observability, basic SRE runbooks, and rollback procedures
- A real(istic) traffic shadow or small production slice
Recommended building blocks:
- Deploy serving: Deploy with Helm (production-ish)
- Ops checklist: Production readiness checklist (RecSys suite)
Option C: Production-like (artifacts + manifest + scheduled pipelines)¶
Use when you want to prove:
- Daily refresh of signals with guardrails
- Atomic publish/rollback and freshness SLOs
- A repeatable evaluation workflow
Start with:
- Production-like tutorial: production-like run (pipelines → object store → ship/rollback)
- Pipelines daily operation: How-to: operate recsys-pipelines
Recommended progression¶
- Local sandbox → proves integration semantics cheaply.
- Staging pilot → proves ops readiness with real integration constraints.
- Production-like → proves long-term operating model (pipelines, ship/rollback, evaluation).
Read next¶
- Pilot plan: Pilot plan (2–6 weeks)
- Data modes: Data modes: DB-only vs artifact/manifest
- Reliability & rollback: Operational reliability and rollback