Java and Kotlin comprehensive backend framework
Kora builds the application graph at compile time, generates transparent highload-grade source code, and gives cloud-native services easy, simple, blazing fast and already familiar production JVM stack from day one.
A STEP development process for interns, engineers, and AI agents: Simple, Transparent, Efficient, Predictable.
Familiar modules, clients, repositories, and controllers use direct, synchronous Java and Kotlin, with typed contracts and generated implementations. The same patterns carry across HTTP, OpenAPI, gRPC, data, messaging, resilience, and configuration, so your existing JVM experience applies throughout the stack.
Open the generated source and follow the real execution path, from dependency wiring to request handling and database calls. Replace default components, customize behavior, and add integrations through explicit, typed contracts—without fighting the framework or reverse-engineering hidden runtime behavior.
Explicit code, focused docs, runnable examples, and official Kora AI-Skills reduce cognitive load and the framework context you keep in your head. Engineers and AI agents develop STEP by STEP, using precise compiler feedback and fast tests to learn, build, verify, and refine services.
Framework optimizations are already built in, so developers can focus on business code without spending time tuning internals or keeping performance hacks in their heads. Low CPU and memory overhead, fast readiness, resilience, graceful shutdown, metrics, and tracing support efficient, stable, predictable, observable production services.
A TechEmpower Single query (external): responses per second for one database query per request. Higher is better.
For a single service, raw performance is rarely the goal — most services handle their load comfortably on either framework, so it is easy to conclude that efficiency is irrelevant here. For one service in isolation, that is true.
Engineers often see the system only from their own vantage point — their service, their repository, their machine, at best their own production stand — and through that lens the conclusion holds. But step back to the level of a company's whole technical infrastructure and the picture, along with the priorities, looks very different.
Because nothing runs as a single instance. A production service is redundant by default: at least two instances per data center, so a rolling deploy or a lost node never takes it down, and usually a second data center for regional failover — another two instances. That is four or more running copies of every service before a single real user arrives.
This is where per-instance footprint stops being about speed and becomes about cost. A heavier runtime reserves more memory and CPU just to start and stay healthy within an acceptable time — headroom you pay for on every redundant copy, whether or not it is doing meaningful work.
It is all about scale. Take that one service and multiply it out: a couple of instances for redundancy, then across two data centers, then every service the team owns, then every team in the department, then every department in the business line, then every business line in the company — and on top of all that, the spare CPU and RAM reserved for peak events like Black Friday, sitting idle most of the year. And operating infrastructure at this scale is nothing like buying a CPU or a PC for local use: every reserved core and gigabyte also carries its share of on-site operations staff, electricity, cooling, networking, and data-center overhead, billed every single month. The per-instance difference that looked negligible is now multiplied by tens of thousands. A lighter runtime like Kora turns performance you never needed into reserved memory and CPU you simply stop paying for — the same reliability, on far fewer cores.
Figures are illustrative, not measured — real numbers depend on your services, JVM settings, SLAs, peak headroom, and cloud pricing. The shape is what matters: footprint × redundancy × services × teams × departments × business lines × peak reserve.
Kora does not pursue breadth for its own sake, wrap every possible technology behind a framework-specific abstraction, or replace every functionality of other frameworks. It takes proven, widely used backend practices and pushes them further: less runtime machinery, fewer competing styles, clearer contracts, and lower cognitive overhead.
A Swiss Army knife offers a tool for almost any situation, but rarely does everything equally well. Kora focuses on a targeted set of tools, each purpose-built for its specific task.
Use only the modules you need, replace or customize their components, and add your own modules and integrations through the same explicit application model.
Kora focuses on essentials of production backend development and aims to make that path exceptionally direct, transparent, and as efficient as possible.
Kora just works.
Simple. Transparent. Efficient. Predictable.
That same discipline is what makes Kora easier for engineers to develop, debug, and maintain: components are wired explicitly, mistakes are caught by the compiler as readable errors instead of runtime surprises, and every generated class reads like code an engineer would write by hand. That same clarity also makes Kora a natural fit for development with AI agents—nothing hides behind reflection or dynamic proxies, so an agent can open the generated sources, trace a request end to end, and trust what it sees just as easily as a person can.
One STEP at a time—for engineers and AI agents alike.
95%+ of Kora's functionality is covered by documentation—step-by-step guides, module references, and runnable examples. No need to piece together answers across dozens of tabs and scattered Stack Overflow discussions. The official AI skill kora-skills makes working with Kora even easier for AI agents.
Learning Kora today can be as simple as installing the official kora-skills skill and asking your agent — it consults the skill, then teaches straight from the official guides and examples.
Start small, add only integrations your service needs, and keep every dependency in controll.
Components, constructor injection, modules, typed configuration, and application startup in familiar Java and Kotlin. Virtual-thread-first: direct, synchronous code with no reactive chains or callbacks.
Wiring is checked and generated at compile time, so mistakes surface as clear compiler errors instead of runtime surprises—explicit, typed code with a fast feedback loop for engineers and AI tools alike.
HTTP servers, declarative clients, request mapping, interceptors, management endpoints, and strongly typed OpenAPI generation. Spec-first: build servers and clients from your OpenAPI contract with a strongly typed generator and rich options.
One consistent repository model for JDBC and Cassandra, with generated implementations, compile-time mappings, query macros, and explicit control over data access.
Messaging, RPC, storage, workflow engines, and infrastructure integrations built around the same explicit programming model.
Validation, caching, resilience, transactions, scheduling, security, and logging generated at compile time without runtime proxies.
Metrics, tracing, structured logging, context propagation, health probes, and graceful shutdown integrated from the start.
Replace, decorate, or complement nearly any component and adapt framework behavior through an explicit, compile-time application graph.
Kora keeps HTTP contracts explicit, generated, and observable without hiding request handling behind runtime reflection.
What this gets youExplicit code, strong types, precise compiler feedback, and almost no magic — the same qualities that make a codebase approachable for a junior joining the team make it tractable for an AI agent. Kora brings them to Java and Kotlin, so building services gets easier — both for people and for the new AI tools that help them.
A real iteration loop: the agent writes code, the compiler answers, it fixes and moves on — most mistakes caught before anything runs.
Every change is checked on two levels. First, compile-time DI, annotation processors, and typing catch structural errors already at build time. Then, thanks to very fast application-context startup, you can run full component and integration tests cheaply and often. The loop stays short: change → compile → get precise errors → start the context → verify real behavior → fix. A shorter loop helps a newcomer learn quickly and an autonomous agent work effectively.
DI, HTTP handlers, repositories, AOP, and the rest of Kora's infrastructure turn into ordinary Java/Kotlin code. You can open the generated sources, read them, and follow the real execution path. Less reflection, fewer runtime proxies, and less hidden behavior means less context to keep in your head — or for an LLM to guess. And because the whole path is transparent and direct, it's easy to trace and debug — you can just ask an AI to explain how the stack works from any point, and it reads the real code to do it.
Java/Kotlin plus compile-time DI give well-defined internal contracts, and Kora's OpenAPI Generator extends that to the external API: strongly typed server/client APIs, models, parameters, requests, and responses. A wrong assumption is more likely to turn into a compile error than a runtime bug.
Constructors, interfaces, @Component, @Module, and @KoraApp describe the application graph directly in the source. It's easier to see what depends on what, where a component is created, and which contract it implements — without reconstructing the state of a runtime container in your head.
A small set of direct, orthogonal abstractions shrinks the space of possible solutions. That matters for a newcomer and for an LLM alike: less chance of mixing different API generations, programming models, and incompatible framework approaches.
Kora tries to stay close to JDBC, Kafka, gRPC, HTTP, and other core technologies instead of building a separate framework-specific world. These are abstractions familiar to most Java developers — proven in production for years and already second nature. So most of what you — or a model — already know about Java/Kotlin and standard technologies applies directly to Kora code.
The same explicitness, strong typing, precise compiler feedback, and minimal magic make Kora approachable for an engineer joining the project and predictable for the tools working alongside them.
Fast readiness helps horizontal scaling absorb peak load faster and thin framework internals avoids heavy startup SLA spikes during rolling deployments. Lower is better.
Startup and time-to-readiness read as local developer ergonomics. Across a service fleet they are an operational cost driver — in provisioned infrastructure and in engineer time.
p95 latency during a rolling deploy. A fresh Kora instance reaches steady-state latency almost immediately; a heavier runtime holds an elevated tail above the SLA threshold for longer while the JIT warms up.
Seconds per instance × the whole fleet × every restart → fewer machines, a smaller bill, and a faster loop. Kora builds its graph at compile time and starts up as parallel as possible, with a far smaller warm-up footprint.
Base principals of Kora engineering decisions keeps services transparent, fast to start, easy to maintain.
The dependency container is built and validated during compilation from @KoraApp, @Component, @Module, and submodule declarations. Missing or ambiguous dependencies fail before the service starts.
Kora avoids runtime Reflection API, dynamic proxies, and runtime bytecode generation for the graph. Generated readable source that can be inspected, maintained, debugged, and reviewed by human or AI.
Kora uses carefully selected, fast, optimized integrations and asks you to enable only the modules your service needs. Teams do not have to research which web server, HTTP client, database approach, Redis client, or messaging integration should become the internal standard before building the service.
Kora uses native Java and Kotlin language constructs to declare framework mechanisms instead of forcing developers into a foreign programming model. HTTP handlers, Kafka listeners, repositories, config interfaces, and aspects feel natural in the language you already use, while compile-time generation handles the repetitive work.
Readable generated sources, compile-time errors, focused documentation, and examples make onboarding easier. New developers can inspect what the framework did, verify behavior quickly, and ask AI to navigate real implementation code instead of guessing hidden runtime state.
Proxy-heavy frameworks can make annotations feel simple until behavior depends on hidden runtime proxy rules, self-invocation, reflection, or container-specific conventions that change from one version to another. Kora keeps the mechanism transparent: generated source and docs hold the context, so developers do not need to memorize annotation folklore or keep invisible framework state in their heads.
Kora is based on highload-grade production optimizations from the first request: fast startup, explicit dependency graphs, generated adapters, and lean module integrations. Developers do not need to read hundreds of articles, watch hundreds of talks, spend thousands of hours benchmarking framework internals, or tune the framework itself before shipping. It is already done inside Kora. Just start writing services.
Kora favors one recommended solution based on JVM best practices instead of many competing framework styles. Teams spend less time writing internal rules, preparing talks about correct usage, or debating which abstraction should be allowed.
You do not need a giant community to trip over millions of edge cases, search through millions of non-working answers, write millions of questions, and produce endless conference talks explaining how the framework really works and why it is not in the documentation. Kora just works: the docs are direct, examples are practical, generated code is readable, and AI can explain the actual implementation instead of reverse-engineering hidden magic.
Test the service through the same explicit component graph it uses in production. Inject test components, replace dependencies, override configuration, keep component tests fast, and add Testcontainers-backed integration tests when real infrastructure matters.
Tracing, metrics, structured logging, probes, resilience, and graceful shutdown for all modules are designed as framework capabilities rather than late add-ons. The operational contract remains visible in generated and handwritten code.
Follow the guided setup, use the official examples, or jump straight into the module documentation for the stack you already know you need.