Self-hosted API gateway: when it's worth installing Kong, Traefik or similar

"API gateway" is one of the most overloaded jargon categories in back-end architecture. The term became an umbrella for things a simple reverse proxy has done for twenty years — routing, terminating TLS, balancing between instances — mixed with things that genuinely require a dedicated component: per-client API key validation, per-user request limiting, request body transformation, aggregating multiple back-ends into a single response. The confusion sells a lot of product. And makes a lot of startups install a critical component they didn't need — paying later in latency, RAM, operational complexity and failure surface.

This post separates what each thing covers, lists the five main players with honest resource consumption numbers, and draws a practical ruler: when the reverse proxy embedded in the orchestrator is enough, when it's worth bringing up a standalone Traefik, and when you actually need a Kong with authentication plug-ins. The audience is the tech lead looking at the current stack and trying to decide whether the next pain deserves another component on the critical path — or whether the pain is fake.

TL;DR — installing a dedicated gateway is an expensive decision, keep the ruler short

A simple reverse proxy covers the trunk of the problem: HTTPS terminated, automatic Let's Encrypt certificates, routing by host and path, balancing between back-ends, health check, compression. For a typical B2B SaaS with web app + a few HTTP microservices, that's enough. No need to install Kong, no need for Tyk, no need for KrakenD.

A dedicated API gateway becomes a defensible investment when three signs appear simultaneously: you publish an API for third parties to consume (not just your own web/mobile), you need request limits per client key (not per IP), and you want interactive documentation with try-it-here for consumers. In that scenario, Kong, Tyk or Traefik with rich middlewares pay their own cost. Outside that scenario, you are adding 100–300 MB of RAM on the critical path, 1 to 3 milliseconds of latency per request, and one more component that can fall in production — in exchange for features nobody will use.

The simplest ruler we know: if your end client is a person opening a browser, a reverse proxy is enough. If your end client is a developer with an API key, consider the gateway. Everything else is variation on top of those two lines.

What a simple reverse proxy already covers, and what's still missing

Before comparing gateways, it's worth fixing the floor. A decent reverse proxy — Caddy, nginx, or the integrated router of a modern orchestrator — delivers a lot for free. This list represents the state of the art in 2026, not the historical minimum:

• HTTP/HTTPS termination with HTTP/2 and HTTP/3. The proxy speaks any modern protocol with the client and speaks clean HTTP/1.1 to the back-end if needed.
• Automatic Let's Encrypt certificates. Issuance, renewal at 60 days, error recovery. Today this is commodity — any serious router does it.
• Routing by host and path. api.example.com goes to one back-end, app.example.com goes to another, /v1/users goes to a third. Rules with prefix, regex and priority.
• Balancing between instances. Round-robin, least connections, IP hash. Enough to distribute load between replicas of the same service.
• Active and passive health check. Removes a sick instance from the pool. Re-includes it when it comes back.
• gzip and brotli compression. Negotiates with the client, compresses what's worth compressing.
• Static content cache. For immutable files, avoids hitting the back-end.
• Basic per-IP limit. Thirty requests per second per address, for example. Covers most silly abuse.
• Timeouts and retries. Fail fast, retry on an alternative back-end if applicable.
• Proxy headers. X-Forwarded-For, X-Real-IP, X-Forwarded-Proto. The back-end sees the real client.

That's a lot. For 80% of B2B SaaS web applications, it's all you need on the entry path. What a simple reverse proxy does not cover is what differentiates a gateway:

• Per-client API key validation. Each consumer gets a key, the gateway validates, identifies the client, and uses that identity for limits and auditing.
• JWT token validation with rotatable keys. The gateway downloads public keys from the issuer, validates signature and time, exposes claims to the back-end.
• Request limits per key/user/route. Client A can make 1,000 calls/hour; client B, 100. Per route, per day, with sliding window. Hard to do in a simple proxy.
• Request and response transformation. Add/remove headers, rewrite JSON body, translate between API versions.
• Versioning by header or path. Coexist with v1 clients while v2 gains traction. Deprecation policy.
• Back-end aggregation. Composite endpoint that calls three microservices and returns a unified response (back-end-for-frontend pattern).
• Request schema validation. Reject at the gateway what doesn't match the OpenAPI contract before touching the back-end.
• Documentation portal with try-it-here. Interactive page for developers to explore the API.
• Granular metrics per API key. Who called, how much, when, with what latency. Vital if the API is the product.

