Skip to content

GitHub Actions Coverage Maven Central Repository

The atoms of your platform

Hexagon is a microservices toolkit written in Kotlin. Its purpose is to ease the building of server applications (Web applications or APIs) that run inside a cloud platform.


The Hexagon Toolkit provides several libraries to build server applications. These libraries provide single standalone features1 and are referred to as "Ports".

The main ports are:

  • The HTTP server: supports HTTPS, HTTP/2, WebSockets, mutual TLS, static files (serve and upload), forms processing, cookies, CORS and more.
  • The HTTP client: which supports mutual TLS, HTTP/2, WebSockets, cookies, form fields and files among other features.
  • Template Processing: allows template processing from URLs (local files, resources or HTTP content) binding name patterns to different engines.

Each of these features or ports may have different implementations called "Adapters".

Hexagon is designed to fit in applications that conform to the Hexagonal Architecture (also called Clean Architecture, Onion Architecture or Ports and Adapters Architecture). Its design principles also fit into this architecture.

Hello World

Simple Hello World HTTP example.

import com.hexagonkt.http.server.jetty.serve

lateinit var server: HttpServer

 * Start a Hello World server, serving at path "/hello".
fun main() {
    server = serve {
        get("/hello/{name}") {
            val name = pathParameters["name"]
            ok("Hello $name!", contentType = ContentType(TEXT_PLAIN))

You can check the code examples and demo projects for more complex use cases.


Hexagon's goals and design principles:

  • Put you in Charge: There is no code generation, no runtime annotation processing, no classpath based logic, and no implicit behaviour. You control your tools, not the other way around.

  • Modular: Each feature (Port) or adapter is isolated in its own module. Use only the modules you need without carrying unneeded dependencies.

  • Pluggable Adapters: Every Port may have many implementations (Adapters) using different technologies. You can swap adapters without changing the application code.

  • Batteries Included: It contains all the required pieces to make production-grade applications: logging utilities, serialization, resource handling and build helpers.

  • Kotlin First: Take full advantage of Kotlin instead of just calling Java code from Kotlin. The library is coded in Kotlin for coding with Kotlin. No strings attached to Java (as a Language).

  • Properly Tested: The project's coverage is checked in every Pull Request. It is also stress-tested at TechEmpower Frameworks Benchmark.

Not in Scope

  • Kotlin Native: because of the added complexity of Kotlin Native, focus will be set on the JVM platform, native binaries' generation will rely on GraalVM.



It is an interface for a task. The toolkit ports are designed to work on their own. For example: you can use the http_server module without importing the templates one, and the other way around (taking only the dependencies you need for your application).

Each Port may have different implementations (Adapters).

Ports cannot be used by themselves and in their place, an adapter implementing them should be added to the list of dependencies.


They are implementations of a functionality (Port) for a given product/technology. Clients should only use ports' code (not Adapters specific code), this makes them easy to switch among different adapters with minimum impact.

Adapters are independent of each other, and you can use several adapters for the same port in a single application. For example, you could use many Template adapters to support several template engines.

http_client_jetty, and http_server_jetty are examples of this type of module. Adapter names must start with their Port name.


Module that provide functionality that does not depend on different implementations, like core. These modules can depend on several Ports, but never on Adapters. An example would be the Web module that uses http_server and template Ports, but leaves clients the decission of picking the adapters they want.


Singleton object to manage a cross toolkit aspect. I.e., Serialization, Logging or Templates.

Hexagon Extras

The libraries inside the hexagon_extra repository provide extra features not bound to different implementations (rely on ports to work). They will not use dependencies outside the Hexagon toolkit.

  • Web: this module is meant to ease web application development. Provides helpers for generating HTML and depends on the HTTP Server and Templates ports.
  • Schedulers: Provides repeated tasks execution based on Cron expressions.
  • Models: Contain classes that model common data objects.


How Hexagon fits in your architecture in a picture.

✏️ Note

Using this toolkit won't make your application compliant with Hexagonal Architecture (by its nature, no tool can do that), you have to provide a layer of abstraction by yourself.



Ports with their provided implementations (Adapters).

HTTP Server Netty, Netty Epoll, Jetty, Servlet
HTTP Client Jetty
Templates Pebble, FreeMarker, Rocker
Serialization Formats JSON, YAML, CSV, XML, TOML

Module Dependencies

Module dependencies (including extra modules):

graph TD
  http_server -->|uses| http
  http_client -->|uses| http
  web -->|uses| http_server
  web -->|uses| templates
  rest -->|uses| http_server
  rest -->|uses| serialization

  1. Except the Core module that contains a set of utilities like logging. However, some of these capacities can be replaced by other third party libraries.