Why these apps exist
Purpose-built tools, not another giant system
Clerk of Court offices already run large case management systems. What's often missing are small, well-scoped tools for specific recurring tasks — redacting sensitive information from a scanned filing, auditing a batch of guardianship cases, tracking who reviewed what and when. This site collects a few of those helper apps, built as independent, containerized services rather than bolted onto an existing platform. Each one is scoped to a single job, deployable on its own, and disposable if it stops being useful.
Live examples
Apps running on this domain
Both apps below are early-stage prototypes running on synthetic, made-up case data — not real court records — while the workflows and access controls are being worked out.
Redaction Reviewer
Walks a reviewer through a filing before it goes on the public record, applying different redaction standards depending on case type — standard financial-identifier redaction, or a heightened standard for sexual-offense and child-abuse cases. Includes an admin panel for managing reviewers and the underlying redaction rule sets.
Frontend: Azure Static Web Apps • API: FastAPI on Azure Container Apps • Auth: Microsoft Entra ID
Open app.caernarvon.net →Guardianship Audit
A workflow tool for auditing guardianship case files: creating audits, assigning them to reviewers, uploading supporting documents, and tracking status — including take-over and unlock actions when an audit needs to be reassigned. Every view and status change is logged for accountability.
Frontend: Azure Static Web Apps • API: FastAPI on Azure Container Apps • Auth: Microsoft Entra ID
Open gaapp.caernarvon.net →Development
How these apps get built
Each helper app is two small services — a browser frontend and a backend API — both packaged as Docker containers from day one, even during local development, so "it works on my machine" also means "it works in the cloud."
Scope narrowly
One app, one job — e.g. "review and redact a filing," not "manage every case."
Build in containers
API and frontend each get a Dockerfile; a docker-compose file runs the whole stack locally.
Use synthetic data
Development and demo environments run on fake case data — never real filings.
Layer in auth
Single sign-on (Entra ID / OIDC) is added early, not bolted on before launch.
Testing
Testing before anything touches real records
Because these tools eventually sit near sensitive court records, testing leans conservative:
Unit tests
Redaction rules, audit-state transitions, and permission checks are tested in isolation.
Integration tests
The containerized API and a test database run together in CI, exercising real HTTP calls.
Container scanning
Every image is scanned for known vulnerabilities before it's allowed to deploy.
Staging with fake data
A staging deployment, identical to production, runs on synthetic cases for sign-off.
Deployment
Container-based deployment, cloud-agnostic by design
Because everything ships as a Docker container, the same image can run on any major cloud with only configuration changes — no rewrite. The apps above currently run on Azure; the table shows the equivalent building blocks on AWS and Google Cloud if a future app needs to land elsewhere.
| Building block | Microsoft Azure | Amazon Web Services | Google Cloud |
|---|---|---|---|
| Run the container | Azure Container Apps | ECS on Fargate / App Runner | Cloud Run |
| Host the static frontend | Azure Static Web Apps | Amplify Hosting / S3 + CloudFront | Firebase Hosting / Cloud Storage + CDN |
| Store container images | Azure Container Registry | Elastic Container Registry (ECR) | Artifact Registry |
| Sign-in / identity | Microsoft Entra ID | Amazon Cognito | Identity Platform |
| App database | Azure Database for PostgreSQL | RDS for PostgreSQL / Aurora | Cloud SQL for PostgreSQL |
| Secrets | Azure Key Vault | Secrets Manager | Secret Manager |
| CI/CD pipeline | GitHub Actions → ACR → Container Apps | GitHub Actions → ECR → ECS/App Runner | GitHub Actions → Artifact Registry → Cloud Run |