15 Factor App Deep Dive: Factors 1–6 (Basics & Lifecycle)

TL;DR

• Factors 1–6 of the 15-Factor App define the internal lifecycle of an application: from the codebase through dependencies and configuration to processes and runtime behavior.
• A single codebase with clearly declared dependencies and external configuration reduces operational risks, facilitates audits, and lays the foundation for robust, portable deployments.
• Backing services as interchangeable resources and strictly separated build/release/run phases are key levers for resilience, portability, and regulatory traceability.
• Stateless processes support high availability and disaster recovery – an important component for organization-wide compliance and resilience requirements.
• With ohMyHelm as the packaging tool of the ayedo platform, these factors can be systematically translated into Helm charts and values.yaml files – including a clean separation of code, configuration, and environment (without proprietary dependencies).

Why the First Six Factors Make the Difference

The 15-Factor App extends the well-known 12-Factor principles with modern requirements such as telemetry and security. In practice, however, it is primarily factors 1–6 that determine whether an application can be reliably operated on a modern platform – and whether it keeps pace with your compliance and sovereignty goals in the medium and long term.

These first six factors regulate:

• how you structure your code (Factor 1),
• how you manage dependencies (Factor 2),
• how you handle configuration (Factor 3),
• how you integrate external systems (Factor 4),
• how you organize the delivery lifecycle (Factor 5),
• and how your processes relate to the platform (Factor 6).

In combination, they determine how portable, auditable, and resilient your applications are – and thus also how well they fit into a European ecosystem with clear legal frameworks (such as GDPR and national supervisory requirements).

ohMyHelm addresses this precisely: as a standardized packaging tool that translates these principles into reusable Helm charts and values.yaml files. Let’s take a look at the individual factors – with a focus on practical impacts and compliance relevance.

Factor 1: Codebase – One Codebase, Many Deployments

The basic principle: An application has exactly one codebase, maintained in a version control system. From this one codebase, different deployments arise: development, testing, staging, production, possibly tenant or country variants.

Key points:

• No forking of repositories per environment or per customer.
• No copies of deployment manifests with slightly altered parameters.
• All environments reference the same logical codebase, differing only by configuration.

For those responsible, this has several advantages:

• Traceability: A specific commit or tag is clearly assigned to a functional version – important for change management and audits.
• Reduced error sources: No diverging “shadow repositories” with undocumented deviations.
• Faster security fixes: Patches are applied once and then rolled out across all relevant environments.

With ohMyHelm, this separation is elegantly achieved: You define a single chart for your application and use different values.yaml files for development, testing, and production. The application code remains the same, only parameters like resource limits, external endpoints, or feature flags vary. For compliance, this is a win: You can always demonstrate which chart with which values was productive at what time.

Factor 2: Dependencies – Explicitly Declare, Never Rely on System Packages

Factor 2 demands that all dependencies be explicitly declared and isolated. This includes:

• Libraries in the application code (e.g., via Maven, npm, pip),
• Operating system-level packages in the container image,
• Infrastructure dependencies like databases, message brokers, identity providers.

What you want to avoid:

• “It works on my machine because some system package is installed on my build host.”
• “In Cluster A, the base image is slightly different than in Cluster B, so the application behaves differently.”

In a containerized environment, this means:

• Container images are fully self-describing.
• All required libraries and tools are included in the image.
• Which version of which dependency is used is clearly documented.

With ohMyHelm, this principle is structured:

• The Helm chart declares its own dependencies (e.g., database or cache charts) with clear version specifications.
• In the central values.yaml file, the container images along with tags or digests are recorded – ideally without “latest” in sensitive environments.

For compliance, this is key: Explicit dependencies facilitate security assessments, Software Bills of Materials (SBOMs), and structured patch management. If you need to respond to a critical vulnerability, you transparently know which components are affected and where they are used.

Factor 3: Config – Configuration in the Environment, Not in the Code

Configuration is everything that changes between deployments without wanting to touch the code: database URLs, feature flags, API keys, tenant-specific endpoints, regional settings.

The core of Factor 3:

