From Kubernetes Dev Setup to Production: What Actually Changes

Georg Schwarz

From Kubernetes Dev Setup to Production: What Actually Changes<br>May 8, 2026<br>kubernetes gitops devops platform engineering infrastructure

The application already ran on Kubernetes. But that did not make it production-ready.

The starting point was a development-style setup: local minikube deployment, local certificates, *.127.0.0.1.nip.io domains, generated credentials, bundled development dependencies, and manual Helm sequencing.

Moving towards a production deployment changed the operating model. Delivery moved to GitOps, secrets moved to SOPS, object storage moved outside the cluster, database backups became restore-tested, identity flows were customized, and observability gave us a baseline for operating the application.

This article is not about how to deploy an app to Kubernetes. It walks through what had to change after it already ran there.

This post is for: Founders, CTOs, platform engineers, and product teams who already have an application running on Kubernetes but need to make it reliable, repeatable, observable, and safe to operate.

TL;DR

Running on Kubernetes is not the same as being production-ready.

The work followed a deliberate order: make the building blocks work, make the product usable, make change controlled, then make operations recoverable and observable.

Most production-readiness work was integration focused: identity, storage, ingress, secrets, GitOps, backups, and user-facing flows had to line up.

GitOps improved deployment control, but also contributed to a better repository structure and streamlined validation checks.

Backups became particularly meaningful after restore checks were automated. Until then, they were mostly optimism with YAML.

Building something similar?<br>I work with teams on exactly this kind of transition: from working deployments to systems they can safely run, observe, recover, and evolve.<br>Let’s talk.

Context

Over the past few weeks, we took diff/docs, a hosted deployment of La Suite Numerique Docs, from a development-style Kubernetes setup to something that behaves more like a production platform.<br>Operating an application is more than “it deploys”. We aimed for repeatable delivery, guarded change management, recovery paths, monitoring, and policy controls.

If you want to know more about diff/docs, check out Philip’s announcement post.

The Starting Point

The starting point already worked for its intended purpose: development.

La Suite Numerique Docs already provides a Kubernetes installation guide. It is a useful teaching setup: start a local minikube deployment, generate local mkcert certificates, use *.127.0.0.1.nip.io domains, install nginx ingress, and deploy development dependencies for Keycloak, MinIO, PostgreSQL, and Redis through the provided helm-dev-backend chart.

The upstream documentation is clear about the intent: this setup is meant to explain how the system works and needs to be adapted for production.

For diff/docs that meant we started with a documented product architecture and a development-oriented Kubernetes deployment. The task was to turn that baseline into an externally hosted product.

Local certificates, local domains, generated development credentials, dependency containers, and manual Helm sequencing are fine for learning and testing. But they are not enough for a service that needs stable domains, real identity flows, persistent storage, repeatable delivery, backup/restore paths, policy checks, observability, and day-2 operations.

The work focused on closing the gap between “the app runs locally” and “the team can safely change, recover, observe, and evolve the system.”

Understand The Runtime Architecture

Before touching deployment mechanics, we had to be clear about what diff/docs actually was in runtime terms.

The product was more than a single stateless web container. It was an application surface with several components all working together.

At a high level, the architecture looked like this:

La Suite Numerique Docs application as the primary user-facing service, split into multiple deployments

PostgreSQL for transactional data and application state

Redis for cache and real-time/session support

S3-compatible object storage for uploaded media and binary assets

OIDC identity provider for login and token flows

Ingress/gateway layer for TLS termination, host/path routing, and redirects

Not required by the application itself, but necessary for operating it as a product:

GitOps controller for converging the cluster toward the desired state in Git

Observability stack for metrics, dashboards, and alerting

At this point, we were mostly identifying interfaces and capabilities, not final implementations.

The product needed a PostgreSQL-compatible database, Redis-compatible cache, S3-compatible object storage, OIDC identity, HTTP routing, deployment reconciliation, and observability. Which operator, chart, or implementation should...