ohMyHelm: Helm Charts for 15-Factor Apps Without Kubernetes Complexity

TL;DR

• ohMyHelm is a universal Helm chart wrapper that delivers production-ready workloads without requiring teams to maintain their own templates – the entire definition is managed through a central values.yaml.
• Standard components like Deployments/StatefulSets, Ingress, RBAC, ConfigMaps, Secrets (including External Secrets Operator), and observability hooks are integrated and pre-configured according to best practices.
• The 15-Factor principles (configuration, backing services, logs, telemetry, parity) can be consistently mapped into Helm models with ohMyHelm – ideal for standardized cloud-native architectures on /kubernetes/.
• Guardrails such as resource limits, network policies, security contexts, and standardized service dependencies make it easier to enforce regulatory requirements and internal /compliance/ guidelines.
• ayedo uses ohMyHelm itself as a building block of a sovereign, policy-compliant platform and supports teams in transitioning their applications into a secure, auditable operational environment without Kubernetes overhead.

Why Helm Charts Often Bring More Complexity Than Benefit

Helm has become the de facto standard for packaging applications on /kubernetes/. However, in practice, many teams see two opposing realities:

• Either individual Helm charts are created for each service with their own templating style, their own understanding of “best practice,” and varying levels of maturity.
• Or it remains a matter of copy & paste from existing repositories, leading to inconsistent resources, missing guardrails, and difficult-to-trace dependencies.

For engineering leads with compliance responsibilities, this is a dilemma: they are responsible for stability, security, and regulatory compliance without being able to review every line of template code themselves. This is where ohMyHelm comes in – as an abstraction layer that encapsulates the Kubernetes infrastructure while providing standardized, auditable structures.

What is ohMyHelm? An Abstraction Layer Over Kubernetes

ohMyHelm is not another “application chart” but a universal Helm chart wrapper. Instead of writing individual templates for each application, you bind ohMyHelm once as a dependency and describe your application solely through configuration values.

Core Idea: Centralized Templates, Logic in values.yaml

The basic idea is simple:

• Helm templates for typical resources (Deployments, Services, Ingress, RBAC, Monitoring, etc.) exist centrally in ohMyHelm.
• Your application references these templates as a dependency with its own alias.
• Everything application-specific – images, ports, environment variables, secrets, limits, policies – is configured exclusively in your chart’s values.yaml.

For you as the responsible person, this means:

• No own templating DSL zoo in every repository.
• Fewer sources of error when introducing new security requirements.
• A consistent foundation on which different teams can work without constantly reinterpreting Helm details.

Central Features for Production-Ready Deployments

ohMyHelm deliberately targets production-ready, multi-stage environments – with standards that prove themselves in audits and 24/7 operations.

Workload Types: Deployment, StatefulSet, Services, Ingress

ohMyHelm supports both classic stateless deployments and StatefulSets, which are necessary for databases or stateful services. Through your configuration, you determine:

• Whether a Deployment or StatefulSet is created.
• What Services (ClusterIP, NodePort, LoadBalancer) should look like.
• Which Ingress routes are provided – whether simple HTTP routes or more complex host/path combinations with TLS.

Teams do not need to create their own YAML manifests for this, but only declare what the desired end state should look like.

Configuration & Secrets: ConfigMaps, ESO, and RBAC

ohMyHelm comes with integrated mechanisms for configuration and secrets:

• ConfigMaps for non-sensitive configuration data (e.g., feature flags, framework settings).
• Secrets for passwords, tokens, and certificates.
• Optional integration with an External Secrets Operator (ESO), which retrieves secrets, for example, from /apps/hashicorp-vault/.

This gives you a clear separation:

• Long-term, secure storage of secrets in a secret backend like Vault.
• Kubernetes-near distribution of these secrets via ESO.
• Uniform connection of your applications to these secrets via ohMyHelm.

Additionally, you can define ServiceAccounts and RBAC roles per application. This prevents the widespread “default-ServiceAccount” anti-pattern and enables least-privilege approaches without having to write individual, manually maintained roles for each service.

Observability: Built-in Monitoring and Metrics

Modern cloud-native architectures cannot be operated sensibly without observability. ohMyHelm offers standardized hooks for this:

• Configuration of readiness and liveness probes.
• Optional Prometheus ServiceMonitors that automatically collect metrics from your workloads.
• Clean HTTP endpoints for health and metrics routes, which can be visualized with tools like /apps/grafana/.

This makes observability no longer a “tacked-on” topic but part of the standard deployment model.

Modeling 15-Factor Apps with ohMyHelm

The original 12-Factor and further developed 15-Factor principles are the blueprint for many teams’ cloud-native strategies. ohMyHelm is explicitly designed to technically map these principles.

