KrakenD Community Edition: a stateless Go API gateway driven by one JSON file

The problem KrakenD CE solves, and who feels it

A client team wants one endpoint that returns data assembled from three services. Without a gateway, either the client makes three calls and merges the payloads, or one backend grows an aggregation route that exists only to serve the frontend. KrakenD CE takes that job. The README describes content aggregation, composition and filtering, and says the gateway can "Decouple clients from existing services" so you can create new APIs without changing existing API contracts.

The intended user is a platform or backend team running microservices that wants a Backend For Frontend layer without writing and maintaining that layer in application code. The README frames the appeal as easy integration, a transition path to microservices, and low operational cost, and it lists platform-agnostic deployment as a goal, so Kubernetes and on-premises are both in scope. It is not aimed at someone who needs a graphical control plane. Configuration is a file, and the README points at GitOps and declarative configuration as the lifecycle model.

Stateless by design: what that means for your cluster

The architectural claim in the README is that every KrakenD node operates independently, with no coordination and no centralized persistence. That single sentence drives most of the operational consequences. There is no shared cache to warm, no leader to elect, and no session store to keep alive. Scaling out means starting more processes with the same configuration file; the README calls this "true linear scalability".

The cost is that configuration lives in the process. Change krakend.json and each node has to pick it up, which in practice means a restart or a rollout of the deployment. That is a reasonable trade for a GitOps workflow, where the file is the artifact and the rollout is the deploy. It is a poor fit if you expect to add a route at runtime and have every node agree within seconds. The repository layout reflects the same model: a cmd directory for the binary, a router_engine.go, an executor.go and a proxy_factory.go at the top level, plus a builder directory that assembles the pieces. The binary is the configuration's runtime, not a service with a mutable database behind it.

The extension surface is similarly explicit. go.mod lists the middleware modules compiled into the community build, including krakend-ratelimit, krakend-jose, krakend-cors, krakend-circuitbreaker, krakend-lua, krakend-martian, krakend-cel, krakend-otel and krakend-opencensus. If a capability is not in that list, the community edition does not have it out of the box, and the README's own framing is that you reuse external tools rather than putting everything in the gateway.

Installing KrakenD CE with Docker and running a first config

The README is direct about distribution: KrakenD is packaged in several formats and you do not need to clone the repository unless you want to build the binary yourself. The simplest path is the official Docker image. This command starts the gateway and publishes port 8080.

docker run -it -p "8080:8080" krakend

According to the README, you then open http://localhost:8080/__health and the gateway answers. That health endpoint is the signal that the process is up and listening; it says nothing about whether your backends are reachable. Stop the container with CTRL-C.

The image ships a placeholder configuration. The Dockerfile writes the file at build time with a single line, and the container entrypoint runs the binary against that path.

RUN apk upgrade --no-cache --no-interactive && apk add --no-cache ca-certificates tzdata && \
    adduser -u 1000 -S -D -H krakend && \
    mkdir /etc/krakend && \
    echo '{ "version": 3 }' > /etc/krakend/krakend.json

The same file shows the runtime contract: the process runs as user 1000, the working directory is /etc/krakend, and the default command is the run subcommand pointed at that JSON path.

ENTRYPOINT [ "/usr/bin/krakend" ]
CMD [ "run", "-c", "/etc/krakend/krakend.json" ]

EXPOSE 8000 8090

So the real first task is replacing /etc/krakend/krakend.json with your own configuration. The README links to the designer at designer.krakend.io for generating a first config rather than showing one inline. Mount your file over that path and the same command starts your gateway instead of the placeholder. Note the two exposed ports in the Dockerfile, 8000 and 8090, differ from the 8080 used in the README's run example; check which port your own configuration declares before you publish anything.

If you prefer to build from source, the Makefile sets GOLANG_VERSION and the README says to check the required Go version there, then run make build. Without a local Go toolchain, make build_on_docker uses the golang container instead.

Where KrakenD CE is the wrong tool

