SATELLITE CLUSTERS // BETA
A Server You Already Own, Now a Platform on Kubernetes
Connect a VPS, a dedicated box, or a machine in your office. One command installs K3s; Edka adds the platform on top: apps, databases, GitOps deployments, domains with TLS, observability, and agents. No cloud account, no SSH access to hand over.
01 // CREATE
Create a satellite cluster
In the dashboard, choose Satellite cluster and name it. Copy the connect command; it carries a one-time enrollment token that expires after 60 minutes.
02 // RUN
Paste one command
Run it on the server as root. The installer checks the server first, installs K3s pinned to the version Edka validates against, and enrolls the server.
03 // DEPLOY
Use it like any cluster
Add-ons and observability install automatically. Deploy apps, databases, and agents; point a domain at it and TLS is issued for you.
THE CONNECT COMMAND
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 readable before you run it, published with its sha256. Your cluster id and token travel as environment variables, not in the URL.
FEATURES // SATELLITE
Your Hardware, Edka's Platform
Anyone can run K3s on a server. A satellite adds what comes after: add-ons, apps, databases, deployments, domains with TLS, and observability, the same stack a cloud cluster gets. The server stays yours.
Any Server
A VPS at any provider, a dedicated box, or a machine in your office.
- Ubuntu 22.04+ or Debian 12+, x86_64 or arm64
- 2 GB RAM and 20 GB free disk
- Public IPv4 with ports 80, 443, and 6443 free
- Preflight checks tell you exactly what is missing
One Readable Command
A static install script you can read before running, published with its sha256.
- One-time enrollment token, 60-minute expiry
- Secrets travel as environment variables, not URLs
- Safe to re-run; a healthy install is reused
- K3s pinned to the version Edka validates against
The Full Platform
The same platform components a cloud cluster gets, installed automatically.
- Apps and databases from the catalog
- GitOps and container deployments
- Agents: Codex, Hermes, and OpenClaw
- Metrics, logs, and alerts included
Direct Traffic
Workloads are served straight from the server's public IP.
- Gateway on ports 80 and 443, no load balancer
- TLS certificates issued for your domains
- K3s ServiceLB publishes the server's public IP
You Stay in Control
Edka's access is a service account in the cluster, nothing more.
- No SSH access, ever
- Delete the service account and Edka is locked out
- The cluster is plain K3s and keeps running without us
- One command wipes the server when you decide
Beta, Stated Plainly
What satellites do not do yet, so you are not surprised.
- Single node per satellite; multi-node is on the roadmap
- You upgrade K3s in place with a one-line command
- No cluster (etcd) backups yet
- Database and agent state backups work as usual
INCLUDED // EVERY PLAN
Connect Your First Server
The Free plan includes one satellite cluster; Standard includes 5 and Pro 10. Extra satellites cost €10/month on any plan, and satellites never count against your cloud cluster limit.
What is a satellite cluster?
A satellite is a single-node Kubernetes cluster on a server you already own: a VPS, a dedicated server, or a machine in your office. You connect it by running one command on the server, and it appears in Edka next to your cloud clusters with the same apps, databases, deployments, domains, and observability.
Do I need a Hetzner or cloud account?
No. Satellites need no cloud account and no API token. Any server that meets the requirements works, from any provider or your own hardware.
What are the server requirements?
Ubuntu 22.04, 24.04, or 26.04, or Debian 12 or 13, on x86_64 or arm64, with at least 2 GB RAM, 20 GB free disk, and a public IPv4. Ports 6443, 80, and 443 must be free. The installer checks all of this before touching the server and tells you exactly what is missing.
What access does Edka get to my server?
No SSH access, ever. The installer creates a Kubernetes service account and hands Edka a credential for it; that is the only access Edka has. You can delete the service account at any time, and Edka is locked out while your cluster keeps running.
Is the install script safe to run?
The script is static, the same for everyone, and readable before you run it; its sha256 is published so you can verify a download. Your cluster id and one-time enrollment token (60-minute expiry) travel as environment variables, never in the URL.
What happens if I stop using Edka?
Nothing, on the server. The cluster is plain K3s and keeps running without us. Deleting the cluster removes it from Edka only; a single uninstall command wipes K3s from the server when you decide to.
What are the beta limitations?
One node per satellite (multi-node is on the roadmap), K3s upgrades are a one-line command you run yourself, and cluster (etcd) backups are not available yet. Database backups to S3 or GCS and agent state backups work as usual.
What does it cost?
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.