• Configuration does not belong in the codebase.
• Configuration is provided from the environment – typically in Kubernetes via environment variables, ConfigMaps, and Secrets.
• The same container image can thus be operated in different environments with different values.

With ohMyHelm, this separation becomes concrete:

• Functional configuration (e.g., feature flags, logging level) is defined in the values.yaml file and translated by the chart into suitable Kubernetes resources.
• Sensitive values, such as database passwords or OAuth client secrets, are consistently treated as secrets and not checked into the codebase.
• Each environment has its own values file, where these configuration values are maintained – including clear responsibilities for who can change which values.

The connection to GDPR is direct: On May 25, 2018, the GDPR came into force, requiring, among other things, a privacy-friendly default setting (“privacy by default”) and technical and organizational measures to protect personal data. If access points to databases, identity providers, or storage systems are hardcoded, it complicates:

• the separation of roles (development vs. operations),
• the rotation of secrets and keys unnecessarily,
• the risk that sensitive information accidentally lands in repositories or artifacts.

By consistently externalizing configuration in values.yaml and secrets, you get:

• clear interfaces where security and compliance teams can intervene,
• defined points where access to personal data is regulated and checked,
• the ability to adjust configuration per tenant or region without changing the application itself.

A practical example is Identity & Access Management: If you rely on a sovereign identity provider like Keycloak, your applications merely reference the respective Keycloak endpoint, realm, and client configuration via configuration. The application itself remains generic; regulatory-relevant details lie in the environment.

Factor 4: Backing Services – Interchangeable Resources

Backing services are all external systems your application uses: databases, message queues, caches, S3-compatible storages, email providers, but also services like Keycloak for authentication.

The central idea:

• Backing services are treated as attached resources, not as a hardwired part of the application.
• The application accesses these services via well-defined interfaces, typically in the form of URLs, hostnames, and ports provided through configuration.
• Switching the backing service (e.g., from one database cluster to another or from an external to a sovereign European provider) is done through configuration change, not code change.

With ohMyHelm, these principles are reflected in the values.yaml files:

• For each environment, you define the endpoints of your backing services – for example, different database clusters for testing and production or various object storage instances in different regions.
• The chart ensures that this information arrives cleanly in the application’s runtime environment without needing to adjust the application itself.

For compliance and data sovereignty, this is a strategic advantage:

• You can relatively easily migrate applications to another region or provider if regulatory requirements change.
• You are less tied to individual infrastructure operators – an important goal for a strong, independent technology location in Europe.
• You can strictly operate sensitive backing services (e.g., databases with personal data) in EU data centers, while less critical services can be chosen more flexibly.

Factor 5: Build, Release, Run – Strict Separation in the Lifecycle

Factor 5 demands a clear separation of phases:

• Build: Immutable artifacts are built from the source code, typically container images.
• Release: A release combines a specific build artifact with a specific configuration, resulting in a precisely defined version that can be deployed.
• Run: In this phase, releases are executed in the target environments – without altering the artifacts or the associated configuration.

In many organizations, these boundaries blur: Images are rebuilt directly in production, configuration is “quickly adjusted in the cluster,” releases are not cleanly versioned. This complicates:

• Root cause analyses (“Which version was exactly running?”),
• Security assessments and approvals,
• Evidence for auditors.

With ohMyHelm, a clean separation can be implemented very structurally:

• In the build step, a container image of an application version is created.
• In the release step, a Helm chart is combined with exactly this image and a set of verified values.yaml files. This bundle is your release.
• In the run phase, releases with clear version specifications are rolled out to the respective Kubernetes clusters. Changes to configuration or images generate new releases; there is no “silent drift.”

For compliance, this transparency is invaluable: You can always trace back,

• which combination of code and configuration was active in which environment,
• when a specific fix or security-relevant update was rolled out,
• and whether the approval processes defined in policies were followed.

Factor 6: Processes – Stateless, Share-Nothing

Factor 6 views the application as a set of processes that:

• are horizontally scalable,
• can be started and stopped independently,
• hold no local, non-replicated state (“stateless”),
• require no write access to local filesystems that would be critical for correct operation.

State – whether sessions, business data, or long-running workflows – belongs in backing services: databases, caches, object storages, messaging systems. The processes