Cluster requirements

Anyport runs on any Kubernetes cluster. Most things work everywhere — apps, domains, builds, secrets and routing need nothing special.

Every row below says what breaks, not just what is needed. A requirements list that doesn't say what happens when you ignore it is a list people ignore.

CPU and memory#

Minimum: 2 vCPU and 4 GB of memory. The numbers below are measured on exactly that — a 2 vCPU / 4 GB cloud VM running k3s with the Anyport agent, cert-manager and the Observability service installed, and nothing else deployed.

What the platform uses before you deploy anything#

CPU at idle is around 0.13 of the 2 vCPU — roughly 6%. Disk is about 1.6 GB for Kubernetes and its container images, before your own images.

That last row is larger than a bare Linux box would use, and the reason is worth knowing: Ubuntu's own processes account for about 65 MB of it. The rest is kernel memory that exists because you are running containers at all — cgroups, network namespaces, firewall rules and container filesystem bookkeeping. It is the cost of Kubernetes showing up somewhere other than the Kubernetes line.

The part worth noticing is that Kubernetes costs far more than Anyport does. The agent is ~100 MB of the ~1.55 GB. If you already run a Kubernetes cluster, connecting it to Anyport costs about 100 MB of memory and 4 millicores per node — everything else in that table is the cluster you already have and already pay for.

How many applications fit#

Each running application costs its own memory plus about 10 MB of Kubernetes overhead (the container runtime, and the API server's bookkeeping for the pod). So on the 2.3 GB left over:

The third column is arithmetic and the fourth is advice. Plan to fill about two thirds of what is left, because the first column describes idle processes: real applications use more under traffic, and a node with no spare memory has nowhere to put the second pod during a rolling deployment, so updates stall instead of rolling.

Kubernetes' own overhead also grows with the number of pods — about 5 MB per pod on the API server and kubelet, which is already included in the 10 MB figure above. The Anyport agent does not: it measured 100 MB with 15 pods on the node and 103 MB with 85.

When 4 GB is not enough#

If you build container images on the same cluster, use 8 GB. A build gets a whole compiler, package manager and image layer cache in memory, and a large npm install or multi-stage Docker build can want 2–4 GB on its own. On a 4 GB node that is the entire application budget, so a build and your apps will compete — and the build usually wins. Builds are transient, so this is a question of whether a deploy can disturb what is already running, not of steady-state capacity.

Also move up from 4 GB when you want a managed database (a small PostgreSQL alone reserves 1 GB of the 2.3 GB), when you run more than one node (the log collector runs on every node), or when you want room for rolling deployments of memory-heavy applications, which briefly run two copies of the pod being replaced.

A practical starting point: 2 vCPU / 4 GB to try Anyport, 4 vCPU / 8 GB for a real project, and more memory before more CPU. Every measurement above ran out of memory long before it ran out of CPU — at 85 pods the node was using 12% of its CPU and 47% of its memory.

Storage#

Storage is the exception to "runs anywhere", and it is worth checking before you connect a cluster rather than after. Anyport refuses a database on a cluster with no default storage class, but a default class whose driver is missing looks fine until the database waits forever, because Kubernetes has nowhere to put the data.

Checking what your cluster has#

kubectl get storageclass

The class marked (default) is the one an unqualified volume request goes to. If none is marked, that's the case worth fixing — Kubernetes will not choose for you, and a volume request binds to nothing.

kubectl patch storageclass <name> \
  -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Anyport shows the same information under Cluster → Settings → Storage once the agent connects, so you can confirm from the console rather than the terminal.

Seeing what the cluster is holding#

The same tab lists every persistent volume in the cluster's Anyport projects, joined to the app or service it belongs to: its size, class, whether a pod is using it, and how old it is. Two situations it is there to catch:

• Orphaned volumes. A service uninstalled while the agent was disconnected, a volume removed from an app, or a project deleted on a storage class that retains data leaves a disk behind that nothing owns and that keeps billing. These rows lead the list and carry a Delete verb. A volume that belongs to a paused project or service is not orphaned: nothing is using it, but it is still owned, and it is never offered for deletion.
• Size drift. An app or database that asks for a larger volume than the cluster gave it shows both numbers. Resizing itself happens on the app's or service's own settings, never here.

Volumes Anyport did not create are listed so you know they are there, but cannot be deleted from the console. This view needs the agent to report volumes; an older agent shows an update prompt in its place.

Clusters that need setup#

• Amazon EKS — a new cluster has no working default class until the EBS CSI driver add-on is installed. This is the most common cause of a service that never starts.
• Bare metal and on-prem — no storage exists until you install a CSI driver. local-path-provisioner is the simplest option for a single-node cluster; it stores data on the node, so it does not survive that node.
• Cloudfleet — a new cluster has no storage class. On a Hetzner fleet, install hcloud-csi from the Marketplace in Cloudfleet's console; it needs your Hetzner API token and makes hcloud-volumes the default class. Anyport names this fix when it refuses an install, and on the first-run card.
• k3s, k3d, kind, Docker Desktop — a default class is already there. Note it does not support expansion and does not enforce the size you request.
• GKE, AKS, DigitalOcean, and most managed clouds — ready as-is.

Log collection#

The Observability service collects container logs by reading them from each node. Some clusters forbid that:

• GKE Autopilot, OpenShift with its default security policies, Talos, and any cluster running Pod Security Admission at restricted.

On those clusters metrics still work — they are collected through the Kubernetes API and touch nothing on the node. Only log collection is affected, and Anyport says so on the Observability service rather than leaving you to notice logs never arrive.

Everything else#

Next steps#

• Connecting clusters — Attach a cluster that has what this page lists.
• Anyport Cloud — No cluster to size? On Pro, Anyport runs one for you.
• Logs & metrics — What works out of the box, and what the Observability service adds.