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

You just deployed your application to Kubernetes. So the hard part is done, right?

Well, not really. That moment is usually the beginning.

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. Not just “it deploys”, but repeatable delivery, guarded change management, recovery paths, monitoring, and policy controls.

This article describes what changed coming from a development setup on Kubernetes to prepare for day-2 operations.

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

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.

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 Kind cluster, 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 provide each capability was a separate decision.

That separation helped. We could first agree on the contracts the product needed, then pick components that fit those contracts and the way we wanted to operate the system.

The Timeline

The order below is not meant as a universal checklist. It is the order we chose for this project because the system first needed to become usable before it could become governable.

Broadly, the work moved through four stages:

Make the building blocks work.

Make the product work...