Designed so the safe path is the only path.
DevSewa is built on the security contracts of a payment fleet: an edge that owns nothing, an authority core that owns everything, and engines that are never exposed. This page describes what that means for your application.
Security model
Built so a misconfigured deploy fails closed, not open.
DevSewa runs on the same fleet contracts as the payment products next to it. These are the rules every route is reviewed against.
Edge / authority split
The public site and console are stateless. Only the authority core touches the database and the engine secrets, and it never runs on the edge.
Secrets materialised, never shipped
Every engine credential is delivered at deploy time by the fleet Secret Manager as a file. Releases, images and logs never contain one.
Tenant isolation, not tenant filtering
Scope is derived from the session or the key, never from a request body. Cross-tenant access is 403; existence is hidden with a consistent 404.
Policy at the mediation layer
MFA and e-mail verification are enforced where every call passes, so a client that bypasses your UI gains nothing.
Audit on every mutation
Application changes, key mints, sender-domain edits, completed vault operations and secret writes are recorded with actor and time.
One spelling per tenant
Tenant names are canonical. A variant is rejected with the correct spelling, never silently folded into a new customer.
Review rules
Six rules every route is checked against.
These come from the fleet security checklist that also governs the payment products DevSewa shares infrastructure with.
- 1
Authentication is not authorization
Every route proves that the signed-in session or the presented key may act on the exact target — customer, application, tenant — before it reads or writes.
- 2
Request values are selectors, never scope
A tenant, application id or user id in a body or query only selects. The authorised scope is derived server-side from the session or key.
- 3
One canonical spelling per tenant
Lowercase, digits, single underscores. A variant is rejected with the correct spelling rather than silently becoming a second tenant.
- 4
403 across tenants, consistent 404 otherwise
Cross-tenant access is refused. Where existence must be hidden, the answer is identical to “does not exist”.
- 5
No backend secret reaches the browser or the edge
Engine credentials, DSNs and secret file paths live only in the authority core, materialised from the Secret Manager.
- 6
Fail closed
A missing credential, an unreachable engine or a malformed request produces an error you can act on — never a fallback to a default tenant.
Runtime
How DevSewa itself is deployed.
The same runner and secret manager that will power Hosting run DevSewa today.
No host ports published
Services join a private network behind a TLS-terminating front proxy. The core listens on internal TLS minted by the runner.
Secrets materialised at deploy time
A courier declares, fetches and verifies every secret into files before the app starts. The running app never calls the secret manager.
Pinned internal certificates
Engine certificates are self-signed and pinned as trust anchors — verification stays on, always.
Encrypted mounts, disposable servers
Runtime state lives on encrypted partitions; a server can be rebuilt from a release and the secret store.
GET /v1/secrets/DATABASE_URL
Authorization: Bearer dsk_live_… (another application's key)
→ 404 { "detail": "secret_not_found" }
# identical to a name that does not exist
PATCH /v1/applications/8b3e… (not yours)
→ 404 { "detail": "application_not_found" }Responsible disclosure
Found something? Write to security@devsewa.com. We acknowledge within two business days and will not pursue good-faith research.
- Test only against applications you own
- Do not access other tenants’ data
- Give us reasonable time to fix before disclosure
Build on rules you did not have to write.
Create an account, register a test application and exchange your first ticket in under ten minutes.