Deployment Runbook

This page is the spine of a DynamoAI deployment. It states the phases in order, who owns each one, what has to be true before a phase starts, and what proves it finished. Every phase links to the detail pages; nothing here is duplicated from them.

Use it to plan the engagement, to brief a change board, and to track progress during the deployment window.

How Steps Are Labelled

Throughout the operator documentation, each step carries one of three labels:

Label	Meaning
Required	The platform does not function without it.
Conditional	Required only in certain environments. The condition is always stated with the step, for example "only if DynamoGuard is licensed" or "not on OpenShift".
Optional	A capability or convenience. Skipping it degrades something specific, which is stated with the step.

Read Conditional carefully before sourcing infrastructure. A deployment without DynamoGuard needs no GPU capacity at all, and a deployment that never invites users by email needs no SMTP relay.

Ownership

DynamoAI does not provision or operate your cloud environment. The split is fixed:

Area	Owner
Cloud account, network, Kubernetes cluster, managed datastores, DNS, certificates	Customer
Charts, container images, model weights, licence, values interface, deployment engineering	DynamoAI
Identity provider configuration, corporate SSO, mail relay	Customer, with DynamoAI guidance
Installation, validation, and troubleshooting during the deployment window	Joint
Ongoing operation, monitoring, upgrades, capacity	Customer, with DynamoAI support

Cluster provisioning is deliberately not documented as a procedure. Managed Kubernetes changes faster than documentation can track, and every organization provisions through its own approved tooling. What is documented instead is the target state your cluster must reach and the command that verifies it, which is the part a runbook actually needs.

Phases

Phase 1: Scope

Owner: Joint · Required

Establish which products are licensed, because that determines the infrastructure. DynamoGuard, DynamoEval, or both.

Entry criteria	Exit criteria
Commercial agreement in place	Licensed products confirmed in writing; target cloud and region chosen; expected workload sized against Resource Guidelines

Read Platform Architecture before anything else; the rest of the runbook assumes that mental model.

Phase 2: Provision the Environment

Owner: Customer · Required

Bring the cluster and its supporting services to the state the platform expects. The Environment Dependencies registry is the contract: every row states the requirement, why it exists, and how to verify it. Cloud specifics are on the AWS, Azure, and GCP pages, each ending with an exportable pre-deployment checklist.

Entry criteria	Exit criteria
Phase 1 complete	Every row in the registry verified; the per-cloud checklist complete and exported for the record

The dependencies that most often stall a deployment, in order: PostgreSQL missing the pg_partman or vector extension, GPU quota not granted in the target region, and deployment engineer access not working end to end. Verify all three early rather than in the deployment window.

Phase 3: Artifact Access

Owner: Joint · Required

The cluster must be able to obtain charts, container images, and model weights. Either allow-list artifacts.dynamo.ai or mirror its contents into your own registry; regulated environments normally mirror.

Entry criteria	Exit criteria
Phase 2 complete	A test chart pull, image pull, and model fetch each succeed from inside the cluster

Phase 4: Install

Owner: Joint · Required

Install dynamoai-base first, then the product charts your licence covers. Full procedure, configuration variables, and the Kubernetes Secrets the charts expect are on the Deploy page.

Entry criteria	Exit criteria
Phases 2 and 3 complete; Secrets created; values files prepared	All pods Running and Ready; the UI reachable over its domain; first sign-in succeeds

Cluster-level dependencies (NVIDIA device plugin, ingress controller, KEDA, Prometheus, OpenTelemetry) are installed in this phase if your cluster does not already provide them. Their required, conditional, and optional status is stated on the Deploy page.

Phase 5: Connect Identity

Owner: Customer, with DynamoAI guidance, Optional, strongly recommended

The platform is usable on its bundled Keycloak with local accounts, which is why this phase is not marked Required. No production deployment should stop there: without federation, access does not follow your joiner, mover and leaver process, and the administrator account is a shared credential.

Entry criteria	Exit criteria
Phase 4 complete; IdP application registration approved	Users sign in through your corporate IdP; their directory group membership resolves to platform roles; the local admin account is no longer the route to Keycloak administration

New to the identity guides? IAM Overview indexes all of them. Work through these in order. Each one states its own verification.

Step	Page	Status
1	Keycloak SSO	Required
2	Entra ID as IdP, or Keycloak as IdP for any other OIDC provider	Required
3	Adding Mappers	Required
4	Default IdP Redirect	Optional
5	Keycloak Web Console via Entra ID, or the generic IdP version	Recommended
6	Storing the OIDC Client Secret via Vault	Optional

