# Clusters
> Two cluster shapes. Starter (K3s on one AWS instance) for cheap, Production (managed EKS) for scale. Run both in the same organization.
A cluster is the unit of infrastructure you deploy onto. Ownkube supports two shapes: **Starter** ([K3s](https://github.com/k3s-io/k3s) on one AWS instance), and **Production** (managed [EKS](https://aws.amazon.com/eks/), highly available across availability zones). Both run inside your own AWS account on upstream [Kubernetes](https://kubernetes.io/).
## Choosing a cluster shape
- [Starter (K3s)](#starter-k3s)
- [Production (managed EKS)](#production-eks)
### Quick decision guide
| You want… | Pick |
|---|---|
| The cheapest way onto Ownkube | **Starter** |
| A dev or staging environment | **Starter** |
| A side project that runs unlimited apps on one AWS instance | **Starter** |
| High availability across availability zones | **Production** |
| Autoscaling from 1 to 100+ nodes | **Production** |
| Isolated production workloads | **Production** |
| To start small and add Production later | **Starter first**, then add Production |
You can run both at the same time in the same organization. Dev workloads on Starter, production on Production.
## Starter (K3s)
A single EC2 instance running lightweight Kubernetes. One node runs every app, worker, and database you deploy to it. **Free** Ownkube platform fee, you only pay AWS for the EC2 instance.
### What you get
- One EC2 instance (you pick the size) with a public IP
- 50 GiB of gp3 storage
- Automatic TLS and a load-balanced public hostname per web deployment
- One-click Postgres (single instance, local storage)
- All your apps, workers, and jobs on the same node
### Instance options
| Instance | vCPU | Memory | Rough EC2 cost | Comfortably runs | Typical use |
|---|---|---|---|---|---|
| `t3.medium` | 2 | 4 GiB | ~\$30 / mo | 1-2 apps + 1 small db | First app, low-traffic side project |
| `t3.large` | 2 | 8 GiB | ~\$60 / mo | 2-3 apps + 1 db | Small production web + Postgres |
| `t3.xlarge` | 4 | 16 GiB | ~\$120 / mo | 4-6 apps + 1-2 dbs | Multi-service workloads |
| `t3.2xlarge` | 8 | 32 GiB | ~\$240 / mo | 8-12 apps + 2-3 dbs | Busy multi-app node |
No Ownkube platform fee on top, you pay AWS only. AWS Activate and other startup credits cover these EC2 costs in full. "Apps" assumes typical web or worker sizing; heavier workloads will fit fewer per node.
### Create a K3s cluster
Open the create-cluster wizard from your [dashboard](https://app.ownkube.io/dashboard) and select **Deploy on EC2**. See [Create a cluster](/docs/guides/create-cluster) for the walkthrough.
## Production (EKS)
Managed Kubernetes, highly available across availability zones. Ownkube provisions a VPC, subnets, the EKS control plane, and a workload node group that autoscales based on load.
### What you get
- Managed Kubernetes control plane ([AWS-managed](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html), highly available across availability zones)
- Workload node autoscaling. Grows to fit your deployments, shrinks when idle.
- Managed Postgres with backups, scheduled snapshots, and connection pooling
- Load balancing and automatic TLS for public deployments
- Platform upgrades you can roll out on your schedule
### Pricing
Metered on your deployments' **requested** vCPU and memory, not the nodes themselves.
- **\$5 / vCPU / month** (requested)
- **\$1 / GB RAM / month** (requested)
- Pro-rated per second, billed from the first second
AWS charges you directly for the underlying compute (control plane, EC2 workloads, NAT gateway, etc.) at their standard rates. No markup from Ownkube.
### Sizing
In the **Compute** step of the create-cluster wizard you pick a starting capacity:
- **Workload vCPUs**, 2 to 128, default 8
- **Memory**, 4 to 256 GiB, default 16
These are starting sizes. The node pool autoscales up and down as your deployments grow. You can change the floor from the cluster's detail page at any time.
### Region and Kubernetes version
- **Region**, any of the 17 supported [AWS regions](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) (us-east-1/2, us-west-1/2, eu-west-1/2/3, eu-central-1, eu-north-1, ap-south-1, ap-southeast-1/2, ap-northeast-1/2/3, sa-east-1, ca-central-1)
- **Kubernetes version**, pick from 1.35, 1.34, or 1.33 at creation time (see the [upstream release schedule](https://kubernetes.io/releases/))
### Create an EKS cluster
Open the create-cluster wizard from your [dashboard](https://app.ownkube.io/dashboard) and select **Deploy on EKS**. See [Create a cluster](/docs/guides/create-cluster) for the walkthrough.
## The cluster detail page
Every cluster has a detail page in your [dashboard](https://app.ownkube.io/dashboard) with three tabs.
### Overview
Live status, uptime, region, Kubernetes version, deployment count, and telemetry (nodes, vCPU, memory). If there are no deployments yet, a **Deploy a sample app** nudge appears here.
### Registries
Container registries connected at the organization level, with per-cluster status.
### Settings
Compute (EKS only)
Current workload capacity, last-synced timestamp, and a **Reconcile** button that re-syncs actual capacity from the cluster. A warning shows if the data is more than 15 minutes stale.
Networking
VPC ID, pods CIDR, and services CIDR. What you chose at creation time.
Cluster platform version
Upgrade the cluster's platform version to a newer release. The dropdown only shows versions newer than what you're running. Downgrades aren't supported because platform migrations are forward-only. See [Platform upgrades](#platform-upgrades) below.
Health check
Last health-check timestamp and status, with a **Validate** button that checks for configuration drift.
Danger zone
**Destroy cluster** permanently removes everything. Blocked if active deployments exist; you have to delete the deployments first. There's a name-confirm prompt to prevent mis-clicks.
## Platform upgrades
Ownkube ships a **Cluster platform version** that keeps your cluster and workloads current. It covers the cluster-wide system components (ingress, TLS, metrics, networking).
When a new version ships, you see it in the UI on the cluster detail page. Apply the upgrade from there on your own schedule.
**Keep up to date.** Staying on the latest platform versions is how you get new features as they ship. We'll let you know in-app when a new version is available and what changed.
Upgrades are designed so they don't affect deployment quality. Rollouts are gradual and drain-safe, and we test upgrade paths before they reach your cluster. If an upgrade does misbehave, it will not take your workloads down with it.
- [Create a cluster](/docs/guides/create-cluster)
- [Deployments](/docs/features/deployments)
---
**Don't see a feature you need?** Email [support@ownkube.io](mailto:support@ownkube.io?subject=Feature%20request). Ownkube is shaped by the teams using it and we ship what our users ask for.