Skip to main content

​
Deployment model

Runtime services are containerized and deployed with Helm. Service configuration is organized by environment:
Shared Helm templates are in devops/helm-charts/services/templates/:
  • deployment.yaml
  • service.yaml
  • cronjob.yaml
  • keda-scaledobject.yaml
The values tree contains service-specific releases such as Atlas, Compass, Dermadesk, Estimo, Gearbox processes, Hodor, Konsilo, Medusa components, Mint, Notify, Orderbox API/worker/cronjobs, Reflekt, Sesh, Storehouse API/worker, Tetris, and Vector API/worker.

​
Operational dependencies

ConcernPlatform evidence
SecretsAWS Secrets and CSI driver configuration
AutoscalingKEDA ScaledObject templates/configuration
Metrics and tracingDatadog, Prometheus, and Grafana chart configuration
LogsLoki/Alloy configuration
Database connection poolingPgBouncer chart/configuration
Progressive/traffic operationsArgo CD and Terraform/traffic-split scripts

​
Release checklist

  1. Confirm the service’s active code branch and the intended environment values file.
  2. Review required secrets and new configuration keys; never introduce plaintext credentials in Helm values.
  3. Verify database migration ownership and backwards compatibility.
  4. For async changes, provision queues/DLQs, retry policy, dashboards, and alerting before enabling producers.
  5. Validate readiness/liveness and autoscaling settings for API and worker processes independently.
  6. Confirm observability tags and correlation IDs are emitted for cross-service requests/events.
  7. Use a staged rollout and preserve an explicit rollback target.

​
Incident triage order

For a customer transaction issue, inspect in this order: Hodor/session context → Vector/Dermadesk request → Medusa cart/order → Mint gateway/callback → Orderbox worker/events → Storehouse reservation → Notify delivery. Use the correlation identifiers propagated by the participating services rather than timestamps alone.