Skip to main content

Deployment & Operations

This section is for platform operators: the team that deploys and runs DynamoAI in your own Kubernetes environment with Helm. If you are looking for product usage documentation, including account access and projects, see Products. Identity, observability, and billing administration are under Platform Administration; standard operating procedures are indexed in Runbooks.

The section is organized as a runbook. A new deployment reads it in order; an existing deployment jumps to the part it needs.

Deployment Path​

Start at the Deployment Runbook. It is the spine of a deployment: nine phases in order, who owns each one, what has to be true before a phase starts, and what proves it finished. Everything below is the detail it links to.

The condensed sequence:

  1. Architecture: understand the install model and how the platform is put together before touching the cluster.
  2. Prepare the environment: verify everything your environment must provide, per cloud, before the deployment window starts.
  3. Deploy: install the platform with Helm.
  4. Validate: run the acceptance checks that prove the platform is operational.

Validation is the handover gate, not the finish line. Connecting a first AI system and its policies is phase 8 of the runbook, and it is the phase customers most often underestimate.

Operating an Existing Deployment​

  • Advanced Configuration: bring-your-own alternatives for platform dependencies, such as an external MongoDB or your own model storage.
  • Upgrades: the general upgrade procedure, plus step-by-step guides for changes tied to a version boundary.
  • Troubleshooting: known failure symptoms across installation and operations, with causes and fixes.

Conventions Used in the Guides​

  • <namespace>: the Kubernetes namespace of your DynamoAI installation.
  • <your-registry>: your internal container registry that mirrors DynamoAI images.
  • Values snippets show the keys to add or change; merge them into your existing values files rather than replacing whole blocks.
  • Every requirement pairs with a verification command you can copy and run.
  • Every upgrade guide ends with a Verification and a Rollback section; read both before starting the rollout.
  • Steps are labelled Required (the platform does not function without it), Conditional (required only in certain environments, with the condition stated alongside), or Optional (skipping it degrades something specific, which is stated alongside). The Deployment Runbook explains the labels in full.