# jorisvink/kore: writing web APIs in C or Python with privilege separation by default

> Kore is an event driven web application framework for C and Python that ships with TLS on by default and sandboxed worker processes. It is a good fit for small, security sensitive services and a poor fit for teams that want an ecosystem of ready made middleware.

**jorisvink/kore** — An easy to use, scalable and secure web application framework for writing web APIs in C or Python. || This is a read-only mirror, please see https://kore.io/mail and https://kore.io/source for information on how to contribute via the mailing lists.

- Repository: https://github.com/jorisvink/kore
- Website: https://kore.io
- Stars: 3,826 · Forks: 322
- Language: C
- License: ISC
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/jorisvink-kore

## What Kore is for, and who it is aimed at

Kore is a web application platform for writing scalable, concurrent web processes in C or Python, according to its README. The audience is narrow and specific: developers who are willing to write their handlers in C or Python and who care more about process isolation and TLS defaults than about having a large catalogue of plugins to install. The README states that Kore is used in high assurance cryptographic devices, machine learning stacks and aerospace, and that it runs from embedded platforms up to high performance servers. That range tells you the design centre is small binaries and predictable resource use, not rapid application scaffolding.

The problem it addresses is the amount of security plumbing a C service normally needs before it can safely face the network. Kore builds TLS in by default, isolates private keys in a separate process, and sandboxes worker processes on OpenBSD with pledge and on Linux with seccomp. A developer writing a JSON API in C would otherwise have to wire up a TLS library, decide where the key material lives, and add a sandbox step. Kore treats those as part of the framework rather than as optional hardening you add later.

## The process model: event loop, workers, and a separate key manager

Kore uses an event driven architecture over epoll or kqueue, with per CPU worker processes. The source layout reflects this: src/worker.c, src/connection.c, src/domain.c and src/net.c sit alongside src/pool.c and src/timer.c. A request arrives on a worker's event loop, is matched to a domain and a handler, and is answered without a thread per connection. That is the classic single threaded event loop model, replicated across CPUs by running several worker processes rather than by sharing one loop.

Privilege separation is not a bolt-on. There is a dedicated key manager, with src/keymgr_openssl.c compiled in when the TLS backend is openssl, so private keys live in a process that is not the one parsing requests. The Makefile also shows that when TLS_BACKEND is set to something other than openssl, ACME support is rejected outright with an error. Modules can be reloaded on the fly, and the README states that private keys and certificates can be reloaded without a restart, which matters for certificate rotation on long lived services.

The application itself is compiled into a dynamic library or a single binary. The Makefile exposes KORE_SINGLE_BINARY for the latter, which sets KORE_TMPDIR at compile time. That choice has consequences: a single binary is easier to deploy, but the temporary directory path is baked in when you build, not chosen at run time.

## Building and installing Kore from source

Kore is not distributed as a package in the README given here. The README points at https://kore.io/releases/4.2.3 for the latest release, and the normal build path is a plain make from the repository root. The stated requirement is openssl 1.1.1, libressl 3.x or openssl 3. Optional features need libcurl 7.64.0 or higher, pthreads, libpq, Python 3.6+ or Lua 5.4+ depending on which ones you enable.

```bash
cd kore
make
make install
```

The Makefile defaults PREFIX to /usr/local, so make install places the kore binary in /usr/local/bin, headers in /usr/local/include/kore and shared files in /usr/local/share/kore. If you need a different location, override PREFIX at build time rather than moving files afterwards, because the prefix is compiled into the binary as a preprocessor definition.

Optional features are enabled with environment variables set before make. The README lists them explicitly.

```bash
PGSQL=1 PYTHON=1 make
```

That command compiles in asynchronous PostgreSQL support and Python page handlers. The README warns that certain build flavors cannot be mixed and you will be met with compilation errors, so enable only what you need. The Makefile confirms one such rule: ACME combined with a TLS backend other than openssl is a hard error.

For a first real application, the repository ships examples under examples/. Each example directory contains its own README with build and usage instructions. The examples cover cookies, headers, parameters, json, websocket, pgsql, python-echo, python-async, tasks, upload, sse, tls-proxy and more. Starting from examples/generic and editing the handler is the shortest path to a running service, and the kodev tool in the kodev/ directory is the build helper the project ships for that workflow.

## Where Kore is the wrong choice

The obvious limitation is language. Handlers are written in C or Python, and Python support is optional at build time. If your team writes Go, Rust, Java or TypeScript, Kore offers nothing for you. There is an examples/cpp/ directory, but the README's own description of the platform names C and Python only.

The second limitation is platform and architecture. The README states support for Linux, OpenBSD, FreeBSD and macOS, and only x64, arm and aarch64. A Windows service is out of scope, and so is any 32 bit target. If you deploy on Windows, Kore is simply not an option.

