Dotkernel API describes itself as production ready, and it is — but the phrase covers less ground than most people assume, and the difference is worth naming.
What Ships in the Box
A REST API needs a lot of machinery before it can serve a single useful request. Dotkernel API brings all of it already assembled: a readable middleware pipeline, OAuth2 authentication, role-based access control, request validation, standardised error responses and a generated OpenAPI specification. None of that is scaffolding you finish yourself. It is written, tested and documented, and it is the reason you can go from an empty project to a working endpoint in an afternoon.
That is what production ready means here. The application is complete.
What You Still Own
What it does not mean is that everything a public API needs on the day it goes live is included. Around the application sits a second layer, and that layer is yours:
- Traffic control. Nothing limits how fast a client can call your endpoints. Your login endpoint will answer a brute-force attempt as patiently as it answers a real user.
- An API gateway. Certificates, per-customer quotas, API keys, edge caching and a web application firewall all live in front of the application, not inside it.
- Federated identity. Dotkernel API issues its own tokens. If your organisation signs in through Keycloak, Auth0, Microsoft Entra ID or Okta, connecting the two is work you do.
- Somewhere for errors to go. Errors are written to a file on the server. They are not sent to Sentry or any other tracking service, which means that by default, nobody is told when something breaks.
- Health checks and monitoring. There is no endpoint a load balancer can ask "are you actually working?", and no metrics coming out of the application at all.
- Caching and background work. Responses are not cached, and email is sent while the user waits.
None of these are bugs. Most of them are decisions.
Why the Line Is Drawn There
Rate limiting is the clearest example. It genuinely belongs in your infrastructure, where it can protect every node at once, rather than inside application code that only sees its own traffic. The same argument applies to certificates, secrets and log shipping. A framework that shipped opinionated versions of all of these would be a framework you spend your first week fighting.
The real problem was never the missing pieces. It was that nobody wrote down which pieces were missing. A team can reasonably read "production ready", deploy on Friday, and only discover on Monday that the login endpoint has no rate limit — not because they were careless, but because nothing told them that half was theirs.
Where the Line Is Moving
Some of it is moving inward. There are open proposals to add a health check endpoint, to investigate a rate limiting middleware for demonstration purposes, and to extend caching. The boundary is not fixed, and it is being discussed in the open.
Start Here
We have added a page to the documentation that names every gap, says whether it belongs in your application or in the platform in front of it, and gives you the concrete thing to configure for each one. It closes with a short ordered checklist of what to do before you go live.
Read it before your first deployment, not after: