Kubernetes

We ship a Compose stack, not a Helm chart or Kubernetes manifests. The deploy bundle in your release is the supported, tested configuration. If you run ObjectOS on Kubernetes, you are assembling the manifests yourself — so this page states the properties that stack has, each of which the runtime either depends on or enforces. Reproduce the properties; the YAML around them is yours.

Everything on Docker applies unchanged: same image, same licence rules, same cloud posture rules. Nothing about the orchestrator changes what the deployment is entitled to.

Properties to preserve

The image is pinned by digest

Reference the image by @sha256: digest in the pod spec, not by tag. On an orchestrator this matters more than on a single host: an image pull policy plus a moving tag means two replicas of the "same" deployment can be running different builds. Pulling needs a pull secret holding your licensed registry credentials.

Migrations run once, to completion, before replicas serve

The Compose stack runs a one-shot migration container that must finish before any application replica starts. On Kubernetes that is a Job (or an equivalent pre-serve hook), not an init container on every replica — the point is that schema changes run once, not once per replica in parallel. The image supports a migrate-and-exit mode for exactly this; the bundle names the variable.

Probes address the right endpoints

/api/v1/ready is readiness. /api/v1/health is liveness. They answer different questions, and using one for both means either routing traffic at a replica that is not ready, or restarting a replica that is merely busy.

Since ObjectStack 17.0 readiness is backed by the data layer: /api/v1/ready answers 503 when a data driver stops answering, so a readiness probe pointed at it will correctly pull a replica out of the Service endpoints when its database goes away. Keep it off the liveness probe for exactly that reason — a shared database outage would otherwise restart every replica at once instead of draining traffic.

Every replica gets identical secrets

Multi-replica is not a matter of raising the replica count:

• The cluster driver must be on, backed by Redis.
• A shared secret key becomes mandatory. Without a cluster driver each replica mints its own; across replicas those would diverge, and rather than diverge, the runtime refuses to start. One value, mounted into every replica.
• The auth secret must likewise be identical across replicas.

So the secret material belongs in a Secret mounted identically by every pod — never generated per pod, never templated from a pod-unique value.

Licence and cloud posture are deployment-wide

The licence key, the licence mode, and the cloud-posture setting are part of the deployment's identity. They must be the same in every replica, and their supported combinations are checked at startup — a mismatched pod does not run degraded, it exits. See Air-gapped for the combinations.

Multi-node and high availability are Enterprise capabilities — see License & Pricing.

Business data lives outside the cluster

Point the deployment at a managed PostgreSQL (and Redis). Persistent volumes inside the cluster are not the intended home for business data.

Rolling upgrades change the digest

Upgrading is a change of image digest, with the migration Job running to completion before the new replicas serve. Schema migrations are forward-only: rolling the image back does not roll the schema back, so take a backup first and keep the previous digest to roll back to. The app itself, when it is delivered as a published artifact, versions independently of the image — see the run shapes on Deployment.

Ingress

Terminate TLS at the edge. Configure CORS explicitly for the front-end origins you serve; do not combine wildcard origins with credentialed requests. When the runtime sits behind a proxy, make sure the proxy replaces any client-supplied forwarded-for header with its own — rate limiting and audit trails depend on the caller identity being trustworthy.