Gapless

Deployment and Infrastructure

How the assistant is built, deployed, hosted, scaled, and recovered, and what is different about shipping changes to an AI system.

Deploying an AI assistant involves two kinds of change. Code changes behave like in any web service: tests pass or fail. Behavior changes, such as a new prompt version, a different model, a new chunking strategy, or a guardrail threshold, can pass every test and still make answers worse. The deployment process has to handle both.

What gets deployed

ArtifactChanges how oftenDeployed byRollback
Application code (API, orchestrator, workers)DailyCI/CD pipeline, container imagesPrevious image
FrontendDailyCI/CD, static assets on a CDNPrevious build
Prompt templatesWeeklyShipped with code, version selected by configConfig change to the previous version
Model routesMonthlyConfig changeConfig change
Guardrail settingsAs neededConfig changeConfig change
InfrastructureWeeklyInfrastructure as code pipelineRevert and apply
Index (pipeline version, embedding model)RarelyMigration jobs, new index plus switchSwitch back to the old index
Self-hosted model weightsRarelyModel serving deploymentPrevious deployment

The key design choice: behavior is selected by configuration at runtime, so prompt versions, model routes, and guardrail settings can be rolled out gradually and rolled back in seconds without a code deploy.

The design

Pages in this section

PageCovers
Environments and CI/CDEnvironments, pipeline stages, what runs where, secrets per environment
InfrastructureInfrastructure as code, compute, scaling, and hosting models
RolloutsReleasing prompt, model, and retrieval changes safely, with canaries, flags, and rollback
Disaster recoveryRegional failure, provider failure, recovery plan, and drills

On this page