Tyk Gateway: an open source API and AI gateway for REST, GraphQL, gRPC and MCP

What Tyk Gateway solves, and who ends up running it

Any service that faces the internet eventually needs the same five things: identity checks, request quotas, rate limits, usage records, and a place to change routing without redeploying the backend. Tyk Gateway is a Go reverse proxy that supplies those five as middleware rather than as a library you wire into each service. The README describes it as "cloud-native, open source, enterprise-ready" and says it is provided "Batteries-included, with no feature lockout", which in practice means the open source build ships the authentication, analytics and rate limiting features rather than reserving them for a paid tier.

The audience is narrower than the tagline suggests. If you run one HTTP service behind nginx and your rate limiting is three lines of config, Tyk is more moving parts than you need. It fits teams that have crossed the point where routing rules live in a spreadsheet: multiple protocols, multiple teams owning different APIs, and a compliance request for per-key usage data. The protocol list matters here. REST with OpenAPI, SOAP, GraphQL, gRPC, TCP and MCP are all listed as supported, and the MCP entry is the unusual one: the gateway parses JSON-RPC 2.0 and applies policy per tool, resource and prompt, instead of treating agent traffic as opaque HTTP.

How the gateway actually processes a request

The repository layout tells you more about the architecture than the marketing copy does. Top-level directories include gateway/, middleware/, apidef/, storage/, policies/, rpc/, coprocess/, goplugin/ and event_handlers/. That split maps to a chain: apidef holds API definitions, middleware holds the request pipeline stages, policies holds the access rules that keys are bound to, storage abstracts Redis and other backends, and event_handlers plus rpc cover the control plane and webhook side.

Redis is not optional in the documented setup. The Docker Compose file in the repository declares a tyk service built from the local Dockerfile, attached to a proxy network, exposing container port 8080 on host port 9000, and mounting ./tyk.conf.example as /opt/tyk-gateway/tyk.conf. It includes docker/services/redis.yml and docker/services/httpbin.yml. The Makefile likewise offers db-start with redis-start and mongo-start targets, where redis-start runs redis:4.0-alpine on 127.0.0.1:6379. So the data flow is: request arrives, the gateway resolves the API definition, runs the middleware chain (auth, rate limit, transform, analytics), forwards to the upstream, and writes session and analytics state to the datastore. That statefulness is the design decision everything else follows from.

Installing Tyk Gateway with Docker and adding your first API

The README recommends the Docker path as the quickest start and points at a separate repository, tyk-gateway-docker. Clone it, change into it, and bring the stack up. The README gives these exact commands:

git clone https://github.com/TykTechnologies/tyk-gateway-docker
cd tyk-gateway-docker
docker-compose up

The README notes you can add the -d flag to run detached. You should see the gateway and Redis start. To confirm the gateway is alive, the README uses the hello endpoint:

curl localhost:8080/hello

The documented output is a JSON body with a status field set to "pass", a version field, and a description of "Tyk GW". Note the port: the README's Docker walkthrough answers on 8080, while the docker-compose.yml inside this repository maps host port 9000 to container port 8080. Pick the one that matches the deployment you actually started.

From there the README sends you to the "adding your first API" documentation page for the Open Source instructions. That page is not reproduced in the repository, so the API definition schema is something you read on tyk.io rather than in the README. If you prefer to build from source, the Makefile has a dev target that compiles with the coprocess, grpc and goplugin build tags and runs the binary against tyk.conf:

make dev

The Dockerfile pins Go via an ARG GO_VERSION=1.26 and builds with make build, then copies tyk.conf.example to tyk.conf and sets the entrypoint to /opt/tyk-gateway/tyk.

Where Tyk Gateway is the wrong tool

The Redis dependency is the first real constraint. Sessions, rate limit counters and analytics flow through it, so if Redis is unavailable the gateway's auth and quota middleware is degraded or blocked depending on configuration. A stateless edge proxy that keeps counters in memory has a different failure mode, and for a single-node deployment behind a load balancer that never scales past one process, the datastore is cost without benefit.