Each item on this second list is a feature that costs a lot to do in application code spread out. If you need most of it, a gateway pays. If you need almost nothing — which is the common case in product SaaS — the gateway is dead weight.

The five players that matter in 2026

The market has settled. There are five defensible choices for a self-hosted gateway, with reasonably distinct profiles. The RAM and latency numbers below are measured with default configuration and modest workload (a few dozen calls per second); heavy plug-ins or high volume change everything.

Kong (Lua-based, on top of OpenResty)

The best-known name in the category. Kong started in 2015 and has the largest plug-in catalog in the space — OAuth authentication, JWT validation, transformation, log to Elasticsearch, integration with external vaults, all pre-built. The open source version covers most cases; the paid one adds a more polished developer portal, fine-grained RBAC, and SLA support.

Resources: realistic minimum of 200 MB of RAM per instance, plus the database if you don't use db-less mode. Added latency of 1 to 2 milliseconds per request on a simple call. Heavy plug-ins (schema validation with large OpenAPI, complex JSON transformation) can double that.

When it makes sense: serious public API with multiple external consumers, need for catalog plug-ins, team willing to learn Lua if customization is needed. Payments company, communication platform, any business where the API is the product sold.

Gotcha: the mode with PostgreSQL puts the database on the critical path. Database down, gateway can't update configuration. Use db-less mode (declarative configuration via file) whenever possible — eliminates that dependency.

Traefik (written in Go, speaking various orchestrator proxies)

Known as a Kubernetes ingress controller, but has rich enough middlewares to cover many gateway cases. Per-client request limiting, basic JWT validation, header transformation, complex redirects, forward auth (delegating to an external service). The paid version adds commercial plug-ins and a more robust dashboard.

Resources: 50 to 100 MB of RAM, added latency of 0.5 to 1 millisecond. Automatic back-end discovery via container labels is the strong point — you don't write route configuration, it appears when the service comes up.

When it makes sense: already using Traefik as the entry router and want to avoid adding one more component; need reasonable middlewares but not Kong's giant catalog; value declarative configuration by label rather than database.

Gotcha: some advanced patterns (call aggregation, full OpenAPI validation, interactive documentation portal) don't fit in Traefik. If you need that, the temptation to "stretch" Traefik via custom plug-ins leads to complexity that Kong would solve more cleanly.

Tyk (written in Go, focus on developer portal)

The open source version delivers far more than most — request limiting per key, key management, developer portal, all in the free plan. The paid version adds multi-tenant dashboard, multi-region replication, and support.

Resources: 100 MB of RAM, added latency of 1 to 2 milliseconds. Database (Redis) is central to the architecture — request limits and counters live there.

When it makes sense: API with many external consumers, developer portal is part of the product, you want to pay less than what Kong charges for the equivalent in resources. Small teams publishing API for partners have found a good fit here.

Gotcha: fewer ready-made plug-ins than Kong. If your expected integration exists in Kong's list but not in Tyk's, the trade-off changes.

KrakenD (written in Go, no database, focus on aggregation)

KrakenD is the small gateway that specializes in aggregation. 100% file configuration, no external state, designed to compose endpoints — the client makes one call, KrakenD calls three back-ends in parallel and returns a combined response. Great for the back-end-for-frontend pattern.

Resources: 50 MB of RAM, added latency of 0.5 milliseconds. The lightest of the category. No database, no panel — everything is static configuration file.

When it makes sense: you have multiple microservices and want to expose a cleaner API to the mobile/web front-end. You don't need dynamic key management or developer portal. You like immutable configuration: change file, deploy, done.

Gotcha: everything is static. Adding a new key is a deploy. For a small team that's simplification; for an API platform with third parties self-registering, it becomes a bottleneck.

Envoy Gateway (CNCF, on top of Envoy proxy)

The serious newcomer of the list. Envoy is the very-high-performance proxy used in large service meshes. Envoy Gateway is the project that packages Envoy as an API gateway with declarative configuration. Focus on Kubernetes, high throughput, mesh integration.

Resources: raw Envoy consumes 50 to 100 MB on the data proxy; the control plane weighs more. Low added latency (< 1 millisecond) on a simple call. But operational complexity is the highest on the list.

