> For the complete documentation index, see [llms.txt](https://kerno.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kerno.gitbook.io/docs/references/supported-technologies.md).
# Supported Technologies
Overview of Kerno's supported technologies
### **Supported Coding Agents**
Kerno works with any coding agent that supports MCP, including Claude Code, Cursor and Codex. See the [Quickstart](/docs/getting-started/quickstart.md) to connect yours. We're constantly adding new technologies, so if you want us to support your stack next, [let us know here](https://join.slack.com/t/kerno-community/shared_invite/zt-3fzrjxgog-voatSyyKY78uDj6QaNW4OQ).
### **Supported Backend Languages**
Your scenarios are always written in TypeScript and reach your application the way its clients do, over HTTP for routes, through an MCP client for MCP tools, and through your message broker for background consumers. The language your service is written in does not affect how tests run. What it affects is how Kerno discovers your routes.
For the frameworks below, Kerno detects routes from your code. When detection finds no routes in an application, Kerno's analysis searches the code for them itself. A route that detection misses in an application where it finds others stays off the list until you ask for a test on it by method and path, and then Kerno locates its handler.
| Language | Frameworks with route detection |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| TypeScript / JavaScript | Express, NestJS, Fastify, Koa, Hono, Hapi, AdonisJS, Elysia, Next.js App Router and Pages Router API routes, Remix / React Router v7, tsoa, SvelteKit, Nuxt, Astro |
| Python | Django, Flask, FastAPI, Litestar, Sanic, Tornado, Pyramid, Bottle, Falcon, aiohttp |
| Java | Spring, Quarkus, Jersey, RESTEasy, Dropwizard, Micronaut, Vert.x Web |
| Kotlin | Ktor, Spring, Micronaut |
| Scala | http4s, Akka HTTP, Pekko HTTP, Play |
| Go | Gin, Echo, Chi, Fiber, GoFrame, gorilla/mux, net/http |
| Ruby | Rails, Sinatra, Grape |
| PHP | Laravel, Symfony, Slim, Drupal, Utopia (Appwrite) |
| C# | ASP.NET, FastEndpoints |
| Rust | Axum, actix-web, Rocket |
| Swift | Vapor |
For SvelteKit, Nuxt and Astro, detection reads page and API paths from the file layout without their HTTP method, and SvelteKit `+server` endpoints go undetected. Ask for a test on one by method and path, and Kerno locates its handler.
Kerno also reads AWS deployment files. HTTP routes declared in an AWS SAM template are detected, and SQS-triggered functions in a Serverless Framework `serverless.yml` are detected as background consumers.
Don't see your framework? [Let us know](https://join.slack.com/t/kerno-community/shared_invite/zt-3fzrjxgog-voatSyyKY78uDj6QaNW4OQ). Route detection is added as plugins, so new frameworks land quickly.
### **Supported External Dependencies**
These are the dependencies Kerno can connect to directly, for setting up and verifying state that your API cannot express. See [Environment Setup](/docs/core-concepts/environment-setup.md).
| Dependency | Status |
| -------------------------------------------------- | --------- |
| PostgreSQL | Supported |
| MariaDB | Supported |
| MySQL | Supported |
| MongoDB | Supported |
| Redis | Supported |
| Kafka | Supported |
| RabbitMQ | Supported |
| Azure Service Bus | Supported |
| Amazon SQS | Supported |
| DynamoDB | Supported |
| ClickHouse | Supported |
| Azure Blob, Queue, and Table Storage (via Azurite) | Supported |
| S3-compatible object storage (MinIO and similar) | Supported |
| Zitadel | Supported |
| Amazon Cognito | Supported |
Kerno connects to these over the network, so embedded databases such as SQLite cannot be accessed directly. Applications backed by them are still fully testable through their HTTP API.
Zitadel and Amazon Cognito are identity providers rather than stores. Kerno reads them to obtain a test credential, and seeds no state in them.
For AWS-backed dependencies, an `aws` block carries your shared credentials and region, which every AWS SDK client a scenario builds then picks up. The individual kinds, such as `aws-sqs` and `dynamodb`, declare what they each need on top of that.
### **Supported Protocols**
| Protocol | Status |
| --------------------------------------------------------------- | --------------------------------------------- |
| HTTP (S) | Supported |
| MCP (Streamable HTTP) | Supported |
| Background consumers (Celery, Graphile Worker, broker messages) | Supported |
| WebSocket | Coming Soon |
| gRPC | Coming Soon |
| GraphQL | Coming Soon |
### **Supported Authentication Methods**
Kerno reads your source code to work out how each entry point authenticates, then builds a per-entry-point recipe for obtaining and presenting a credential. These are the mechanisms it handles reliably.
| Authentication Methods | Status |
| --------------------------- | --------- |
| Bearer Authentication (JWT) | Supported |
| Session Tokens | Supported |
| API Key (Custom Header) | Supported |
| HTTP Basic Authentication | Supported |
| OAuth 2.0 | Supported |
{% hint style="info" %}
When Kerno signs a token itself, it uses HMAC algorithms (`HS256`, `HS384`, `HS512`). If your verifier requires an asymmetric algorithm such as `RS256`, Kerno obtains a real token from your login flow instead of constructing one.
Flows that require a person to complete a hand-off with an external identity provider cannot be automated. Kerno reports those scenarios as blocked rather than faking a credential.
{% endhint %}
{% hint style="info" %}
If you encounter issues or have questions, [message us on Slack](https://join.slack.com/t/kerno-community/shared_invite/zt-3fzrjxgog-voatSyyKY78uDj6QaNW4OQ), and we'll gladly help.
{% endhint %}