Deploy and operate Koldan

Use this guide to plan, deploy, secure, monitor, scale, back up, and upgrade a Koldan installation on Kubernetes or OpenShift.

Choose a deployment path

Before choosing a path, confirm the platform and dependency requirements and define the production readiness and high-availability design.

Deployment lifecycle

Follow the stages in order for a new environment. For an existing installation, enter at the relevant stage and complete the associated verification before making the change.

1. Plan. Inventory release artifacts, cluster policies, dependencies, storage, DNS, certificates, recovery objectives, and expected capacity. Start with requirements and dependencies and networking.
2. Deploy. Select the supported single-node or cluster capacity profile, add a deployment-owned values file, render and review the manifests, then install the release with Helm.
3. Configure. Establish secret handling, TLS trust, PostgreSQL, Temporal, object storage, identity, and the Koldan license.
4. Validate. Confirm workload readiness, public HTTP and gRPC access, dependency connectivity, authentication, certificate trust, persistent storage, and telemetry collection.
5. Operate. Define the QoS expectations and priorities, then put monitoring and alerts, capacity controls, and tested backups in place before production traffic.
6. Maintain. Rehearse upgrade and rollback, certificate and credential rotation, dependency maintenance, and disaster recovery in a non-production environment.

Keep the Helm chart, container images, values reference, and documentation from the same Koldan release. Record the deployed chart version, image tags, values revision, Helm revision, and dependency versions for every environment.

Production go-live gate

Do not admit production traffic until all of the following are true:

• Every enabled workload is Ready and stable under representative load.
• HTTP and gRPC hostnames resolve from their intended client networks and present complete, trusted certificate chains.
• PostgreSQL, Temporal, S3-compatible storage, and the identity provider have passed connectivity and authentication checks from the Koldan namespace.
• koldan.security.encryption-key and koldan.api.api-keys.hmac-secret are site-specific, non-default, recoverable, and consistent across every consuming replica.
• No placeholder values remain, and deployment-owned files or rendered artifacts containing sensitive data are access-controlled and retained only as required by the deployment process.
• Resource requests, limits, replica counts, failure-domain placement, disruption controls, and backend concurrency are based on measured demand and documented capacity ceilings.
• Dashboards and actionable alerts cover availability, dependency failures, saturation, storage growth, certificate expiry, and backup age.
• Database, object-storage, configuration, identity, and license recovery procedures have been tested together.
• The deployment team has a rollback decision point and access to the previous release artifacts and values.

Use Troubleshooting to diagnose failed readiness or dependency checks.