When it makes sense: you already run a service mesh with Envoy (Istio, Consul, Linkerd with compatible proxy) and want configuration consistency between mesh and gateway. You operate at high enough scale that Envoy throughput matters (tens of thousands of requests per second).

Gotcha: for a startup with 4 servers and a few dozen requests per second, Envoy Gateway is overkill by two or three sizes. The configuration complexity doesn't pay off.

When is a simple reverse proxy enough?

This is the question that saves money. The honest answer is: in the vast majority of Brazilian B2B SaaS we see running, it is enough. The criteria for "enough":

• Audience for your API is your own application. Web, mobile, internal integrations. There are no unknown third parties calling endpoints with keys you issued.
• Authentication happens in the application, not on the path. Cookie session, JWT token issued by the back-end itself and validated by application middleware, OAuth via library inside the code. The proxy doesn't need to see the user.
• Request limit is "avoid silly abuse". Thirty per second per IP, perhaps. There is no commercial plan that limits Client A to 1,000 calls/day and Client B to 10,000.
• You don't need to combine back-ends. Each front-end call goes to one endpoint, that endpoint calls what it needs internally. No path-level aggregation.
• API documentation is internal or non-existent. No developer portal with try-it-here for third parties.
• Versioning, if it exists, is managed in code. The back-end routes internally between v1 and v2 when needed. No formal policy at the gateway.

If five of the six items above are true, installing a dedicated gateway is expensive for the real benefit. A reverse proxy embedded in the orchestrator, or standalone Caddy/nginx, covers everything.

When is a dedicated gateway worth it?

The inversion of the previous list. A gateway pays off when some of these appear:

• Public API is part of the product. You charge (or plan to charge) per API usage. Third parties register, get a key, consume.
• Limit per key/user/route is a business rule. Free plan has a ceiling, paid plan has a higher ceiling, enterprise plan is negotiated. That limit needs to live somewhere — gateway is the right place.
• Multiple back-ends need to be combined into one response. Back-end-for-frontend pattern, microservice aggregation, fan-out and fan-in. High costs in the application, modest costs in the gateway.
• Formal API versioning. You support v1 and v2 simultaneously, with announced deprecation date. Accept-Version header or /v2/ path. Legacy client can't break.
• Complex authentication. Validation of JWT issued by a third party, with public keys downloaded and cached, with automatic rotation. OAuth with multiple providers. Authentication by client certificate (mutual TLS) for inter-company integrations.
• Developer portal with try-it-here. Interactive documentation, self-service key management, usage panel for consumers.
• Per-API-key metrics. Who calls what, when, latency per consumer. Commercial dashboards, usage reports, per-client SLA.

Three or more of these criteria true, gateway is defensible. One or two, you can still solve it in other ways (authentication in the application, limit per app, structured metrics in the log).

HeroCtl integrated router — where it sits on this ruler

The router embedded in HeroCtl doesn't try to be a gateway. It covers the well-done reverse proxy side: HTTPS terminated, automatic Let's Encrypt with renewal, routing by host and path, balancing between the replicas the orchestrator brought up, health check coordinated with the agent on each node, compression, proxy headers, basic per-IP limit, retry policy on back-end failure.

What the integrated router does not do: per-consumer API key validation, per-key/user limit, body transformation, back-end aggregation, OpenAPI schema validation, developer portal. For 80% of cases where the end client is the company's own browser or mobile app, the embedded router covers the entire entry path — you don't install anything else in front.

For the 20% who need a dedicated gateway, the path is direct: install Kong, standalone Traefik, Tyk or KrakenD as another job in the cluster, behind the embedded router. The router terminates TLS at the edge, the gateway does the gateway work, the back-ends sit behind. Without ceremony, without circular dependency.

The HeroCtl control plane occupies between 200 and 400 MB per server — meaning an installed Kong adds practically the same weight as the entire control plane. Worth remembering the order of magnitude before "just install".

Comparison table — 12 criteria

The table has clear zones. The first three columns solve the entry path with low weight. The last four solve the entry path plus gateway work, with growing weight and complexity.

Typical stack by company stage

This is the ruler we recommend. Not a strict prescription — it is what we see working in Brazilian SaaS teams.

MVP (1 back-end, 1 developer). Standalone Caddy on a server, or embedded router if you're already in an orchestrator. Don't install anything. Don't think about gateway. Focus on product.

