A modern, JVM‑based framework for fast cloud applications

Build modular microservices and serverless applications with compile-time dependency injection, fast startup, low memory overhead, and GraalVM Native Image support.

Compile-time DINo runtime reflectionGraalVM native ready
Sally, the Micronaut mascot
Your first Micronaut app

$ sdk install micronaut

$ mn create-app com.example.demo

Application created at ./demo

$ cd demo && ./gradlew run

Startup completed in 235ms. Server Running: http://localhost:8080

$ ./gradlew nativeRun

Startup completed in 15ms. Server Running: http://localhost:8080

One application model, from endpoint to database

The same annotations declare an HTTP endpoint, the client that calls it, the repository behind it, and the JSON that crosses the wire — then boot the whole thing in a test.

Same annotations across server, client, and repository
Routes, queries, and JSON resolved by the compiler
Tests boot the real application context
A controller in a few annotations
import io.micronaut.http.annotation.*;

import java.util.Collections;
import java.util.Map;

@Controller("/hello")
class HelloController {

    @Get
    Map<String, String> index() {
        return Collections.singletonMap("message", "Hello World");
    }
}

Coming from a legacy JVM framework?

Legacy frameworks resolve the application model with reflection and classpath scanning while the application starts. Micronaut keeps the same familiar programming model but moves that work to the compiler — and the cost profile changes with it.

Resolved at runtime, on every startup
What a legacy reflection-based framework does each time your application boots.
Classpath scanning on every startup
Reflection metadata assembled while the app boots
Proxies generated on the fly at runtime
Startup cost and memory grow with each new bean
Wiring errors surface when the app starts in production
Resolved at build time, once
What Micronaut does instead, before your application ever ships.
Injection and AOP metadata generated by the compiler
No classpath scanning or reflection to start
Startup work stays flat as the codebase grows
Wiring errors fail the build, not the deployment
The same properties that make GraalVM Native Image practical

The rest of the platform

Native executables, data access, and the build plugins that produce them — maintained alongside the framework rather than bolted on beside it.

GraalVM native executables
Compile applications with GraalVM into native executables that start in milliseconds and hold a fraction of the memory of a JVM deployment.
Same appJVMNative
Startup235 ms15 ms
Memory356 MB42 MB
Reachability metadata generated with your beans
Container images and AWS Lambda custom runtimes
The same suite runs as native tests
Micronaut Data, across your datasources
Repository interfaces the compiler writes the queries for — over SQL, reactive, and document stores alike.

Access styles

Jakarta DataJDBCJPA / HibernateR2DBCHibernate Reactive

Datasources

PostgreSQLMySQLMariaDBOracleSQL ServerSQLiteH2ANSI SQLMongoDBAzure Cosmos DB
Queries written by the compiler, not assembled at runtime
Repositories and entity mappings validated at compile time
No runtime model scanning, and no reflection overhead
Build plugins for Gradle and Maven
One plugin per build tool folds native images, containers, and test infrastructure into the build command you already run.

Native builds. nativeCompile, nativeRun, and nativeTest — or mn:native-image and mn:graalvm-resources.

Container images. dockerBuild and dockerBuildNative, with CRaC checkpoints and a push goal.

Test Resources. Databases and brokers started for dev and test runs, then torn down.

AOT optimization. Micronaut AOT analysis moves more work off startup and into the build.

Config validation. Configuration checked before packaging, per environment.