What is KrakenD?

KrakenD is a stateless, declarative API gateway written in Go. Its engine is the Lura Project, hosted by the Linux Foundation, and the Community Edition is open source under Apache 2.0; KrakenD Enterprise adds commercially licensed features and support. The whole gateway is defined in a single configuration file, typically krakend.json: each endpoint lists one or more backends, and KrakenD calls them, merges and reshapes the responses, and returns one payload to the client. Because all behavior lives in that file, every node is identical and there is no database to coordinate.

Why use it in the API Lifecycle?

Aggregation: One endpoint can fan out to several backends concurrently and merge the results, so a client makes one call instead of four. The X-KrakenD-Completed header tells the client whether every backend succeeded.
Response shaping: allow and deny filter fields, mapping renames them, group nests a backend’s response under a key, and target strips a wrapper such as data, so clients receive only what they use.
Zero-trust forwarding: By default KrakenD forwards no client headers (except Content-Type), no query strings and no cookies to backends. Each one has to be listed in input_headers or input_query_strings.
Traffic controls: Rate limiting, circuit breakers, concurrent calls, shadow proxying, bot detection and IP filtering are configured per endpoint or per backend.
Authentication: Validates JWTs, API keys, Basic Auth and mTLS at the edge, and handles OAuth 2.0 client credentials toward backends.
Protocol bridging and telemetry: Connects to REST, gRPC, GraphQL, SOAP, Lambda and message brokers such as Kafka, RabbitMQ and SQS, and exports metrics and traces through OpenTelemetry.

Best Practices

Run krakend check -t -l -c krakend.json in CI on every change. --lint validates the file against KrakenD’s published JSON schema, catching unknown keys, wrong types and misplaced components, and --test-gin-routes starts the service briefly to catch conflicting routes.
Run krakend audit alongside check. It evaluates the configuration against CIS-inspired security rules (a missing rate-limiting strategy, the /__debug/ endpoint left enabled, insecure connections allowed) and reports each finding with a rule ID and severity. A clean audit means those rules passed, not that the API is secure.
Keep the zero-trust default. List exactly the headers each backend needs in input_headers, such as Authorization or an Idempotency-Key, and avoid "*": forwarding everything passes client-controlled headers like X-Forwarded-For straight to services that may trust them.
Treat X-KrakenD-Completed: false as a partial response. If your clients cannot tolerate missing fields, check that header rather than assuming a successful status means a full payload; KrakenD omits the cache header on incomplete responses for the same reason.
Know which limiter answers with which status. The per-client limit (client_max_rate) rejects with 429 Too Many Requests, but the endpoint-wide max_rate rejects with 503 Service Unavailable, which clients and dashboards will read as an outage. Counters are kept in memory per node, so the effective cluster limit is the configured limit times the node count. See API Rate Limiting.
Use flexible configuration (FC_ENABLE=1 with FC_TEMPLATES, FC_SETTINGS and FC_PARTIALS) to split a large krakend.json into Go templates and per-environment settings, run check against the rendered output, and keep them in Git so every gateway change is reviewed like code. OpenAPI import and export is an Enterprise feature; on the Community Edition, keep the OpenAPI document as the contract and test the gateway against it.