Tyk open source gateway vs Tyk Self-Managed

The open source Tyk Gateway is a self-contained data plane with Redis as its only supporting datastore. It is licensed under the Mozilla Public License 2.0, and the gateway code ships with no feature lockout, so a team can run it in production without buying anything. What it does not include is the Dashboard, the Developer Portal, Tyk Pump or PostgreSQL. Those belong to the licensed Tyk Self-Managed stack, so everything around the gateway falls to your team. The gateway can be installed with Docker, the tyk-oss Helm chart on Kubernetes, Ansible, Red Hat, CentOS or Ubuntu packages, or built from source. Pick the path that matches your existing change control, and confirm which install artifacts your security team has approved before the first build.

Without a Dashboard, configuration lives in files and API calls rather than a management console. API definitions are JSON or YAML documents loaded from the gateway's configuration directory or pushed through its management API, and a reload applies changes without dropping traffic. Keys, quotas and rate limits are created and tracked in Redis, so the operator must decide how keys are issued, rotated and revoked, and who is authorized to do it. Treat Redis as a stateful dependency with its own backup, failover and access controls, not a cache. Confirm with Tyk which Redis topology and version the open source release supports in your environment before you size the cluster.

Several capabilities that the licensed stack provides must be built or scripted in-house. Typical gaps include a self-service developer portal with sign-up and key requests, an approval workflow for new API consumers, analytics export from Redis to your SIEM or data platform, and an audit trail of who changed which definition. For example, an illustrative team might generate apps definitions from a Git repository through a CI pipeline, issue keys from an internal ticketing workflow, and forward gateway logs to its log platform. Each of these is ongoing software your team owns, so estimate the maintenance effort, and ask any implementation partner to price these components as explicit line items in a fixed-scope quote.

The licensed layer earns its cost when the number of people managing APIs grows faster than the number of engineers who can edit configuration by hand. If many API owners need a self-service developer portal, a governed API lifecycle, or a single place to see who consumes what, the Tyk Self-Managed stack with the Dashboard, Developer Portal, Tyk Pump and PostgreSQL covers those jobs in one product. The open source Tyk Gateway with Redis can enforce keys, quotas and per-version access, but it does not give those owners a management interface or a portal. A Kubernetes-native team that wants API definitions managed as declarative resources should also price the Tyk Operator, which requires a license. Teams that prefer not to run the management stack at all can evaluate Tyk Cloud, which is described as managing the full stack and offers a free trial. Confirm with Tyk which features each tier includes, since this page relies only on the license terms the sources state.

A platform team with strong automation and a small API catalog can reasonably stay on the open source gateway. In that setup, API definitions live in version-controlled files, changes flow through CI, and keys and quotas are issued by a script or an internal service that the team already runs. The MPL-2.0 gateway supports JWT, bearer tokens, Basic Auth, client certificates, rate limiting, quotas, versioning, IP allowlisting and hitless reloads, and plugins can be written in Python, JavaScript, Go or any language that supports gRPC. The trade-off is that the team builds and maintains whatever the Dashboard and portal would have provided, including onboarding workflows, audit trails and documentation for consumers. Before committing, list those internal tools and estimate the engineering time they need, then compare that figure with a written quote for the licensed components.

Put the decision in writing before the first license conversation. Name the number of API owners who need portal access, the approval steps a new API must pass, and whether auditors will ask to see who changed a policy and when. If those answers point to self-service and governance, the licensed stack is the more direct path. If they point to a few owners and a mature pipeline, the open source gateway may be enough for now, and the team can add the commercial layer later if the catalog grows. Ask Tyk to confirm the current Dashboard and Developer Portal features in each edition, the license terms that apply to production use, and the support scope, and ask for the same answers in writing from any implementation partner you consider.

Start by mapping each capability you need to a specific edition, because the public README draws a clear line only at the gateway. The Tyk Gateway is MPL-2.0 and runs with Redis, while the Dashboard, Developer Portal, Tyk Pump and PostgreSQL belong to the licensed Self-Managed stack. Ask Tyk in writing which edition carries each feature you depend on, including the controls you plan to use for per-version and per-operation access, quotas, analytics export and developer onboarding. Do not assume that a feature visible in the gateway code is available without the management layer, and do not assume the reverse. Get the answer as a feature matrix tied to the version you will deploy, such as the current Tyk Gateway releases.

Confirm the license scope for the parts that are easy to overlook. The Tyk LICENSE states that the ee folder sits under a separate commercial Enterprise Edition license, so ask which of your planned components, the Tyk Operator for Kubernetes and the Developer Portal included, are covered by which terms, and whether licenses are per node, per cluster, per environment or per API. Ask how the license is validated in air-gapped or restricted networks, what happens to running production traffic if a license lapses, and what support and update terms come with it, including the supported upgrade path between Gateway releases.

Size Redis and PostgreSQL against your own traffic rather than against a generic figure. Redis holds the state the open-source gateway relies on for quotas and rate limiting, so measure your request rate, key cardinality and failover expectations in a load test in your environment. PostgreSQL and Tyk Pump matter for analytics retention and reporting volume. Your platform team should own those numbers, and any vendor sizing guidance should be checked against them. For Tyk Cloud, confirm the hosting regions, data residency for analytics and logs, and whether your regulators or contracts require data to stay within your own infrastructure, which would rule out the hosted option regardless of price.