The second constraint is the licence file. The repository metadata reports NOASSERTION, while the README carries an MPL 2.0 badge. Those two signals disagree, and the repository root does contain a LICENSE.md, so the file is the authority. If your organisation has a policy of only approving dependencies with a machine-readable SPDX identifier in package metadata, that mismatch is a blocker until someone reads the file. This is not a legal opinion, and I am not giving one; it is a fact about what the metadata says versus what the badge says.

The third is scope creep. The README presents three products on one page: the open source Gateway, Tyk Self Managed (a management control plane with GUI and developer portal), and Tyk Cloud (the hosted SaaS version). Nothing in the README says the open source build includes the GUI or the developer portal. Teams that evaluate Tyk by reading the feature list and then deploy the open source Gateway can find that the dashboard they expected lives in a different product. Verify which binary you are installing before you promise a portal to anyone.

Tyk versus Kong: two different bets on configuration

Kong is the comparison people reach for, and the difference is not speed claims. Both are Go or Lua-based proxies with plugin ecosystems and both lean on a datastore for cluster state. The divergence is in how APIs are declared. Tyk's apidef package and its OAS support mean an API definition is a first-class object the gateway imports, with OpenAPI 2.x and 3.0.1 listed as import formats for scaffolding. Kong's model centres on declarative configuration and its own entity schema, with the Admin API or decK as the usual management surface.

A second difference sits in the AI and agent path. Tyk's README documents an MCP Gateway that puts the proxy in front of remote Model Context Protocol servers and applies policy per tool, resource and prompt, plus an API to MCP feature that generates an MCP proxy from a REST API without hosting a separate MCP server. That is a specific claim about where the parsing happens: Tyk says it parses JSON-RPC 2.0 rather than treating MCP as opaque HTTP. If your interest in Tyk is agent traffic rather than classic REST, that is the feature to test, because it is the part of the product that is least like a conventional gateway.

Maintenance cadence, upgrade cost and the licence question

The last push to master was on 2026-09-21, and the most recent tagged release in the list is v5.14.0 from 2026-07-07. There is also v5.15.0-alpha1 from 2026-06-25 and v5.12.0-alphafips5 from 2026-02-12, so the release stream includes alpha tags alongside stable ones. The repository is not archived. That combination, a recent push plus a stable release roughly two months earlier, is the picture to plan upgrades around: pin to a tagged stable version rather than tracking master, and treat the alpha tags as pre-release.

Upgrade cost is dominated by the datastore and the API definitions, not the binary. Because policies and sessions live in Redis, a version bump that changes how keys or policies are serialised is a migration, not a restart. The repository ships a checkup/ directory, which suggests there is tooling for validating configuration, but the README does not document a rollback procedure or a downgrade path between major versions. Plan for that gap by testing upgrades against a copy of your Redis data before touching production.

On licensing, the honest summary is that the README badge says MPL 2.0 and the repository metadata says NOASSERTION. MPL 2.0 is a file-level copyleft licence, which generally means modifications to MPL-covered files must be published under the same terms while larger works that merely combine with them can be licensed differently. That is a general description of the licence, not advice about your situation, and the LICENSE.md in the repository is what governs.

Editorial conclusion

Adopt Tyk Gateway if you need one Go binary that terminates REST, GraphQL, gRPC, TCP and MCP traffic with the same auth, quota and analytics middleware, and you accept Redis as a hard runtime dependency. Do not adopt it if you want a single-file proxy with no datastore, or if you need legal certainty about the licence without reading LICENSE.md yourself, since the repository metadata reports NOASSERTION while the README badge says MPL 2.0. Verify first that the Docker image tag you pull matches the release you intend to run, and confirm which of the three deployment paths (open source Gateway, Self Managed, Cloud) your feature list actually requires, because the README lists all three on the same page.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. TykTechnologies/tyk on GitHub