Configure the cloud around Orbita.

These practices make evaluation deployments representative. They do not turn the current pre-1.0 system into a production-ready service.

Isolate peer traffic

Expose client and Admin gRPC on 7100. Keep peer port 7101 private to the cluster network. Peer framing is versioned and currently unauthenticated.

Use workload identity

Prefer cloud workload identity over static object-store keys: IRSA or Pod Identity on EKS, task roles on ECS, and instance profiles only when pod-level identity is unavailable. Scope access to the Orbita bucket.

Spread failure domains

Place the three voters across separate nodes and availability zones. Keep the voter target independent from worker count so adding compute does not enlarge the consensus quorum.

Preserve local WAL state

Every node needs persistent local storage for acknowledged writes that have not flushed to object storage. Use predictable latency storage and retain the node data directory across restarts.

Treat object storage as shared infrastructure

All nodes must use the same bucket and compatible endpoint settings. AWS S3 normally uses virtual-host addressing; MinIO and R2 commonly require path-style access.

Keep the current boundaries visible

Orbita does not yet provide built-in TLS, peer mTLS, backup/restore tooling, an audit log, or encryption at rest. Put evaluation endpoints behind trusted networking and do not store irreplaceable production state.

The EKS test setup is documented in docs/TESTING-ON-EKS.md.