Tyk Gateway's build tags, its two hello ports, and the legacy crypto it keeps on

The quick start curls 8080, the repository compose publishes 9000

The verification step in the README is one request:

curl localhost:8080/hello

and the expected reply is `{"status":"pass","version":"5.x.x","description":"Tyk GW"}`. That answer is worth reading closely, because the version field is masked to 5.x.x while the repository's own docker-compose.yml maps `9000:8080` for the `tyk` service and mounts `./tyk.conf.example` at `/opt/tyk-gateway/tyk.conf`. Consequence: someone who builds from the compose file in this repository and then runs the README's curl command gets an empty reply, because the gateway is on host port 9000, and the version they think they are running stays a placeholder unless they ask the binary directly. Recent tags include v5.16.0 on 2026-10-27 and v5.13.5 and v5.8.17 on 2026-10-30, with the last push to master on 2026-11-02, so the masked string hides a real spread of builds.

Three build tags decide whether coprocess, gRPC, and Go plugins exist

The Makefile sets `TAGS=coprocess grpc goplugin` and threads that variable into every build target: `build` produces the binary with `-tags "$(TAGS)" -trimpath`, `build-linux` forces `CGO_ENABLED=0 GOOS=linux GOARCH=amd64`, `build-debug` adds `-gcflags="all=-N -l"`, and `dev` builds and immediately launches the gateway against `tyk.conf`. A separate `build-plugins` target compiles three .so files with `-buildmode=plugin`, one of them under the race detector, for the plugin tests, and `install` repeats the same tag list through `go install`. Testing and benchmarking run the same tree with `go test -run=$(TEST_REGEX) -count=$(TEST_COUNT) ./...` and a matching `-bench` target. Consequence: anyone who bypasses the Makefile and runs a plain `go build ./...`, or a bare `go install`, produces a binary with none of those three code paths compiled in, so whatever those tags gate is not compiled in.

The godebug block in go.mod keeps old TLS and X.509 behaviour switched on

The module declares `go 1.26.5` and then opens a godebug block that changes defaults away from the Go standard: `tls10server=1` and `tls3des=1` keep TLS 1.0 server support and 3DES available, `tlsrsakex=1` permits RSA key exchange, `tlsunsafeekm=1` and `x509keypairleaf=0` revert two further Go defaults to older behaviour, and `x509negativeserial=1` tolerates negative serial numbers. Consequence: these are compatibility choices for old clients and old certificates, made globally for the whole process, and a reader auditing the deployment sees a gateway that will complete handshakes and accept chains that a stock Go service refuses. A compliance review should read go.mod to see which of these legacy behaviours are enabled.

The Dockerfile is the builder image, and its Go pin sits behind go.mod

The root Dockerfile never switches to a slim runtime. It starts from `golang:${GO_VERSION}-bookworm` with `ARG GO_VERSION=1.26`, installs build-essential plus zlib1g-dev, libncurses5-dev, libgdbm-dev, libnss3-dev, libssl-dev, libsqlite3-dev, libreadline-dev, libffi-dev, libbz2-dev, curl, wget, and python3, runs `go mod download` and `make build` with cache mounts, copies `tyk.conf.example` over the image's `tyk.conf`, prints the Tyk, Go, and Python versions at build time, and ends with `ENTRYPOINT ["/opt/tyk-gateway/tyk"]`. Consequence: the image it builds carries the entire toolchain and the development headers, and the base image tag 1.26 is a minor-version pin while go.mod asks for 1.26.5, so the patch level of the compiler in the image is whatever the golang tag resolves to on build day, not what the module file requires.

APIs live as files in an apps folder that Linux readers must create by hand

The four quick start steps are: create a gateway configuration file named `tyk.conf`, on Linux create an `apps` folder where the gateway saves your APIs, write a Docker Compose file that runs Tyk Gateway and Redis, then start it with `docker compose up -d`. The first API is then created through the Tyk Gateway API. The repository root has `apidef/`, `apps/`, `certs/`, `policies/` and `storage/` directories. Consequence: the Linux instruction is the only one given, so anyone on macOS or Windows has no documented location for the apps folder, and the quick start steps do not say what role Redis plays.

The full lifecycle needs a licence key, which the no-lockout line does not cover

The README advertises the gateway as provided batteries-included with no feature lockout, then describes a separate route for evaluating the whole platform. Tyk Install runs Tyk Gateway, Tyk Dashboard, the Developer Portal, Tyk Pump, Redis, and PostgreSQL with Docker Compose, preloads sample APIs and policies, and requires a licence added to an environment file:

git clone https://github.com/TykTechnologies/tyk-install
cd tyk-install/docker/self-managed
cp .env.example .env   # add your licence keys to .env
cd ../getting-started
bash start.sh

A self-managed trial has to be requested separately. Consequence: no feature lockout is a statement about the gateway binary, while the control plane, portal, and analytics around it sit behind that key, and the repository's own licensing is unsettled at the metadata level, with a LICENSE.md, README.signatures, CLA.md, and an `ee/` directory in the tree.

MCP calls are parsed as JSON-RPC 2.0 and policed per tool

For agent traffic the gateway is described as sitting in front of remote Model Context Protocol servers, parsing JSON-RPC 2.0 and applying authentication, rate limiting, and per-tool access control to every call rather than passing MCP through as opaque HTTP, with policy applied per tool, resource, and prompt. The reverse direction is also offered: an MCP proxy generated directly from a REST API in the gateway, without standing up a separate MCP server. Protocol coverage for conventional traffic is REST with native OpenAPI support, SOAP, GraphQL, gRPC, TCP, and MCP, with Swagger and OpenAPI documents in OAS 2.X and OAS 3.0.1 accepted for scaffolding. Consequence: token budgets, model routing, and guardrails across providers are assigned to a separate product, Tyk AI Studio.

Editorial conclusion

Tyk Gateway fits a team that wants a self-hosted gateway with no feature lockout in the gateway binary itself, already runs Docker or Kubernetes, and is prepared to own the surrounding platform. It does not fit anyone who expects the Dashboard, Developer Portal, Pump, or PostgreSQL to come free, since the tyk-install path asks for licence keys in .env, and it does not fit anyone who ships a tight container image, since the repository Dockerfile is the full Go build environment with headers, python3, and a sample config baked in. Before deploying, check which of the three build tags your plugin and gRPC paths need, curl the port your compose file actually publishes rather than the one in the quick start, and read the godebug block in go.mod so you know which legacy TLS behaviours are enabled on your behalf.

Frequently asked questions

Official sources

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