The third is ecosystem. There is no package registry of Kore middleware in the README. Anything you need beyond the built-in features (parameter validation, websockets, JSON, asynchronous PostgreSQL) you write yourself. That is a deliberate trade: fewer dependencies, more code you own.

Finally, the release history deserves attention. The most recent release listed is 4.0.0 from 2020-08-31, while the last push to the repository was on 2026-09-02. Development has clearly continued between releases, so anyone tracking a stable version should read RELEASE.md and the mailing list rather than assume the tagged release reflects current code. The repository is a read-only mirror; contributions go through the mailing lists at kore.io, not through pull requests here.

## How Kore compares to nginx plus a C module, or to a Python WSGI server

The closest structural alternative is nginx with a custom C module. Both give you an event driven core, TLS, and a compiled handler. The difference is where the security boundary sits. With nginx you get a general purpose server whose configuration language and module ABI you must learn, and privilege separation depends on how the master and worker processes are configured. Kore instead compiles your application as the server: the module is the program, privilege separation is the default rather than a configuration choice, and the key manager is a separate process by design.

The other alternative is a Python WSGI or ASGI server such as gunicorn behind a reverse proxy. That path gives you the Python package ecosystem and far faster iteration. The difference in approach is that Kore's Python support is an optional compile time feature layered onto the same C event loop, not a separate runtime. You get the isolation model, but you give up the ability to pip install a middleware library and expect it to work. If your service is mostly business logic over a database, the Python ecosystem is worth more than the sandbox; if it is a small, long lived endpoint handling sensitive material, the reverse is true.

## Maintenance, licence and upgrade cost

Kore is licensed under the ISC license, a permissive licence functionally similar to MIT and BSD. The practical implication is that you can link it into proprietary software and redistribute binaries, provided you keep the copyright notice and licence text. This is not legal advice; check the LICENSE file and your own counsel before shipping.

The repository is not archived, and the last push was on 2026-09-02. Development is ongoing, but the tagged releases are sparse: 3.1.0 in 2018, 3.3.0 in 2019, 4.0.0 in 2020. The documentation link in the README points at docs.kore.io/4.2.0, and the release download page points at 4.2.3, so the documentation and the tagged releases in the repository are not in step. Anyone pinning a version should confirm which documentation matches the code they build.

Upgrade cost is driven by the build flags. Because features are compile time, moving to a new version means re-checking your feature set against the Makefile, particularly the combinations that are rejected. A single binary build also bakes in KORE_TMPDIR, so an upgrade that changes the deployment layout requires a rebuild rather than a configuration change. Budget for that.

## Conclusion

Adopt Kore if you are writing a small, security sensitive HTTP or websocket service in C or Python and you want privilege separation and TLS without assembling them yourself. Do not adopt it if you need a large third party module ecosystem or a language runtime other than C and Python. Before committing, verify that your OpenSSL version satisfies the stated requirement (openssl 1.1.1, libressl 3.x or openssl 3), that your target platform is one of Linux, OpenBSD, FreeBSD or macOS on x64, arm or aarch64, and that the optional features you need were compiled in, because the Makefile rejects some combinations at build time.

## FAQ

### What is jorisvink/kore?

Kore is a web application platform for writing scalable, concurrent web processes in C or Python, built with a secure by default approach that includes privilege separation and TLS by default. It supports Linux, OpenBSD, FreeBSD and macOS on x64, arm and aarch64.

### How do I install Kore?

Clone the repository or download a release from kore.io, then run make followed by make install from the repository root. Optional features such as PostgreSQL or Python support are enabled by setting environment variables like PGSQL=1 or PYTHON=1 before running make.

### Which OpenSSL version does Kore require?

The README states the requirement is openssl 1.1.1, libressl 3.x or openssl 3. The Makefile defaults TLS_BACKEND to openssl, and setting a different backend disables ACME support.

### Can I use Kore on Windows?

No. The README lists Linux, OpenBSD, FreeBSD and macOS as supported platforms, and only x64, arm and aarch64 architectures.

### How do I contribute to Kore?

The repository is a read-only mirror. The README directs patches to the patches@kore.io mailing list and questions to users@kore.io, with signup by sending an empty email to the list address plus +subscribe.

## Sources

- [jorisvink/kore on GitHub](https://github.com/jorisvink/kore)
- [License: ISC](https://github.com/jorisvink/kore/blob/master/LICENSE)
- [Project website](https://kore.io)
- [README](https://github.com/jorisvink/kore/blob/master/README.md)
- [Releases](https://github.com/jorisvink/kore/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jorisvink-kore