Epinio

What Epinio does

Epinio installs into a Kubernetes cluster and gives developers a short path from source code to a running app with a URL. Instead of writing deployments, services and ingresses, a developer pushes code with the epinio CLI or the web UI, and Epinio builds an image, deploys it and routes a hostname to it. The project’s aim is that people with no Kubernetes experience can deploy to a cluster their operations team runs.

Sources can be a local folder, an archive, a Git URL, a GitHub or GitLab repository at a chosen branch or commit, or an existing container image. By default Epinio builds with Paketo Cloud Native Buildpacks, which detect the language and framework; a Dockerfile build is the alternative. Apps are grouped in namespaces, and each app can have several instances, custom routes and environment variables. Application charts decide how an app is turned into Kubernetes resources, so operators can adjust the defaults.

Services and configurations

Backing services come from a service catalog. Each catalog entry is a Helm chart, such as a database, which developers can create instances of and bind to their apps. Operators can add their own entries by pointing at a chart in any Helm repository. Configurations, which can describe an external database or a SaaS account, are bound to apps in the same way to hand over credentials. Deployed apps can also be exported to an OCI registry.

Self-hosting Epinio

Epinio is installed with a Helm chart into an existing cluster. The documentation supports Kubernetes 1.34 to 1.36 on distributions such as RKE2, K3s, k3d and minikube, and asks for an ingress controller with a default IngressClass (Traefik is recommended), cert-manager, metrics-server and a default storage class, preferably with ReadWriteMany access. The minimum it lists is 2 to 4 vCPUs, 8 GB of RAM and 10 GB of disk, and it notes that real workloads need more. To reach apps from the internet, the cluster also needs a load balancer.

The chart brings several components of its own: Dex for login, SeaweedFS for S3-compatible storage, Reflector and a container registry. Each one can be turned off in favor of an external registry, S3 service or identity provider.

Epinio was started at SUSE; the README now lists Krumware as copyright holder from 2025 onward, and releases continue in the 1.14 series.

Hosted version

There is no hosted Epinio. The website has a contact form for commercial support.

Limitations

Epinio assumes you already run Kubernetes, with ingress, certificates and storage in place, so it is not a shortcut for someone with a single small server. It has no pull-request preview environments. Its community is smaller than those of the Docker-based platforms in this category, and its repository has fewer stars than the other projects listed here. We include it because it is an established, maintained Kubernetes PaaS.

Who it suits

Epinio suits organizations that run Kubernetes and want to give developers a push-to-deploy experience close to Cloud Foundry or Heroku, with services provided from Helm charts the operations team controls. For a Kubernetes platform with pipelines and review apps, compare Kubero and Canine; for larger multi-team setups, Tsuru.