Kubernetes

There is no Helm chart and no official manifest set. The image works unchanged on Kubernetes, so this page gives a minimal reference and the properties your manifests must preserve — each one is something the runtime either depends on or enforces. Everything on Docker applies: the same image, the same variables, the same upgrade rules.

A reference Deployment

One replica of the Community image, secrets from a Secret, each probe on its own endpoint:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: objectos
spec:
  replicas: 1
  selector:
    matchLabels: { app: objectos }
  template:
    metadata:
      labels: { app: objectos }
    spec:
      containers:
        - name: objectos
          image: registry.example.com/crm:2.2.2   # your image FROM ghcr.io/objectstack-ai/objectstack:X.Y.Z
          ports:
            - containerPort: 8080
          envFrom:
            - secretRef:
                name: objectos-secrets   # OS_DATABASE_URL, OS_AUTH_SECRET, OS_SECRET_KEY
          livenessProbe:
            httpGet: { path: /api/v1/health, port: 8080 }
            periodSeconds: 30
          readinessProbe:
            httpGet: { path: /api/v1/ready, port: 8080 }
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: objectos
spec:
  selector: { app: objectos }
  ports:
    - port: 80
      targetPort: 8080

Properties to preserve

The image is pinned exactly

Reference the image by its @sha256: digest, with the exact version it was read from written beside it, and never by a rolling tag. On an orchestrator this matters more than on a single host: a pull policy plus a tag that moves means two pods of the "same" Deployment can run different builds. A rolling tag moves with every release, and an exact version tag moves too when that version is rebuilt; see Docker → Pin the image.

Probes address the right endpoints

/api/v1/health is liveness. /api/v1/ready is readiness. Readiness answers 503 while the runtime is booting, while it shuts down, and whenever a data driver stops answering — so rolling restarts drain cleanly, and a pod that lost its database leaves the Service endpoints instead of serving errors.

Keep readiness off the liveness probe. A database outage would otherwise restart every pod at once, which cannot bring the database back, and a configuration fault would show up as CrashLoopBackOff instead of the fault itself. Pods recover on their own when the database returns: the readiness probe drains them while it is away and re-admits them afterwards.

Secrets come from a Secret

OS_AUTH_SECRET and OS_SECRET_KEY belong in a Secret, generated once and mounted by every pod — never generated per pod, never baked into the image. A pod that mints its own secret key loses it on the next reschedule, and every secret encrypted under it with it.

Business data lives outside the cluster

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

One replica on Community

Coordination on Community is in-process, so keep replicas: 1. Declaring more (OS_CLUSTER_REPLICAS above 1) refuses the boot without a license. Multi-node is an Enterprise license capability, and the Enterprise kit runs a single replica today — below.

Ingress

Terminate TLS at the edge, and set OS_AUTH_URL and OS_TRUSTED_ORIGINS to the public address. List cross-origin front ends explicitly in OS_CORS_ORIGIN; never 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.

Enterprise adds

We ship a Compose stack, not a Helm chart or Kubernetes manifests. The deploy bundle in your release is the supported, tested configuration. On Kubernetes you are assembling the manifests yourself, so reproduce these properties of that stack too. Nothing about the orchestrator changes what the deployment is entitled to.

The image is pinned by digest

Reference the Enterprise image by @sha256: digest in the pod spec. 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.

Every replica gets identical secrets

Keep the Enterprise kit at one replica today. It wires no cluster driver, and declaring more than one (OS_CLUSTER_REPLICAS above 1) refuses the boot by design: the in-process coordinator would not share locks, counters or pub/sub between replicas. Multi-node is activated by license contract (maxNodes) and is not a high-availability promise; contact sales if you need it. Whatever the replica count:

• Use one shared secret key (OS_SECRET_KEY). Without it each replica would mint its own, and those would diverge.
• The auth secret must likewise be identical wherever the runtime runs.

License and cloud posture are deployment-wide

The license key, the license 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.

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.