Configuration as a First-Class Citizen: values.yaml

Instead of baking configuration into containers or using different templating in different environments, everything is controlled via values.yaml:

• Image references and versions.
• Configuration switches and feature flags.
• Environment-specific settings (e.g., external URLs, timeouts, limits).

This allows you to achieve:

• A clear separation of build and release phases.
• Versioning of all configurations in the Git repository.
• Transparency about which settings are active in which environment.

Backing Services as Declarative Dependencies

15-Factor apps treat backing services – databases, queues, caches, external APIs – as interchangeable resources. In the Helm world, this means:

• Backing services are either deployed as their own charts or connected as external, managed services.
• ohMyHelm models the dependencies via Helm dependencies and values.yaml.

For example, you define:

• The connection to a PostgreSQL instance.
• A Redis cluster as a cache.
• An observability or security component as an accompanying service.

All these resources remain decoupled from each other while the deployment model remains consistent.

Logs and Telemetry as a Continuous Data Stream

In the 15-Factor model, logs are understood as a continuous event stream, not as local files. In a /kubernetes/ environment, this means:

• Containers log to stdout/stderr.
• Central log pipelines read these streams.

ohMyHelm ensures that your workloads provide the necessary labels, ports, and endpoints so that logging, metrics, and tracing stacks can capture this data. Combined with tools like /apps/grafana/, this creates a consistent observability picture across all applications.

Compliance-Ready Guardrails Without Extra Effort

With increasing regulatory requirements – from the European Data Act to industry-specific standards – it is becoming increasingly important for platform managers to establish clear technical guardrails. ohMyHelm supports exactly this task.

Resource Limits and Requests as Standard

Missing or inconsistent resource limits are a common finding in audits. In ohMyHelm, they are part of the basic equipment:

• CPU and memory requests and limits can be centrally defined per application.
• Organizations can define mandatory minimum requirements that apply to all ohMyHelm instances.

This avoids “noisy neighbors” and unplanned costs – while also meeting common /compliance/ requirements for capacity planning and risk management.

Network Policies and Service Isolation

Network segmentation is an important building block for secure platforms. In combination with a CNI like /apps/cilium/, you can:

• Define standard network policies for different application classes.
• Only enable the communication paths that are actually needed.
• Control east-west traffic in your cluster in a targeted manner.

ohMyHelm helps to anchor these policies as a recurring pattern in your charts instead of defining them anew for each service.

Security Contexts and Runtime Hardening

Security contexts are essential for hardening container runtime environments:

• Non-root users.
• Read-only file systems where appropriate.
• Dropping unnecessary Linux capabilities.

ohMyHelm provides parametric configurations for this, which can be defined once in accordance with your security policies and then reused for all applications. This reduces the risk that individual services are operated “under the radar” with overly extensive rights.

Embedding in European Regulation

On January 11, 2024, the European Data Act came into force; central obligations for data portability and interoperability will take effect from September 12, 2025. This is supplemented by further initiatives around cloud sovereignty and standardization.

ohMyHelm fits into this picture by:

• Enforcing standardized, machine-readable configurations.
• Promoting portability because your application definitions are not tied to a specific cloud provider.
• Creating the technical foundation to implement platform policies transparently and reproducibly.

Practical Scenario: Thinking of a Django App with ohMyHelm

What does this look like in practice? Instead of showing a complete manifest or chart, we focus on the structure you should keep in mind as the responsible person.

Imagine a classic Django application that:

• Uses a PostgreSQL database.
• Is accessible over HTTPS on the public internet.
• Processes asynchronous jobs via Celery workers.
• Delivers logging and metrics to the central observability environment.
• Holds sensitive configurations (e.g., SECRET_KEY, database passwords) in /apps/hashicorp-vault/.

In an ohMyHelm-based values.yaml, you would find the following logical blocks at a high level of abstraction:

1. Base Workload
   Definition of the container (image, tag, ports), replica count, probes, requests/limits. Here you also specify whether a Deployment or StatefulSet is used.

2. Configuration and Secrets

   • Configuration parameters like debug flags, allowed hosts, external URLs.
   • References to secrets obtained via the External Secrets Operator from Vault (e.g., database URL, SECRET_KEY).

3. Backing Services
   Declaration of whether the PostgreSQL database is provided in the same cluster or operated externally, including the necessary connection information.

4. Ingress and TLS

   • Hostname, paths, TLS configuration.
   • Optional redirects, HSTS settings, configuration of HTTP headers for security policies.

5. Observability

   • Activation of a ServiceMonitor for metrics.
   • Definition of health and metric endpoints.
   • Labels and annotations for your central logging and tracing pipeline.

6. Security & Compliance

   • SecurityContext parameters (e.g., RunAsNonRoot).
   • NetworkPolicy-P