Kubernetes is not an operating system distribution. It orchestrates container workloads across cluster resources. SodaOS combines a Linux appliance with a development workflow. The practical choice is an integrated factory or a Kubernetes-based platform whose factory services your team selects and operates.
What Kubernetes contributes
Kubernetes offers workload controllers, scheduling, services and storage integration. Jobs can run tasks to completion and apply configured retry behavior. These are useful primitives for coding, testing or evaluation workloads. A completed Job still does not prove that a change meets its requirements, has current review or is authorized to merge.
The application above the cluster must interpret repository state, manage agent inputs and credentials, publish candidates and enforce development policy. Restarting a process is not always a safe retry of an external Git or forge operation; the factory must account for what already happened.
| Concern | SodaOS | Kubernetes-based platform |
|---|---|---|
| Workflow ownership | Integrated factory coordinator and Forgejo authority | Select/build controllers and forge integration |
| Capacity | One operator-managed appliance and bounded concurrency | Multi-node placement and capacity policies you configure |
| Persistence | Retained Projects and their tools/services | Persistent volumes, stateful workloads and workspace lifecycle design |
| Human intervention | Spaces, native forge and project access | Select/build the operator and developer interfaces |
| Failure handling | Recorded attempts, runs and uncertain outcomes | Cluster recovery plus application-aware reconciliation |
| Operating scope | Appliance updates, access, backups, provider accounts | Cluster lifecycle, networking, storage, policy and factory services |
When a cluster is justified
Kubernetes is a strong candidate when your organization already has a capable platform team, needs many nodes or heterogeneous worker pools, or requires integration with established cluster policy and deployment systems. Reusing a maintained cluster can be easier than introducing an appliance. Kubernetes does not inherently imply unnecessary complexity; that depends on what your team already operates.
SodaOS fits a team that wants a dedicated factory without first designing a cluster platform and the development workflow above it. It does not promise Kubernetes-compatible scheduling, automatic horizontal scale or high availability. Several Projects on one appliance remain subject to the same host capacity and failure domain.
Isolation and credentials
Kubernetes's multi-tenancy guidance distinguishes tenancy approaches and the controls needed to isolate workloads. A namespace alone is not a complete hostile-tenant security boundary. Runtime isolation, node placement, network policy, storage access and privileges all matter.
SodaOS Projects share the host kernel and are intended for a trusted team. If you need hostile-code execution, choose a boundary designed for that purpose rather than equating either a Project or a Pod with a virtual machine. In both designs, separate provider sponsorship from repository write permissions and keep merge authorization outside arbitrary agent-generated instructions.
A useful comparison exercise
Use one repository and the same accepted objective on each proposed platform. Trace environment preparation, agent access, PR publication, a failed check, a corrected candidate, required human approval and confirmed merge. Include cancellation and a provider interruption. Record operational steps and artifacts; do not compare only process start times.
The review and approval guide describes that development exercise. The custom-platform guide lists the application integration responsibilities, and Talos vs SodaOS separates cluster OS selection from the factory decision.