← Back to overview
Case study — shipped on the lab

Phoenix: a real product on top of the Zero-Trust platform

Standing up Vault and Boundary proves you can secure infrastructure. Shipping an application through it — with its own SSO login, its own secrets, its own release pipeline — proves you can operate it for something that has to work for someone else. This is that application.

What it is

An athlete-performance tracking platform

A FastAPI backend and a React frontend, deployed to the same Kubernetes cluster shown in the infrastructure diagram — not a sandbox namespace, the same cluster, behind the same ingress, trusting the same certificate authority.

Training & nutrition logging

Structured daily logging with a deterministic progression engine — rule-based load recommendations computed from logged RPE and technique, not a model guessing.

LLM-assisted features

A food photo is analyzed against a third-party LLM API for a nutrition estimate; a scheduled job compiles a weekly report the same way. The API key never touches a manifest — it's delivered as a Kubernetes secret sourced from the same secrets store as everything else.

Object storage for media

Progress photos are proxied through the backend into an in-cluster object store — never a public presigned URL, never exposed directly.

SSO-gated access

Login is OIDC against the same identity provider that fronts every other internal application — one account, one session model, everywhere.

Architecture

Where a request goes

The request never touches a port opened on a home network — it arrives through an outbound-only Cloudflare Tunnel running inside the cluster itself. The dashed line is the only place a credential changes hands with the outside world — a login redirect to the identity provider. Everything after that is a session token, not a password.

client browser identity provider SSO / OIDC login redirect session token edge Cloudflare Tunnel frontend React SPA backend FastAPI secret: LLM api key data PostgreSQL object storage progress photos secrets store shared with infra third party LLM API photo analysis, weekly report
Deploy workflow

Every release is the same five steps

No manual kubectl edits, no hand-run SQL. A change to the application is a change to Git, run through this sequence.

01

Build the image

Backend and frontend each build to a versioned container image.

02

Push to the private registry

Images never leave infrastructure I control — no public registry dependency.

03

Rolling deploy

Kubernetes replaces pods without downtime; the previous version stays up until the new one is healthy.

04

Schema migration

Database changes run as an explicit, versioned migration step — never an ad hoc statement against production.

05

Health check

The release isn't done until the application confirms it's actually serving traffic correctly.

What this demonstrates

Beyond standing up services

Secrets in application code, done right

The third-party API key is a Kubernetes secret sourced from the same vault as infrastructure credentials — never a plaintext env var in a repo, never hardcoded in an image.

SSO as a default, not an afterthought

The application's login is the same identity provider and session model as every operational tool in the stack — one fewer identity system to secure, not one more.

Repeatable, auditable releases

Every deploy follows the identical five-step sequence — nothing about shipping this application is tribal knowledge.

Product thinking, not just platform thinking

Securing a platform nobody uses is an exercise. This is infrastructure put under load by a real, daily-used application.

FastAPI React PostgreSQL Alembic MinIO Docker Keycloak OIDC Cloudflare Tunnel Claude API (Anthropic) Kubernetes CronJob

Same cluster, same certificate authority, same identity provider as the infrastructure overview — this isn't a demo environment bolted on the side.

← See the full infrastructure diagram