Requirements and Sizing
Collect the required inputs
Decide on the following before provisioning anything:
- A base domain whose DNS zone you can change.
- A datacenter ID, name, city, and country code.
- Stable private IP addresses for every machine.
- A public IP address for the jumpbox. This is separate from the service addresses and should accept SSH only from trusted administrator networks.
- Three stable, externally reachable service IP addresses: platform gateway, workspace gateway, and workspace SSH proxy.
- GitHub Container Registry credentials supplied by Codesphere. Codesphere nodes
currently pull images directly from
ghcr.io, and customers must request the required username and token from Codesphere. - Access to the Codesphere package portal.
- An initial cluster administrator email, if desired.
- OAuth credentials for each Git provider or OIDC provider that users will use.
- An SSH key with administrative access to all hosts.
Git provider credentials must be supplied as complete sets. For example, a GitHub App needs its app name, client ID, and client secret; an OIDC provider needs its issuer URL, client ID, and client secret.
Minimum supported versions
Codesphere requires:
- Ubuntu 22.04 LTS or a newer supported version
- Kubernetes 1.31 or newer
- Ceph 18.2 or newer
- x86-64 (linux/amd64) hosts
The Kubernetes and Ceph minimums also apply when those components are installed or managed outside OMS.
POC topology
Use this compact topology for proofs of concept, evaluation, and other non-production environments:
| Role | Count | Per machine | Storage | Public IP |
|---|---|---|---|---|
| Jumpbox | 1 | 2 vCPU, 4 GiB RAM | 50 GiB SSD root disk | Yes |
| PostgreSQL | 1 | 2 vCPU, 8 GiB RAM | 200 GiB SSD root disk | Not required |
| Ceph | 3 | 8 vCPU, 32 GiB RAM | 50 GiB SSD root, one 10 GiB DB/WAL disk, and one 250 GiB data disk | No |
| Combined k0s control plane and worker | 3 | 8 vCPU, 32 GiB RAM | 200 GiB SSD root disk | No |
All three k0s nodes participate in the control plane and also provide workload capacity. This topology keeps the machine count low, but it does not provide the same maintenance and failure headroom as the production topology. Do not use it for production workloads.
Production baseline
Use separate control-plane and worker pools in production. Start with:
| Role | Starting count | Per machine | Storage | Public IP |
|---|---|---|---|---|
| Jumpbox | 1 | 2 vCPU, 4 GiB RAM | 50 GiB SSD root disk | Yes |
| PostgreSQL primary | 1 | 2 vCPU, 8 GiB RAM | 200 GiB SSD root disk | No |
| PostgreSQL replica | 1 recommended | 2 vCPU, 8 GiB RAM | 200 GiB SSD root disk | No |
| Ceph | 4 or more | 16 vCPU, 64 GiB RAM | 50 GiB SSD root, one 10 GiB DB/WAL disk, and one or more 500 GiB data disks | No |
| Dedicated k0s control plane | 3 | 4 vCPU, 8 GiB RAM | 50 GiB SSD root disk | No |
| Dedicated k0s worker | 3 or more | 16 vCPU, 64 GiB RAM | 200 GiB SSD root disk | No |
Three control-plane nodes provide control-plane quorum and high availability. Start the separate worker pool with at least three 16-vCPU, 64-GiB machines, then scale it for workload CPU, memory, scheduling headroom, and the number of simultaneous node failures the platform must tolerate. Scale Ceph beyond four nodes and add data disks based on usable-capacity targets, replication overhead, recovery headroom, and growth.
Use 250 GiB Ceph data disks as the POC minimum and 500 GiB data disks as the production minimum. Present Ceph DB/WAL and data disks as distinct, unused block devices; do not format or mount them. For production, validate disk performance and size the DB/WAL device for the selected data devices and workload.
Use dedicated PostgreSQL storage and a replica when database availability is required. The POC topology keeps PostgreSQL on its root disk and has no replica.
Record the hostname and private IP of every host. Hostnames must be unique and
resolvable consistently, either through internal DNS or /etc/hosts.
Next
Continue to Networking, firewalls, and DNS, then Provision the hosts.