PromptForge
A foundry for prompts: discover, test, version and compare them across models, on a ten-service Kubernetes estate that deploys itself.
FBN.2025.02
PromptForge
Architect and sole engineer
Node.js, NestJS, Kubernetes (K3s), Terraform, 2025
10
microservices in production
0
seconds of downtime per release
100%
of the infrastructure written as code
5
gates between a commit and production
The problem
Teams working across several language models keep their best prompts in scattered documents and chat threads. Nothing is versioned, nothing is reproducible, and no one can say which wording produced which answer.
The approach
Ten NestJS services, each owning a single concern, run on K3s over Oracle Cloud. Terraform raises the infrastructure, Ansible configures the nodes, and Helm releases every service with autoscaling, rolling updates and self-healing probes. A GitHub Actions pipeline lints, tests, builds, Trivy-scans and ships without a second of downtime, while Prometheus and Grafana keep watch over every pod.
The outcome
A self-healing platform where a commit reaches production without a hand touching a server, and every prompt carries the full history of how it came to be.
What it does
5 capabilitiesPrompts versioned like source
Every prompt can be diffed, rolled back and traced to the output it produced, the way code has been treated for decades.
One prompt, many models
The same wording runs against several models side by side, so a comparison is a view rather than an afternoon.
An arena and a leaderboard
Prompts meet head to head in a battle arena, and a leaderboard keeps the record of which ones win.
Infrastructure that heals
Liveness and readiness probes restart what fails; horizontal autoscaling answers load before anyone notices it.
Releases that pass inspection
No image reaches the cluster without clearing a Trivy vulnerability scan in CI.
The strata
How it standsEdge
Vercel-hosted frontend, entering the cluster through an API gateway
Services
Ten NestJS microservices: auth, prompts, testing, versioning, comparison and more
Orchestration
K3s with Helm charts, horizontal autoscaling and rolling updates
Provisioning
Terraform on Oracle Cloud, node configuration through Ansible
Delivery
GitHub Actions: lint, test, build, Trivy scan, zero-downtime deploy
Observability
Prometheus scraping every pod, Grafana dashboards, liveness alerts
The judgments
The reasoning, on the recordChose
K3s
over a managed Kubernetes service
A lightweight distribution kept the control plane cheap enough to run ten services on a small node pool, with exactly the same Helm charts and kubectl workflow.
Chose
Terraform and Ansible
over configuring the cloud console by hand
The entire environment can be destroyed and rebuilt from the repository. Nothing lives only in someone's memory.
Chose
Trivy as a blocking gate
over scanning images after deploy
A vulnerable image never reaches the cluster, and fixing it before merge costs far less than a rollback.
The cabinet
Captured from the live build
PromptForge, plate I
Screen capture, 2560 × 1600
prompt-forge-frontend.vercel.app, MMXXVI
Next exhibit — III
AssetStream