Satellite Clusters

A satellite is a server you already own, connected to Edka as a single-node Kubernetes cluster. It can be a VPS at any provider, a dedicated server, or a machine in your office. You run one command on the server as root; Edka installs K3s and the same platform components a cloud cluster gets.

Satellites need no cloud account and no API token. Apps, databases, agents, deployments, domains, and observability work the same as on cloud clusters, published directly on the server’s public IP.

Every plan includes satellite clusters: 1 on Free, 5 on Standard, 10 on Pro. Extra satellites cost €10/month each on any plan, Free included. Satellites have their own limit and never count against your cloud cluster limit.

Server requirements

The installer checks all of this before touching the server and tells you exactly what is missing:

• OS: Ubuntu 22.04, 24.04, or 26.04, or Debian 12 or 13, with systemd.
• Architecture: x86_64 or arm64.
• Resources: at least 2 GB RAM and 20 GB free disk space on /.
• Public IPv4: the server must have one and be reachable on it.
• Ports: 6443, 80, and 443 must be free. Port 6443 must accept inbound TCP from the internet so Edka can reach the Kubernetes API. Ports 80 and 443 serve your workloads.
• Root access: the command runs as root (via sudo).
• No existing Kubernetes: the installer refuses servers that already run K3s, RKE2, MicroK8s, kubeadm, or k0s. Remove any previous installation first.

Stateless provider firewalls

Some provider firewalls are stateless (the Hetzner Robot firewall template is a common example), so return traffic needs explicit rules. If pods cannot reach the internet, allow incoming TCP with the ack flag on destination ports 1024-65535, plus UDP replies from source port 53 for DNS. The installer probes pod egress before enrolling and reports this exact fix when it applies.

Connect a server

1. In the Edka dashboard, open the create menu and choose Satellite cluster, then name the cluster.

2. Copy the connect command. It looks like this:

   curl -fsSL 'https://<api>/api/byo/install.sh' | sudo EDKA_API='...' EDKA_CLUSTER_ID='...' EDKA_ENROLLMENT_TOKEN='...' sh -s -

3. Run it on the server as root. The command embeds a one-time enrollment token that expires after 60 minutes; regenerating a command invalidates the previous one.

4. Watch the status on the connect page, or come back later: the cluster appears in your list as soon as the server connects.

The installer runs the preflight checks, installs K3s pinned to the version Edka validates against, applies the Gateway API CRDs, creates the access credential Edka uses to manage the cluster, and enrolls the server. Edka then installs the required add-ons (cert-manager, metrics-server, node-exporter, and the Edka agent) and the observability services. Re-running the command is safe: a healthy K3s installed by Edka is reused and the server simply re-enrolls.

A server can be connected to only one Edka cluster at a time. This is keyed on the server’s public IP.

How traffic works

Satellites have no cloud load balancer. K3s ServiceLB publishes the server’s public IP on the Gateway, so anything you expose through a domain is served directly from the server on ports 80 and 443. Exposures through the server IP are always public.

Storage

Persistent volumes use the K3s local-path storage class, backed by the server’s own disk. When you provision apps and databases, Edka applies this default automatically.

What is different from cloud clusters

A satellite is one server, so cloud-side features do not apply:

• Node pools: not available; a satellite runs on a single server.
• NAT gateway and provider load balancers: not available.
• Cluster (etcd) backups: not available. Database backups to S3 or GCS and agent state backups work as usual.
• SSH credentials from Edka: not available; you already have root on the server.
• Managed Kubernetes upgrades: not available yet. You upgrade K3s in place yourself (see below).

Upgrade K3s

You stay in charge of the server, so Edka never runs upgrades on it. When the server’s K3s version falls two or more minor versions behind the version Edka validates against, the cluster page shows a notice with the in-place upgrade command:

curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<pinned-version> sh -s - server

The installer keeps the K3s configuration in /etc/rancher/k3s/config.yaml, which this command preserves. Workloads keep running while K3s restarts.

Reconnect or replace a server

If enrollment fails, or a connected server later goes offline, generate a new connect command from the cluster’s Overview page and run it on the server again. A new command can be generated while the cluster is awaiting connection, failed, or disconnected; Edka marks a cluster disconnected after its API has been unreachable for 24 hours.

Re-enrolling a wiped or reinstalled server reinstalls the platform components and any add-ons you had. Apps and databases are not recreated automatically: their configuration may reference secrets and data that no longer exist on the new server, so redeploy them deliberately.

Revoke Edka’s access

Edka manages the cluster through the edka-manager service account in kube-system. To cut Edka’s access at any time, delete it on the server:

kubectl -n kube-system delete serviceaccount edka-manager

The cluster keeps running; Edka simply can no longer reach it.

Delete a satellite cluster

Deleting a satellite removes it from Edka only. Nothing is uninstalled from your server: K3s and your workloads keep running until you remove them yourself. To wipe the server, run:

/usr/local/bin/k3s-uninstall.sh

Related

• Create a Cluster — cloud clusters on Hetzner.
• Hetzner Metal Server Pools — dedicated servers as worker pools in a cloud cluster.
• Domains and TLS — expose workloads on your domains.
• Pricing — satellite limits per plan.