Compile-Time Certainty, No Runtime Magic
Kora checks the application graph, contracts, and generated code at compile time. Diagnostics and readable source with no runtime surprises.
Java and Kotlin comprehensive backend framework
Ship fast services without magic.
Kora builds the application graph at compile time, generates transparent highload-grade source code, and gives cloud-native services exceptionally fast and familiar production JVM stack from day one.
0
runtime reflections
95%+
of functionality covered by docs, guides, and examples
OTel
metrics and tracing across modules
Built for teams that want speed, control and clarity.
Kora keeps familiar JVM development, but moves framework work into the compiler where it can be checked, generated, and understood. Magic non-sence no more.
Simple. Coherent. Familiar.
The abstractions are ones you already know—modules, clients, repositories, controllers—as direct, synchronous Java and Kotlin. Nothing new to learn: the same familiar patterns just become simplier, direct, typed, generated, and transparent across HTTP, OpenAPI, gRPC, data, messaging, resilience, and config.
Peak Performance
by Design
Performance follows from compile-time decisions, generated code, thin abstractions, and selected high-performance integrations from startup to request processing—already tuned inside Kora, so you just pick a JVM and write business code.
Production-Grade,
Cloud-Ready
Production defaults cover OpenTelemetry, structured logs, probes, lifecycle, graceful shutdown, and resilience policies for predictable services under load.
More throughput per core, fewer machines to pay for.
A TechEmpower Single query (external): responses per second for one database query per request. Higher is better.
Snapshot
Single query
Metric
Responses / sec
ntex tokio (Rust)
197,868
Kora JDBC Repository
181,904
Quarkus JPA Repository
180,624
Quarkus jOOQ
166,896
Micronaut Data JDBC
166,221
Helidon MP JDBC Client
130,367
Spring JDBC Template
127,355
Micronaut Data JPA Reactive
99,436
Ktor CIO JDBC Driver
98,409
Spring Data JDBC
83,793
Spring Data JPA
83,343
Spring Data R2DBC Reactive
60,745
Micronaut Data JPA
33,544
Values use the "Single query" interval from the linked external results. This is a local benchmark with a local environment and no network latency to the database, so all event-loop reactive systems running on EventLoop threads get a performance boost from it.
Open TechEmpower snapshot
Why efficiency matters even when you don't need the throughput
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.
Watch it scale across an organization
1service instance
×2instances for redundancy
×2data centers for failover
×20services in the team
×8teams in the department
×6departments in a business line
×4business lines in the company
×1.5peak headroom for spikes (Black Friday)
Provisioned instances (incl. peak reserve)
0
How much more the Other framework needs than Kora
0 GB · 0 vCPU · ≈ $0 / yr
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.
Watch the services multiply
one service
1 services company-wide
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.
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.
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 is why it also fits naturally into AI-assisted development—nothing hides behind reflection or dynamic proxies, so a model can open the generated sources, trace a request end to end, and trust what it sees just as easily as a person can.
HTTP
Data access
Messaging
Configuration
Resilience
Telemetry
Integrations
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.
Learn by example
Docs without the bloat.
95%+ of Kora's functionality is covered by documentation—step-by-step guides, module references, and runnable examples—no 40-tab detective work required. There is also kora-skills, an official AI skill that makes working with Kora even easier.
95%+
functionality documented
39+
step-by-step guides
35+
module references
▾ See how an AI agent teaches you Kora
▴ Hide the walkthrough
Docs without the bloat.
95%+ of Kora's functionality is covered by documentation—step-by-step guides, module references, and runnable examples—no 40-tab detective work required. There is also kora-skills, an official AI skill that makes working with Kora even easier.
95%+
functionality documented
39+
step-by-step guides
35+
module references
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.
claude code — learning-kora
Opus 4.8
A controlled stack,
one module at a time.
Start small, add only integrations your service needs, and keep every dependency in controll.
Simple, easy, familiar
Familiar Java and Kotlin idioms, compile-time dependency injection, one clear solution per problem, and virtual threads built in from the ground up—so blocking code stays simple at high concurrency.
Transparent, no runtime magic
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.
Servers, clients, OpenAPI
HTTP servers, declarative clients, request mapping, interceptors, management endpoints, and strongly typed OpenAPI generation.
Kora repositories
One consistent repository model for JDBC and Cassandra, with generated implementations, compile-time mappings, query macros, and explicit control over data access.
Kafka, gRPC, S3, and more
Messaging, RPC, storage, workflow engines, and infrastructure integrations built around the same explicit programming model.
Production essentials
Validation, caching, resilience, transactions, scheduling, security, and logging generated at compile time without runtime proxies.
Observability by design
Metrics, tracing, structured logging, context propagation, health probes, and graceful shutdown integrated from the start.
Built to be extended
Use only the modules you need, replace individual components, or build first-class Kora modules for any library without fighting the framework.
HTTP
Servers, clients, OpenAPI
Kora keeps HTTP contracts explicit, generated, and observable without hiding request handling behind runtime reflection.
What this gets you
Example.java
Easy to reason about, easy to maintain
A stack you can reason about.
Explicit 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 stack you can reason about.
Explicit 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.
claude code — kora-shop
Opus 4.8
A real iteration loop: the agent writes code, the compiler answers, it fixes and moves on — most mistakes caught before anything runs.
Fast, strict feedback loop
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.
No runtime magic
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.
Strong typing, end to end
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.
Explicit architecture
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.
One clear way
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.
Thin abstractions
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.
Fastest to boot,
fastest to serve.
Fast readiness helps horizontal scaling absorb peak load faster and thin framework internals avoids heavy startup SLA spikes during rolling deployments. Lower is better.
10x PetClinic services with full production integrations in a Docker container, 1 CPU and 1 GB memory, startup and readiness.
Average across 5 runs on MacBook Pro 2019 Intel i7-9750H(Similar to EPYC 7763 according to GeekBench 5 Single-Core Benchmark).
10x PetClinic services with full production integrations. Clean artifact build: ./gradlew clean distTar (Kora) / bootJar (Spring — layered jar in the Docker image), run with --no-build-cache, --no-configuration-cache, --no-parallel, -Dorg.gradle.daemon=false.
Average across 5 runs on MacBook Pro 2019 Intel i7-9750H(Similar to EPYC 7763 according to GeekBench 5 Single-Core Benchmark).
10x PetClinic services with full production integrations. Incremental artifact build with Gradle build cache, configuration cache, daemon, parallel and multi-module build, and incremental compilation enabled.
Average across 5 runs on MacBook Pro 2019 Intel i7-9750H(Similar to EPYC 7763 according to GeekBench 5 Single-Core Benchmark).
Why fast startup and readiness save real money
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.
Elastic autoscalingReadiness in seconds lets a horizontal autoscaler add capacity within the load spike, instead of holding a statically over-provisioned baseline.
Shorter deploy windowsEach rolling replacement reaches readiness sooner, narrowing the interval of reduced capacity and the associated error-budget and SLA risk across the fleet.
Scale-to-zero & spotFast cold start makes scale-to-zero and preemptible/spot instances viable: capacity is released when idle and restored on demand in seconds, shifting reserved cost to usage-based.
Low-utilization servicesAdmin panels, internal tools and scheduled jobs are dominated by baseline runtime overhead rather than request load; a thin runtime lowers the per-instance memory and CPU floor — a Kora service can run on as little as 0.1 vCPU, potentially 0.05 — reclaiming capacity across a large low-traffic fleet.
Development and CI feedbackIntegration and black-box suites start the full application on each run; lower startup time cuts wall-clock per iteration and per pipeline stage, shortening the feedback loop — the scarce resource being engineer time.
Lower SLA impactCompile-time wiring, thin abstractions and no runtime reflection make warm-up far smaller — not zero — so a new instance is close to steady-state throughput from the first requests, keeping the p95–p98 tail during deploys and scaling well below a warm-up-bound runtime.
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.
Kora is based.
Base principals of Kora engineering decisions keeps services transparent, fast to start, easy to maintain.
Compile-time dependency injection
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.
Generated source code, not runtime magic
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.
Fine-grained and best-performant modules
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.
JVM abstractions that look familiar
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.
Get context out of your head
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.
No magic, no frustration
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.
Highload-grade optimized out of the box
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.
One problem, one solution
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.
No lore required, Kora just works
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.
Simple and fast testing
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.
Enterprise-grade by design
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.
Build your first Kora service.
Follow the guided setup, use the official examples, or jump straight into the module documentation for the stack you already know you need.