SYS.DOCS // DOCS

Kubernetes Deployments Management

Deploy containerized applications to Kubernetes with Edka.

Workload types

Edka supports three workloads:

Container image deployments: manage a deployment from a pre-built image.
Branch deployments (Git): build from a GitHub branch or tag, with optional preview environments. See Branch deployments.
Cron Jobs: run scheduled batch workloads (for example backups, cleanup jobs, and sync tasks). See Cron Jobs.

Create a Deployment

Basic Configuration

Set the core deployment settings.

Basic Configuration

Name: Deployment name
Namespace: Kubernetes namespace
Replicas: Number of pods
Image repository: Container image source
Image tag: Version to deploy
Container port: Port exposed by the container

Environment Variables and Secrets

Add configuration and sensitive values.

Environment Variables and Secrets

Environment variables: Non-sensitive key-value pairs.
Secrets: Stored as Kubernetes Secrets in your cluster and exposed to the deployment as env vars. Values are write-only in Edka; update by submitting a new value.

Edka allows importing values from .env, JSON, or YAML, or add them individually. Edka will validate and assigns them as environment variables or secrets.

Storage

Choose a storage type.

Storage

You can choose between:

Persistent Volume Claim (PVC): durable block storage. Enter a size (for example 10Gi) and pick a storage class. On Hetzner clusters the classes are hcloud-volumes (default) and hcloud-volumes-encrypted.
Empty Directory (EmptyDir): ephemeral storage that lasts for the pod’s lifetime only.

When a cluster exposes multiple storage classes, Edka marks the default class and node-local classes in the selector. For persistent workloads, prefer the default non-node-local class unless you intentionally want storage tied to a single node.

Networking

Edka supports three exposure patterns in the deployment form:

Internal Only keeps the default ClusterIP service inside the cluster.
Connected Domain publishes the deployment behind a managed hostname through Gateway API, legacy ingress, or direct tailscale exposure.
Private LoadBalancer allocates a private IP from the cluster private subnet through MetalLB.

For new internet-facing workloads, Edka recommends installing Envoy Gateway from the cluster Gateway tab and selecting a Gateway API traffic class in Connected Domain mode.

For private traffic, Edka supports three paths:

Select the direct tailscale traffic class to publish <subdomain>.<tailnet-dns-name> hostnames.
Create a Gateway class with exposure mode Tailscale tailnet (BYOD) and use that traffic class for private Gateway API routes.
Create a Gateway class with exposure mode MetalLB private VIP when you want private Envoy Gateway routing on the cluster subnet.

If you need a service-level private IP without hostname routing, choose Private LoadBalancer. Edka will request a MetalLB-backed LoadBalancer service and show the assigned private IPs in the deployment networking view.

For managed wildcard TLS, hostname domains, and preview domains, use the Domains view. Wildcard domains and DNS-validated hostname domains can target public Gateway classes, private MetalLB-backed Gateway classes, or tailnet-published Gateway classes. HTTP-validated hostname domains require a public Gateway API traffic class. See Domains and TLS.

If remote users need to reach MetalLB-backed private IPs, route the cluster private subnet through the Cloudflare connector or another private network. For the full private networking workflow, see Private Networking. For the full tailnet workflow, see Tailscale Tailnet Exposure.

If you already have a wildcard certificate managed for that traffic class, TLS can be handled at the Gateway level. Direct tailscale exposure uses Tailscale-managed certificates instead of public Let’s Encrypt HTTP-01.

Networking

Automation

Automatically roll out new images using SemVer policies. Edka polls the registry on the Check Frequency you set (1 minute to 24 hours) rather than reacting to a push event. Automatic updates require the Keel add-on installed in the cluster.

Policies:

all: Update on any bump or prerelease (e.g., 1.0.0 → 1.0.1-rc1)
major: Allow major, minor, and patch updates
minor: Allow minor and patch updates; block major
patch: Allow patch updates only
force: Update even for non-SemVer tags (e.g., latest). Edka pins updates to the same tag (sets keel.sh/match-tag=true).
custom: Match versions with a glob or regex pattern. Enter a value prefixed with glob: (e.g., glob:1.0.*) or regexp: (e.g., regexp:^v[0-9]+\.[0-9]+\.[0-9]+$).