The stateless model is the limitation. Any feature that assumes shared state across nodes has to be solved outside the gateway. Rate limiting is the clearest case: go.mod shows krakend-ratelimit is compiled in, and the README lists multi-layer rate limiting with bursting, load balancing and a circuit breaker. But a per-node counter is not a global quota. If you need a hard cluster-wide limit, the state has to live somewhere else, and the README's own position is that you reuse existing tools rather than expecting the gateway to hold that state.

A second boundary is extensibility. The README lists Go plugins, Lua scripts, Martian and Google CEL as extension points, and go.mod confirms the Lua, Martian and CEL modules are dependencies of this repository. Go plugins are a different matter: they are compiled artifacts tied to a Go toolchain and platform, which makes them a heavier operational commitment than editing a JSON file. Treat any plugin-based requirement as a build and release problem, not a configuration change.

The third case is organisational. If your team expects a UI to click through routes, or an API to add and remove endpoints on a running fleet, this is the wrong shape. The repository presents a binary with a config file and a CLI; nothing in the repository describes a mutable control plane.

KrakenD CE compared with Kong and other gateway approaches

The obvious alternative for many teams is Kong. The difference is where configuration lives and what the process is allowed to do. Kong's model centres on an admin API and a datastore that the gateway nodes read from, which is what makes runtime reconfiguration and a shared plugin ecosystem possible. KrakenD CE inverts that: the file is the source of truth, the process is stateless, and there is nothing to coordinate between nodes. If you want to add a route without a deploy, Kong's approach is the one that matches the requirement. If you want every routing decision to be reviewable in a diff and reproducible from a file, KrakenD CE's approach is the one that matches.

A second alternative is doing the work in application code, either in each service or in a dedicated BFF service. That gives you a real programming language and full test tooling, at the cost of owning the aggregation logic, the retries, the timeouts and the middleware yourself. KrakenD CE moves that into configuration, which is cheaper to change and harder to unit test in the conventional sense. A third option is a general-purpose reverse proxy such as nginx or Envoy. Those handle routing and TLS well, but response composition across several backends is not their primary job, and the README's aggregation and format-transformation features are the reason to pick KrakenD CE over them.

The trade is consistent: KrakenD CE gives up runtime mutability and a rich plugin marketplace in exchange for a stateless process and a single declarative artifact.

Maintenance, releases and what the licence permits

The repository is not archived and the last push was on 2026-09-21. Recent releases are v2.13.11 on 2026-09-08, v2.13.10 on 2026-08-20 and v2.13.9 on 2026-08-14, so patch releases arrive on a short cadence. The Makefile pins VERSION to 2.13.11, which tells you the released artifact and the source tree are meant to line up.

Upgrade cost is mostly configuration cost, not runtime cost. The Dockerfile's default config carries a version field, and the Makefile derives SCHEMA_VERSION by taking the first two components of the version, so major and minor versions are the axis that matters for schema compatibility. A patch bump should be a redeploy. A minor bump is the point to re-validate your krakend.json against the schema for that line before rolling it out to every node, because a stateless fleet has no staged migration path: every node gets the same file or none do.

KrakenD CE is distributed under Apache-2.0, and the LICENSE file sits at the repository root. Apache-2.0 is a permissive licence that allows commercial use and modification, and it includes a patent grant. It also requires that you preserve copyright and licence notices and state significant changes when you redistribute. That is the general shape of the licence; whether your particular redistribution or plugin-linking arrangement is compliant is a question for your own counsel, not something this article can settle. Note also that the README distinguishes the community edition from the commercial product, so check which distribution a feature belongs to before you plan around it.

Editorial conclusion

Adopt KrakenD CE if you want an edge layer whose behaviour is fully described by a JSON file you can review in a pull request, and if you are willing to run one process per node with no shared state. Do not adopt it if you need a gateway with an admin API or a control plane that reconfigures nodes at runtime; the repository shows a CLI that reads a config file at startup. Before committing, verify three things against your own traffic: that the version 3 schema in your krakend.json passes the check command, that the endpoints you expose behave correctly when a backend times out, and that the plugin or Lua path you plan to use is one the community edition actually ships in go.mod.

Frequently asked questions

Official sources

1. krakend/krakend-ce on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases