In one line
Getting a container to run is the beginning; keeping it observable and upgradeable is the product.
Kairo Auth Stack is a private test inbox built on my own domain. Cloudflare Email Routing receives messages, a Worker processes them, D1 stores them, and local Docker services plus diagnostics handle maintenance. It is useful for testing login emails on sites you own, assigning aliases to projects, and learning how a message travels from a domain into a database.
The project goes beyond receiving mail: it turns configuration, runtime data, diagnostics, upgrades and rollback into a process I can still understand months later.
The problem
Each component could run on its own. The difficult part appeared after connecting them:
- a missing email could originate in DNS, Email Routing, a Worker or D1;
- a service could appear to start successfully and still fail a later health probe;
- following a
latestimage made upstream changes difficult to inspect; - environment files and runtime data were too easy to publish by accident.
The project focuses on those operational gaps.
What I built
One command surface
.\kas.ps1 init
.\kas.ps1 doctor
.\kas.ps1 update
.\kas.ps1 snapshot
.\kas.ps1 test
Initialization, diagnostics, upgrades and audits no longer depend on one-off terminal commands.
Safer defaults
The stack refuses to start while CHANGE_ME placeholders remain. Real environment files, runtime data and local audit snapshots stay outside Git.
Layered diagnostics
The Doctor command checks Docker, the target service, dependency discovery, placeholder values and local configuration hygiene.
Upstream auditing
Before an upgrade, the tooling backs up local configuration and records image metadata. Private snapshots make version comparison repeatable without publishing third-party source.
Email infrastructure
Email → Email Routing → Worker → D1 → local test task
The documentation turns this chain into small checks, making it possible to identify the failing layer instead of restarting everything blindly.
Current result
- test mail can be received on a self-owned subdomain;
- a Worker processes messages and stores them in D1;
- one unified CLI;
- four maintenance scripts;
- placeholder and weak-default blocking;
- repeatable upstream snapshots and upgrade records;
- a private troubleshooting record and a safety-reviewed public retrospective;
- explicit security and third-party boundaries.
Open-source boundary
The orchestration, maintenance tooling and public documentation are MIT licensed. Third-party runtimes remain under their own licenses and terms, and the project does not redistribute source or images with unclear licensing.
The public project covers general deployment maintenance, security checks and version auditing. It does not publish third-party account automation, CAPTCHA bypass, credential-export or platform-evasion instructions.
Status
Version 0.1.0 passes local structure, Compose, PowerShell syntax, image-link and credential-leak checks. The GitHub repository has not been published yet; the project remains an actively tested Kairo experiment.