About these pages¶
These pages are for people changing Paduraksa: contributors and the agents that work on the code. They say how it is built and why, with the invariants, budgets and decisions a change has to respect. They are not the guide.
To use Paduraksa, start with the user guide. To run it, see Operating it.
Start here¶
- Working on the code: build, test and format, and how to write tests that don't flake.
- Overview: what Paduraksa is, how a request flows through it, the development rules and where the project stands.
Pages by area¶
| Page | What it covers |
|---|---|
| Process and hosting | The two web apps and the core host in one process, listeners and ports, the admin certificate |
| Config | Typed IDs, the data model, settings layers, and how a change becomes a snapshot |
| The hot path | The request budget, the pipeline, connection limits, HTTP/3 |
| WAF building blocks | Rate limits, access lists, rule sets, forward-auth, proof of work, error pages |
| Client IP behind Cloudflare | Trusted proxies, edge ranges, origin lockdown |
| Vault, certificates and ACME | Key material, the certificate inventory, the local CA, ACME and DNS-01 |
| Identity | Users, sessions, roles and the admin sign-in pipeline |
| Admin surfaces | The REST API, MCP, the CLI, YAML import and export |
| The dashboard | The Blazor app, drafts, conventions, first-run setup |
| Observability | Logs, metrics, live tail, analytics, health and notifications |
| Deployment | The container, compose, bare metal, SQLite tuning |
| Testing | Test levels, property tests and fuzzing |
| Threat model (full analysis) | The analysis behind the short threat model |
| Risks, spikes and milestones | What each milestone built, and the spikes that de-risked the design |
The spikes (S1, S2, S3) are the experiments behind three of those decisions.