Deployment and operations

Stigg owns the operational model for your BYOC environment. You do not need to manage infrastructure upgrades, service deployments, or configuration drift — Stigg handles these through the same IaC pipeline used to provision your environment.

​

Infrastructure as code

All BYOC infrastructure is defined in IaC templates managed in Stigg’s internal Git repository. Every change — whether a new configuration value, a DB version upgrade, or a new service component — goes through:

1. A code change to the IaC template
2. Review and merge in Stigg’s internal repo
3. Deployment to your environment via the CD pipeline

This approach ensures all environments (across different BYOC customers) stay consistent and that changes are auditable and reversible.

​

Infrastructure upgrades

Stigg manages all infra-level upgrades, including:

• Database engine version upgrades
• Compute instance type changes
• Storage capacity expansions
• Networking configuration changes

Stigg coordinates with you before applying upgrades that require maintenance windows or that could temporarily affect availability.

​

Continuous deployment of Stigg services

New versions of Stigg services are deployed into your environment through a continuous deployment pipeline operated by Stigg. Deployments follow a rollout strategy designed to avoid availability impact:

• Canary or blue/green rollout where the service supports it
• Automatic rollback if health checks fail after deployment
• Stigg monitors your environment during and after each rollout

​

Operational responsibilities

​

Incident response

When an issue is detected in your BYOC environment, Stigg’s on-call team can access observability data (health checks, logs, metrics) from your environment to diagnose and resolve it. See Observability and debugging for details on how Stigg retrieves this data.