Most people already pay for a server that does less than it could. A VPS from an old project, a dedicated box with spare capacity, a machine in the office.
Satellite clusters turn one of those servers into a platform. You run one command on it as root; Edka installs K3s and the same platform components a cloud cluster gets. No cloud account, no API token, no SSH access to hand over. Satellites launch today in beta, included in every plan.
How it works
In the dashboard, create a Satellite cluster and copy the connect command. It carries a one-time enrollment token that expires after 60 minutes. Run it on the server:
curl -fsSL 'https://api.edka.io/api/byo/install.sh' | sudo EDKA_API='...' EDKA_CLUSTER_ID='...' EDKA_ENROLLMENT_TOKEN='...' sh -s -The script is static and safe to read before you run it; your cluster id and token travel as environment variables, not in the URL. To verify a download, compare its sha256 with the published checksum.
The installer checks the server before touching it: supported OS, enough RAM and disk, free ports, a public IPv4, no existing Kubernetes. If something is missing, it says exactly what and stops. Then it installs K3s pinned to the version Edka validates against, applies the necessary CRDs, creates the service account Edka uses to manage the cluster, and enrolls the server.
Edka takes it from there: cert-manager, metrics-server, node-exporter, the Edka agent, and the VictoriaMetrics and VictoriaLogs observability services, the same set a cloud cluster gets.
Apps, databases, agents, deployments, domains, and observability work the same as on cloud clusters. Traffic is published directly on the server’s public IP: K3s ServiceLB puts the Gateway on ports 80 and 443, and cert-manager issues TLS certificates for your domains.
Worth knowing
- You own the server. Edka manages the cluster through a service account you can delete at any time to cut its access. Deleting the cluster removes it from Edka only; one uninstall command wipes K3s from the server when you decide to.
- One server, one node. There are no node pools, NAT gateways, or cluster (etcd) backups on satellites. Database backups to S3 or GCS and agent state backups work as usual.
- The requirements are modest. Ubuntu 22.04, 24.04, or 26.04, or Debian 12 or 13, on x86_64 or arm64, with 2 GB RAM, 20 GB free disk, a public IPv4, and ports 80, 443, and 6443 free.
- You upgrade K3s yourself, in place. When the server’s version falls behind, Edka shows the one-line upgrade command. Workloads keep running while K3s restarts.
In beta, on every plan
Every plan includes satellite clusters during beta and after: 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. For example, the free plan gets 1 satellite and one cloud cluster.
Satellites ship as a beta. We’re working on bringing more features by the end of the year. Next up:
- Cluster backups.
- Instance hardening and firewall rules.
- Support for more Linux distributions.
- Higher satellite limits.
- Managed K3s upgrades, so you no longer run the in-place command yourself.
- Migration from a satellite cluster to a full cloud cluster: move your apps, databases, and domains when you outgrow the single server, without rebuilding them by hand.
Full details are in the Satellite Clusters docs.
Connect your first server or book a demo if you want a walkthrough.