Edka

Run apps, databases, and agents on infrastructure you control.

Comment

Inspiration

I kept provisioning Kubernetes clusters for testing, for friends or for some small projects. Every time it meant writing infrastructure as code from scratch, because every project needed a slightly different setup, and every time it took me a couple of days to put something usable together.

Maintenance was also a struggle. For example, restoring a database meant hand writing manifests with the exact restore configuration for that case.

The existing providers did not really solve this. Their offerings were expensive, and what you got was just a managed Kubernetes cluster. Ingress, TLS, backups, databases, deployments, all the things that make a cluster actually useful, were still on you. Edka started as my way out of that loop.

What it does

Edka provisions and operates Kubernetes clusters on Hetzner, in your own account. It is not a hosted service that runs your workloads for you; the infrastructure is yours, Edka does the orchestration.

  • Cluster lifecycle: create k3s clusters with node pools on Hetzner Cloud servers or dedicated metal servers, scale and upgrade them anytime.
  • Add-ons: one-click install and upgrade of ingress, cert-manager, monitoring, databases, container registries, self-hosted GitHub Actions runners, and more, all running inside your cluster.
  • GitOps: connect a repository and deploy complex applications and services.
  • Apps: a curated catalog plus organization authored app templates. Ready to install with a few clicks and aware of other cluster components. Let's say you want to install an application that needs Postgres and Redis. Edka automatically discovers provisioned databases and connect them to your app, without the need to get the credentials or connection endpoints.
  • Backups: run inside the customer's cluster; Edka only brokers scheduling and status, workload data never transits Edka.
  • Live operations: real-time status, monitoring, logs, alerts, cluster connectivity detection, and drift detection between desired and actual state.

How I built it

A TypeScript monorepo: Node.js/Express backend, React/Vite frontend. PostgreSQL, Redis with BullMQ for the background work, and Socket.IO for realtime progress in the UI.

The backend talks with a provisioner micro-service written in Go that does the actual communication with the cloud provider API and cluster instances.

Challenges I ran into

  • Infrastructure operations sometimes fail halfway. Everything had to become an asynchronous, idempotent, retryable job, and the state model had to reconcile against provisioned resources instead of trusting what was requested.
  • Some implementations had to be refactored a couple of times. Achieving good UX is one of the hardest challenge.
  • Helm upgrades have sharp edges. A chart release changed an immutable StatefulSet field, which no upgrade can apply.
  • Teardown ordering matters as much as install ordering. Deleting a credentials Secret before the Helm release that needs it for finalizers, wedges the uninstall.

Accomplishments that I'm proud of

  • A level of abstraction on top of Kubernetes while preserving full access to the underlying infrastructure for the user.
  • Production clusters running on a mix of cloud and dedicated metal, managed from one place with a few clicks.
  • DNS delegation for simple custom domain connectivity.
  • Dedicated private connectivity integration using Tailscale and Cloudflare Warp.
  • An app template system that allows transforming any project into a native Edka application.
  • An add-on system that handles the upgrades, immutable-field migrations, and uninstalls that do not strand resources.
  • A backup architecture where customer data stays in their control using their own object storage buckets.

What I learned

Provisioning is the easy part. Maintaining compatibility between components during upgrades, safe teardown ordering, drift, and partial failure are still the biggest challenges. Every external system (cloud APIs, Helm, the clusters themselves) has to be treated as something that can fail mid-operation, which pushes you toward reconciliation loops and idempotency from the start.

What's next for Edka

  • An MCP server so AI agents can provision and operate infrastructure through Edka.
  • Growing the community app template repository so anyone can publish deployable apps.
  • Support for other cloud providers.
  • Deeper drift detection and remediation.
  • Expanding dedicated metal support to any server.
Share this project:

Updates