Read these two before you start rather than after. Entra ID Groups Claim Overage explains why users in many directory groups silently lose their group claim, and Troubleshooting IdP Logins maps the remaining symptoms back to causes that the error text does not reveal.

Verify roles from the platform, not the Keycloak console

A federated user holding no org-level role receives a server error rather than a restricted interface, so the first sign of a mapping failure looks like an outage. Confirm what the platform resolved before declaring this phase complete:

Read a user's effective org-level roles

curl -s -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://api.<domain>/v1/user/all?includeOrgLevelRoles=true" \
  | jq '.users[] | {email, orgLevelRoles}'

Phase 6: Configure Access

Owner: Customer, Required

Decide who can do what, then grant it. Read Understanding Access and Roles for the model, and Scopes and Roles for the complete role to scope mapping. User Management covers day-to-day administration.

Entry criteria	Exit criteria
Phase 4 complete; Phase 5 complete if federating	Roles assigned and verified from the platform; DynamoGuard activated for every user who needs it; a non-administrator has signed in, reached the Policies tab and created a policy

Step	Status	Notes
Assign org-level roles	Required	Grant through IdP mappers where federating, so the directory stays the source of truth. developer covers a user's own authoring work; admin is only for managing other people's resources.
Activate DynamoGuard per user	Required, where DynamoGuard is licensed	The only onboarding step no role or group mapper can perform. Without it a user signs in and finds no Policies tab.
Plan resource sharing	Required where users collaborate	An administrator sees every resource; everyone else sees only what they own or what is shared with them. There is no team tier.
SMTP Integration	Conditional	Required if you invite users by email, because invitations and password resets are sent through it. Not needed if all access arrives through your IdP.

Correct roles do not imply working access

Role assignment and DynamoGuard activation are independent, and each fails in a way that looks like the other. A user may hold the right roles and still see no Policies tab, or be activated and still be denied on save. Verify both against a real non-administrator account before handover rather than inferring either from the Keycloak console.

Phase 7: Validate

Owner: Joint · Required

Prove the platform works, not just that it started. Deployment Validation runs four functional scenarios across both products with per-step sign-off, and the checklist state exports as Markdown for your handover record.

Entry criteria	Exit criteria
Phases 4 and 6 complete	Every scenario for every licensed product passes; the completed checklist exported and attached to the deployment record

This is the handover gate. Do not open the environment to product teams before it passes.

Phase 8: Onboard the First Workload

Owner: Customer, with DynamoAI support · Required to realize value

A validated platform guards nothing until an AI system is connected to it. This is the phase customers most often underestimate, because it is product work rather than infrastructure work and usually involves a different team.

DynamoGuard:

1. Create an AI system representing the application to be guarded.
2. Create policies: start from the foundation guardrails, then add a custom content policy where your requirements are organization-specific.
3. Integrate DynamoGuard into the request path.
4. Tune thresholds against your traffic before enforcing.

DynamoEval:

1. Run a jailbreak test against a target model.
2. Run a system policy compliance test.
3. Connect your own systems through the custom systems integration where the target is not a standard provider.

Entry criteria	Exit criteria
Phase 7 complete	One real workload guarded or evaluated end to end, with results reviewed by the team that owns it

Phase 9: Operate

Owner: Customer, with DynamoAI support · Required

Area	Status	Where
Logging	Required	Logging
Metrics and dashboards	Required	Metrics
Health monitoring	Required	Health Status
Event handling	Optional	Event Handling
Third-party observability integration	Optional	Third Party Integrations
Upgrades	Required, ongoing	Upgrades
High availability and disaster recovery	Conditional on your availability commitment	Reliability
Paired-region deployment	Optional	Paired Regions

Agree monitoring thresholds and an upgrade cadence before handover rather than after the first incident.

Deployment Summary

Phase	Owner	Status
1. Scope	Joint	Required
2. Provision the environment	Customer	Required
3. Artifact access	Joint	Required
4. Install	Joint	Required
5. Connect identity	Customer	Optional, strongly recommended
6. Configure access	Customer	Required
7. Validate	Joint	Required
8. Onboard the first workload	Customer	Required to realize value
9. Operate	Customer	Required, ongoing

Phases 1 to 3 are preparation and can run in parallel with commercial work. Phases 4 to 7 are the deployment window itself. Phases 8 and 9 continue after handover.