Indie hacker (3 to 5 back-ends, team of 1 to 3). Embedded router in the orchestrator, period. The entry path already covers what matters. Authentication in the application, basic per-IP limit on the proxy. Time spent with gateway is time not spent on product features.

Early startup (10 to 20 back-ends, first external API consumers). Time to evaluate. If the external API is an experiment that may still die, leave authentication in the application and limit by key in a shared library. If the API is part of the product's core promise, install standalone Traefik with authentication and limit middlewares, or Tyk OSS for the included portal. Kong at this stage is usually too heavy.

Mid startup (50+ back-ends, public API platform becomes product). Kong OSS or paid Tyk. You need plug-ins, robust portal, self-service key management, commercial metrics. Kong's weight now justifies — you're charging for API usage and the gateway is revenue, not cost.

Large company (hundreds of services, integrations with serious partners). Kong Enterprise or Envoy Gateway, depending on context. Dedicated team looking after the gateway. Formal versioning, deprecation, per-client SLA policy.

The natural migration — reverse proxy → Traefik/Tyk → Kong — works because each step solves real pain from the previous step. Skipping steps is expensive: installing Kong at the MVP phase is bringing a truck to deliver a pizza.

The 4 most common expensive gateway mistakes

The stumbles we see in production:

Installing Kong with PostgreSQL on the critical path without needing to. db-less mode exists and is perfect for most cases. Declarative configuration via file, no external dependency, no extra failure point. Many teams fall into the default configuration with database and only discover it when the database becomes unavailable and the gateway can no longer propagate changes. If you need dynamic key management (consumers self-registering), database pays off. Otherwise, db-less mode.

Not monitoring the gateway with the same severity as the back-ends. A gateway in front becomes an easily-forgotten black box. Latency grows 5 ms, error rate goes from 0.01% to 0.5%, nobody notices until the client complains. Gateway metrics (per-route latency, 4xx/5xx error rate, memory usage, configuration propagation lag) deserve their own dashboard and alerts, not just a shy inclusion in the general panel.

Custom plug-in in Lua/JS running in production. Kong allows custom plug-in in Lua. Tyk in JavaScript. Huge temptation to solve "just this transformation" at the gateway. A bug in that plug-in takes the entire gateway down — a bug you created, without load testing, on the critical path of everything. If you need custom transformation, do it in a microservice behind the gateway. Custom plug-in only with serious review, load testing, and automatic rollback plan.

Outdated gateway version. Kong, Envoy and Tyk receive CVEs (security vulnerabilities) regularly. The gateway is exposed to the internet — a relevant attack surface. An 18-month-old version is known vulnerability accumulating. Make it part of the maintenance cycle: updating the gateway is as important as updating the operating system.

Real scenarios where you should NOT install a gateway

Strong list. If you are in any of these, avoid the dedicated gateway even if the topic comes up in council:

• Web SaaS with 5 endpoints, no public external API. End client is the browser. Session authentication. Reverse proxy solves the entire entry path. Adding a gateway here is architectural vanity.
• Small team (1 to 3 developers). Kong's learning curve costs two to four weeks of total team productivity. On a 3-person team, that's a quarter of features stalled. Unless the gateway solves concrete pain today, postpone.
• Workload where sub-10ms latency is a hard requirement. Low-latency trading, real-time auction, multiplayer game. Every millisecond counts. Gateway adds 1 to 3 ms — in sensitive workload, expensive. Put intelligence in the application.
• Monolithic application without aggregation. The monolith serves the front-end directly, without composition between services. There's nothing to aggregate. Gateway is a solution looking for a problem.
• Compliance that prefers minimal attack surface. Each component exposed to the internet is one more item for audit, one more patch to apply, one more log to keep. If audit values minimalism, justify each component — gateway not covering concrete pain is a minus.

Frequent questions

Is Kong db-less stable in 2026? Yes. Declarative mode (db_less = on) is mature, recommended by Kong itself for a large part of the cases, and eliminates PostgreSQL as a dependency. You lose dynamic key management via admin API (need to deploy new configuration), but gain enormous operational simplicity. For a small team, the trade is almost always worth it.

Does Traefik do everything Kong does? No. Traefik with middlewares covers most common cases — basic authentication, simple per-key limit, header transformation, forward auth. It doesn't cover Kong's plug-in catalog, native OpenAPI validation, robust developer portal, ready-made commercial integrations. If your pain fits in Traefik middleware, stay in Traefik (lighter, simpler). If you need something from Kong's catalog, Kong.

