Containerized Web App on Kubernetes with PostgreSQL

A web application is only useful once it runs somewhere reliably. The goal was to take a Kanban board from a local prototype to a Kubernetes deployment: login, data that survives pod restarts, and a clean path from source code to a running cluster.

The app is a single-board Kanban with five renameable columns and drag-and-drop cards. The frontend is Next.js 16, exported as static files. The backend is FastAPI with SQLAlchemy. Local development uses SQLite; Kubernetes uses PostgreSQL 18.6. The source code, Dockerfile and manifests are public on GitHub.

1. 1.Packaged the frontend and backend into one image with a multi-stage build, so the cluster runs one application workload with no separate web server.
2. 2.Kept configuration in environment variables (DATABASE_URL, admin credentials, SESSION_SECRET), so the same image runs with SQLite locally and PostgreSQL in the cluster.
3. 3.Ran PostgreSQL as a StatefulSet with a volumeClaimTemplate instead of a Deployment, which gives it a stable identity and its own persistent volume.
4. 4.Added an init container and readiness/liveness probes, so the app starts in the right order and Kubernetes only sends traffic to healthy pods.
5. 5.Set CPU and memory requests plus memory limits on both workloads, so the scheduler can place them and a runaway process cannot starve the node.
6. 6.Added a Docker Compose file with the same PostgreSQL version as the cluster, to test the production database path locally before deploying.
7. 7.Organized the manifests with Kustomize, so the image name and tag are changed in one place.

• ▸The container runs as a non-root user (UID 10001) on a slim base image.
• ▸Credentials and the session key come from a Kubernetes Secret, not from the image. The committed Secret holds placeholder values only, and the README says to change them before any real deployment.
• ▸The API requires a signed session cookie on every board endpoint, and the login check uses a constant-time comparison.
• ▸PostgreSQL is reachable only inside the cluster through its headless Service. It is not exposed through a NodePort.
• ▸The build context excludes local databases, virtual environments and the manifests themselves (.dockerignore).

• ▸kubectl apply -k k8s/ creates the namespace, Secret, database and app in one command, and kubectl delete -k removes them.
• ▸On first start, the app creates its schema and seeds a demo board automatically.
• ▸Tests at three levels: Pytest for the API, Vitest for React components and hooks, and Playwright end-to-end tests that start their own servers.
• ▸A multi-architecture buildx command produces an image that runs on both Apple Silicon and x86_64 cluster nodes.

• ▸A working full-stack application deployed to Kubernetes from public, reproducible manifests.
• ▸Board data is stored in PostgreSQL on a persistent volume, so it survives app and database pod restarts.
• ▸The same image runs in three places: locally with SQLite, in Docker Compose with PostgreSQL, and in Kubernetes.
• ▸Source, Dockerfile, manifests and tests are public on GitHub.

• ▸Database start-up order matters: an init container is a simple way to avoid crash loops while PostgreSQL initializes.
• ▸Major PostgreSQL versions can change the data directory layout. Checking the image documentation before mounting volumes avoids losing data.
• ▸Next steps for production use: an Ingress with TLS instead of NodePort, secrets from an external secret manager, secure-only session cookies, and backups for the PostgreSQL volume.