Can I have two gateways in series? Technically yes, in practice it almost always is a symptom of confused organization. Two gateways = two configurations to maintain, two latencies summed, two failure points. The defensible case is: edge router doing TLS and basic routing, dedicated gateway behind doing specific work (key validation, aggregation). That's different from "two complete gateways in series" — it's responsibility split.

Does an API gateway replace a service mesh? No. Gateway handles north-south traffic (external client → your system). Mesh handles east-west traffic (internal service → internal service). Similar functions (authentication, limits, observability) but different scope. For a medium startup, the gateway solves the part that matters; a complete service mesh only becomes a defensible investment at larger scale. We address that boundary in service mesh: when it's worth it for small and medium SaaS.

How much latency does Kong add on a typical call? On modern hardware, with default configuration and light plug-ins (key validation + per-key limit): 1 to 2 milliseconds per request. Heavy plug-ins (full OpenAPI validation on large payload, complex JSON transformation, synchronous log to external service) can add 3 to 10 ms. Measure before and after — don't trust generic blog post numbers.

Self-hosted OAuth provider — Keycloak or Hydra? Keycloak is the standard for those wanting a robust admin panel, federation with LDAP/SAML, complete user management. Heavier (1 GB of RAM minimum, JVM). Hydra is minimalist, focuses only on OAuth/OIDC, no user management (you integrate with your existing user system). For a small team that already has its own user system, Hydra is more appropriate. For a company that wants a single place for identity, Keycloak. Both speak standard protocols, so the gateway doesn't differentiate between them.

Schema validation — OpenAPI or JSON Schema? OpenAPI (formerly Swagger) is the standard for describing HTTP API — covers paths, methods, request and response. Includes JSON Schema for describing payloads. Kong, Tyk and standalone validators speak OpenAPI directly. Pure JSON Schema is more portable (not tied to HTTP) but requires more glue. Use OpenAPI when the gateway supports it; worth keeping the contract schema alive, not outdated.

Can I do limiting in the application instead of the gateway? You can. Libraries like golang.org/x/time/rate or Redis with INCR solve per-user limit at the application level. The question is where the limit is cheaper: at the gateway, before the back-end is touched (saves back-end resources, applies before work begins) or in the application, with business rules closer to the code (easier to reason about, easier to test). For simple limits, the application is enough. For limits per commercial plan with multiple tiers and auditing, the gateway is the right place.

Can I use two different gateways on distinct routes? You can. Some companies run Kong for "product" routes (sold public API) and Traefik for "internal" routes (admin, ops, cron). The justification is that each gateway solves a different pain, and having only one would force compromise. Worth it when usage profiles actually diverge. Not worth it just for the pleasure of variety — two pieces to maintain.

Closing — start with the minimum, level up when the pain is real

The trap of the "API gateway" category is treating the decision as binary — install or not — when it is gradual. A well-done reverse proxy covers 80% of applications. The integrated router in the orchestrator covers the same 80% without a separate component. A dedicated gateway is a defensible investment when three or four signs appear simultaneously: public external API, per-key limit, aggregation, developer portal.

The honest ruler: install the minimum until concrete pain forces the next step. Skipping steps costs dearly in latency, RAM, complexity, failure surface. A small team that installs Kong "because they will need it" spends three weeks configuring something they don't use, and still has one more component to monitor.

HeroCtl delivers the lowest step embedded — integrated router with automatic TLS, balancing, health check, per-IP limit. When gateway pain appears for real, you bring up Kong, standalone Traefik, Tyk or KrakenD as another job in the cluster. Without painful migration, without ceremony.

To bring up a cluster and test:

curl -sSL https://get.heroctl.com/install.sh | sh

Community is free forever, no server ceiling, no job ceiling, no feature gate. Business adds SSO/SAML, granular RBAC, detailed auditing and SLA support. Enterprise adds source code escrow, continuity contract and 24×7 support.

Upcoming posts: service mesh: when it's worth it for small and medium SaaS and multi-tenant SaaS: real isolation between clients. The three topics together cover most of the platform decisions for a Brazilian startup in the 1 to 500 server range.

Container orchestration, without ceremony. Gateway only when the pain asks.