Tyk vs KrakenD: when to choose each gateway
Choose Tyk when your team needs gateway state managed centrally, such as Redis-backed quotas and rate limits, granular per-version and per-operation access control, and API versioning that the gateway enforces at runtime. Tyk's middleware plugins can be written in Python, JavaScript, Go or any language that supports gRPC, which matters if your security or platform engineers already work in several of those languages. If you want a management UI for publishing and governing APIs, plan for the licensed Tyk Dashboard and Developer Portal, because the open-source Tyk Gateway runs without them. Tyk Gateway itself is MPL-2.0 licensed, but the ee folder falls under a separate commercial license, so confirm with Tyk exactly which components your production setup touches.
Choose KrakenD when you want stateless gateway nodes that each run independently, with configuration kept in declarative files for GitOps workflows. Its strength is response aggregation, content filtering and XML or JSON transformation at the edge, which reduces round trips for front-end and mobile clients. KrakenD Community Edition is Apache-2.0 licensed, so the core gateway is free to self-host. The trade-off is that KrakenD's design does not include centralized persistence, so features that depend on shared counters, such as distributed quotas, need to be checked against the documentation before you commit. Its Enterprise Edition adds SLAs, security, governance and 24/7 support, so ask KrakenD what that edition covers that your team would actually use.
The decision turns on four questions. First, do you need a management layer with a portal and console, or is configuration-as-code enough? Second, how much shared state can your gateway tolerate, and are you prepared to run Redis? Third, which plugin languages must your team support? Fourth, which parts of each vendor's enterprise license will your production deployment require? Write those answers down, then ask both vendors for a written statement of which features are free, which are licensed and which are supported only under a subscription.
Which gateway fits which scenario
This table maps common API gateway scenarios to the platform that fits each one better, with the reason and the condition that makes the choice hold. Read each row as a conditional choice, since both gateways are open source and the answer depends on whether you need stateful controls, a management UI or a stateless edge layer.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Stateless edge gateway that aggregates several backend calls | KrakenD | KrakenD nodes run independently with no shared persistence and offer content aggregation and filtering. Choose it when the edge layer must scale without a shared datastore. |
| Per-consumer or per-version quotas that must be enforced across nodes | Tyk | Tyk's quotas and rate limiting rely on Redis, so Redis availability becomes a condition for those stateful controls. Plan Redis operations before committing. |
| Multi-team API program needing a developer portal and management UI | Tyk | The Developer Portal and Dashboard are part of the licensed Tyk Self-Managed platform, so the portal experience requires a commercial license. Confirm the license scope against your team count. |
| GitOps-first Kubernetes shop wanting declarative configuration in version control | KrakenD | KrakenD is configured declaratively for GitOps workflows. Tyk's declarative Kubernetes path, the Tyk Operator, requires a license, so confirm that cost first. |
| Python or JavaScript plugins in the request middleware chain | Tyk | Tyk plugins can be written in Python, JavaScript, Go or any language with gRPC support. KrakenD extensions use Lua, Martian or Google CEL, so choose Tyk if your team already writes Python or JavaScript. |
| Per-version access control with hitless configuration reloads | Tyk | Tyk supports API versioning, per-version and per-operation access control and hitless reloads. Confirm the exact versioning model against your API lifecycle before relying on it. |
| Budget limited to a self-hosted open-source gateway with no management layer | KrakenD | KrakenD CE is Apache-2.0 and runs without a database or Redis. Tyk Gateway is MPL-2.0, but the Redis-backed features and management components are the parts that carry licensing or operating cost. |
How each gateway is built and what it means for operations
Tyk and KrakenD both sit in the request path, but they distribute state very differently. The cards below cover what each design asks your team to back up, scale and monitor, and where coordination work lands.
Tyk Gateway depends on Redis
The open-source Tyk Gateway runs with Redis as its shared datastore, and quotas, rate limits and key state depend on it. Redis availability, persistence settings and sizing therefore become gateway availability concerns. Ask how your Redis topology behaves during failover, and whether a Redis outage degrades or blocks requests in the gateway version you plan to run. Confirm this behavior with Tyk before you commit to a design.
Self-Managed adds four stateful components
The full Tyk Self-Managed platform runs Tyk Gateway, Tyk Dashboard, the Developer Portal, Tyk Pump, Redis and PostgreSQL. Each stateful component needs its own backup, restore test, patch cycle and monitoring. Analytics flow through Pump, so a Pump backlog can hide inside an otherwise healthy gateway. Map every component to an owner before you size the platform, and ask Tyk which components are licensed in your edition.
KrakenD nodes hold no shared state
KrakenD's design is stateless: every node operates independently without coordination or centralized persistence. Scaling means adding identical nodes behind a load balancer, and a failed node carries no data that must be restored. Backup focuses on the declarative configuration files, which should live in version control. Your scaling and recovery runbooks will be simpler, but you must confirm that your rate limits and circuit breaker behavior are acceptable when each node counts traffic independently.
Coordination moves out of the gateway
Because KrakenD nodes do not coordinate, any cross-node concern must be handled by something else: the load balancer, the configuration pipeline, or your observability stack. Plan for consistent config rollout across all nodes, since a node running an older file can behave differently from its peers. Ask your team who owns config distribution and how drift between nodes is detected.
Declarative config drives change control
KrakenD is configured declaratively for GitOps workflows, which suits teams that already review infrastructure changes through pull requests. Tyk also supports hitless configuration reloads, but its Dashboard and Operator, which require a license, are the usual route for managing APIs as objects. Decide where your API definitions live of record, and confirm which Tyk management path your edition includes before writing your change process.
Monitoring and telemetry integrations
KrakenD exports telemetry to Prometheus, Jaeger, Zipkin and Datadog. Tyk's observability depends on how you deploy Pump and analytics storage. Compare the metrics each gateway exposes for latency, error rates and quota consumption against your existing dashboards. Confirm exporter support and retention with each vendor, since the community and licensed editions may differ.
Capabilities compared using supplied facts
This table sets Tyk's open-source gateway and KrakenD Community Edition side by side on the capabilities most teams test first. Read each row for the tier that holds the feature, since Tyk's management layer is licensed and KrakenD's enterprise features sit behind its paid edition. Where a row says to confirm, the supplied facts do not settle the answer for your environment.
| Capability | Tyk (open-source gateway) | KrakenD (Community Edition) |
|---|---|---|
| Authentication | JWT, bearer tokens, Basic Auth and client certificates in the open-source gateway | OAuth and JWT security in the Community Edition |
| Rate limiting and quotas | Rate limiting and quotas in the open-source gateway, which uses Redis for state | Multi-layer rate limiting in the Community Edition, with no shared state between nodes |
| API versioning and access control | Versioning, plus per-version and per-operation access control, in the open-source gateway | Declarative configuration in version-controlled files; confirm how versioning is organized for your APIs |
| Protocol support | REST with native OpenAPI support, SOAP, GraphQL, gRPC, TCP and MCP | Confirm protocol coverage for your own environment before relying on it |
| Response aggregation and transformation | Handled through the middleware chain and plugins; confirm fit for multi-backend composition | Content aggregation, filtering, and XML and JSON transformation in the Community Edition |
| Circuit breakers and telemetry | Confirm circuit breaker behavior and telemetry exports in your own deployment | Circuit breakers, plus telemetry to Prometheus, Jaeger, Zipkin and Datadog |
| Extension languages | Python, JavaScript, Go or any language that supports gRPC | Lua, Martian or Google CEL extensions |
| Deployment and hot reload | Docker, the tyk-oss Helm chart, Ansible, Red Hat, CentOS or Ubuntu packages, or source; hitless configuration reloads | Several package formats and an official Docker image; stateless nodes configured declaratively for GitOps |
What each license covers and what the enterprise editions add
The Tyk Gateway source is licensed under the Mozilla Public License 2.0, which is a file-level copyleft license. Modifications to MPL-2.0 files must stay under MPL-2.0 when you distribute them, but the license does not require your wider application to be open source. The exception is the ee folder in the repository, which sits under a separate commercial Enterprise Edition license. Tyk also states that the gateway ships with no feature lockout, so the open-source gateway runs with Redis and includes rate limiting, quotas, versioning, JWT and client certificate authentication, and plugins.
- Gateway code: MPL-2.0 applies to the core gateway outside the
eefolder. - The ee folder: Code in this folder falls under a separate commercial license, so confirm which files you would touch if you patch the gateway.
- Feature access: Tyk says there is no feature lockout in the gateway itself, which you should verify against the release you deploy.
- Distribution: Modified MPL-2.0 files you distribute carry source obligations, which matters if you ship a customized gateway image to other organizations.
- Runtime: Self-hosted open-source use does not require a Tyk license for the gateway alone.
Check with Tyk's license file and the release notes for your version whether any feature you plan to rely on lives in the ee folder.
The management layer is where the licensing decision usually lands. The full Tyk Self-Managed platform, which runs Tyk Gateway, Tyk Dashboard, the Developer Portal, Tyk Pump, Redis and PostgreSQL, needs a license. The Tyk Operator for Kubernetes-native declarative API management also requires a license. Tyk Cloud is the hosted option that manages the full stack and has a free trial. A team that needs a graphical management console, a self-service portal for API consumers, or Kubernetes-native declarative management should budget for a license before design, not after.
- Dashboard: Required for the graphical management console in Self-Managed deployments.
- Developer Portal: Required for the self-service portal that publishes API documentation to consumers.
- Operator: Required for Kubernetes-native declarative management.
- Pump and PostgreSQL: Part of the full Self-Managed stack that needs a license.
- Hosted option: Tyk Cloud covers the full stack as a service.
Ask Tyk in writing which components are included in each commercial arrangement and whether support, upgrades and Kubernetes packaging are covered.
KrakenD Community Edition is the open-source distribution of the KrakenD API Gateway and is licensed under Apache-2.0. Apache-2.0 is a permissive license, so you can use, modify and redistribute the code with fewer conditions than a file-level copyleft license imposes. The Community Edition is distributed in several package formats and as an official Docker image. Its design is stateless and declarative, so each node operates independently and configuration is managed as code for GitOps workflows. Features such as content aggregation, XML and JSON transformation, OAuth and JWT security, multi-layer rate limiting, circuit breakers and telemetry export are part of the open-source product described in its README.
- License: Apache-2.0 for the Community Edition.
- Distribution: Several package formats and an official Docker image.
- Configuration: Declarative and suitable for GitOps workflows.
- Extensions: Lua, Martian and Google CEL are available for customization.
- Upstream framework: The Lura Project, which holds the core framework, is Apache 2.0 under LF Projects, LLC.
Confirm with KrakenD which capabilities you need are documented in the Community Edition release you plan to run, since feature availability can change between versions.
KrakenD sells an Enterprise Edition alongside the free Community Edition. KrakenD describes the commercial offer as adding SLAs, security, governance and 24/7 support. The practical question for a regulated team is which of those items are contractual commitments, which are product features, and which are process commitments such as review cycles or patch timing. None of these details are specified in the public materials this page relies on, so they must come from the proposal. Support and SLA terms affect who you call during an incident, and governance features affect how you control change across teams.
- SLAs: Ask for the uptime, response and resolution terms in writing.
- Security: Confirm which security features are product functions and which are advisory.
- Governance: Ask which policy, access and audit controls are in the Enterprise Edition.
- 24/7 support: Confirm coverage hours, severity definitions and escalation paths.
- Features by tier: Ask for a table mapping each capability to Community or Enterprise.
Get the feature-by-tier mapping in writing before you compare costs, because the Enterprise Edition scope drives the recurring spend.
Both vendors draw the commercial line in different places, so a like-for-like comparison depends on the features you need in production rather than on headline license names. Tyk's open-source gateway can run on its own, but the Dashboard, Developer Portal and Operator sit behind a license. KrakenD's Community Edition is complete for gateway work, while the Enterprise Edition is sold on support, SLAs, security and governance. Treat the license split as a design input that affects who operates the platform, which tools your developers use, and what you can audit after go-live.
- Tyk scope: Gateway under MPL-2.0 with licensed management components.
- KrakenD scope: Apache-2.0 Community Edition with a commercial support and governance tier.
- Recurring cost: Ask which licenses renew annually and what triggers a tier change.
- Exit terms: Confirm what happens to features and support if you stop renewing.
- Written mapping: Require a feature-by-tier table from each vendor before selection.
Ask each vendor for a written feature-by-tier table, the license file for the exact version you will run, and the renewal terms covering support and management components.
What drives the running cost of each gateway
The running cost of Tyk is mostly set by what you license and what you operate. The open-source Tyk Gateway runs with Redis, but the full Tyk Self-Managed platform also runs the Tyk Dashboard, the Developer Portal, Tyk Pump, Redis and PostgreSQL, and that full stack needs a license. Ask the vendor which of these components your use case requires, whether the Dashboard and Developer Portal license is priced per deployment, per node or per organization, and whether the Tyk Operator, which also requires a license, is included. Then size the datastores you will run yourself: Redis for gateway state and quotas, and PostgreSQL and Tyk Pump for the management layer. Each one adds hosting, patching, backup and on-call work that recurs every month.
KrakenD's Community Edition is Apache-2.0 licensed and its declarative, stateless design means each node runs without shared persistence, so the main recurring cost is compute per node plus the pipeline that deploys its configuration. The commercial question is whether you need the KrakenD Enterprise Edition, which the vendor describes as adding SLAs, security, governance and 24/7 support. Ask for that support scope in writing, including response targets, release-tracking help and how upgrades are handled. Both vendors' costs therefore split into one-time items such as implementation, configuration and migration, and recurring items such as licenses, support, infrastructure and staff time. Request a quote that separates them and states the node count and environments it assumes.
Staff skills often move the total more than license fees. Tyk's operating model centers on its management stack, so your team needs to know Redis, PostgreSQL and the Dashboard. KrakenD's model centers on declarative configuration and Go-based extensions, which suits teams already running GitOps pipelines. Confirm which skills you already have, then price the training or contractor time for the gap. Also plan release tracking: check the current Tyk Gateway release (v5.15.1) and KrakenD CE v3.0.1 against your own upgrade calendar, and ask each vendor for its support window per release line before you commit.
Moving from Tyk to KrakenD or back
This sequence turns a Tyk deployment into an equivalent KrakenD configuration, or the reverse, without a single cutover date. It produces a route-by-route inventory, a rebuilt set of rate limits and access rules, and evidence that each migrated route behaves the same under real traffic.
Inventory routes, auth and versions
The platform owner exports every API definition, listing the upstream, the listen path, the authentication method, the version and any per-operation access rules. Tyk API definitions and the Dashboard give the starting list, and the team marks which routes are public, partner-facing or internal. The step is done when every route has a row in a shared inventory that the API owners have signed off, with versions mapped to the paths clients actually call.
Map auth policies to KrakenD security
The security engineer compares each Tyk auth method, including JWT, bearer tokens, Basic Auth and client certificates, with the equivalent KrakenD security settings for OAuth and JWT. Gaps are logged as open decisions, such as any method that needs a custom plugin or an external identity check. The step is done when every route's auth method has a documented KrakenD equivalent or a named owner for the gap, reviewed by the identity team.
Rebuild quotas and rate limits
Because Tyk keeps quota and rate counters in Redis, those counters do not move to KrakenD, whose nodes run statelessly without shared persistence. The platform team decides which limits must stay global across nodes and which can be enforced per node, then rebuilds them using KrakenD's multi-layer rate limiting, and assigns a clear owner for any quota that depends on a shared counter. The step is done when each Tyk quota has a written replacement and a stated accepted behavior during the parallel run, approved by the product owner.
Translate access control to declarative files
The team converts per-version and per-operation access rules into KrakenD endpoint definitions kept in version control, so every change is reviewed as a diff. Engineers check that IP allowlisting and client certificate rules are enforced at the same points, and that GitOps promotion covers all environments. The step is done when a pull request reproduces each access rule and a reviewer confirms the diff against the inventory from the first step.
Rewrite plugins for KrakenD extensions
Each Tyk plugin is classified by purpose, then rewritten. Plugins written in Python or JavaScript must be reimplemented, because KrakenD extends through Lua, Martian or Google CEL rather than those languages, and Go or gRPC plugins need a new integration path. Engineers test each rewritten plugin against recorded requests from the Tyk environment. The step is done when every plugin has either a tested KrakenD equivalent or a documented decision to remove it.
Run both gateways in parallel
The team deploys the KrakenD configuration beside Tyk and mirrors or splits live traffic for selected routes, comparing status codes, latency, auth outcomes and telemetry in both systems. Observability needs to be set up on both sides, with KrakenD telemetry exported to the monitoring stack the team already runs. The step is done when the comparison shows agreed differences only, and each difference has an owner and a recorded decision.
Cut over route by route
Routes move one group at a time, starting with low-risk internal routes and ending with partner-facing and high-volume ones. Each cutover has a written rollback step that points the client path back to Tyk, and the on-call team is named for the window. The step is done when every route is served by its chosen gateway, the rollback path has been tested, and the old Tyk definitions are archived rather than deleted until the business owner agrees.
Confirm the reverse path and retire
If the move goes the other way, from KrakenD back to Tyk, the same inventory and mapping apply in reverse, with Redis-backed quotas rebuilt in Tyk. Before decommissioning, the team confirms licensing needs for any Tyk Dashboard, Developer Portal or Operator features still in use, and checks that backups and documentation cover the final state. The step is done when a signed decommission record lists the retired components, the retained licenses and the documented runbook for the surviving gateway.
Where implementation projects usually run long
Implementation timelines for Tyk and KrakenD usually stretch in the same places: the design of the configuration model, the handling of quotas and identity, and the testing that proves both hold under load. On the Tyk side, the first decisions are whether Redis is sized and operated as a shared dependency for rate limits and quotas, and whether the team needs the licensed Dashboard and Developer Portal, which the open-source gateway does not include. Those licensing choices shape the architecture, so they should be settled before any API is migrated. On the KrakenD side, the work centers on the declarative configuration, usually a krakend.json file managed through GitOps, and on mapping each backend aggregation and transformation to the correct endpoint. Because KrakenD nodes are stateless, most of the effort sits in the configuration design and in how it is promoted across environments, not in data stores.
The delay points are predictable. Plugin rewrites are the most common: Tyk plugins can be written in Python, JavaScript, Go or any gRPC-capable language, but a Lua or JavaScript middleware that works in one environment may need rework to match the team's language standards. Quota semantics are the second: confirm in writing whether a quota counts per key, per API or per organization, and how it resets, before load tests start, because a mismatch shows up late. Identity provider integration is the third, covering JWT claims, client certificates and token validation against the provider's keys and clocks. Load testing closes the schedule, and it needs a production-like environment, realistic traffic profiles and time set aside to tune Redis and gateway nodes. Ask for these to be scoped and timed separately in the quote.
The client supplies the inputs that determine whether any of this is predictable. Provide a current API inventory with protocols, versions, backends, authentication methods and traffic estimates, along with the identity provider details: issuer, token format, key discovery endpoints and claim mappings. Name the target environments (cloud accounts, data centers or air-gapped networks) and the staffing on both sides, including who owns Redis, Kubernetes or hosts, and who approves security changes. Confirm which Tyk or KrakenD edition and license terms apply, and check current versions on the Tyk releases page and the KrakenD CE releases page. Scope, deliverables and timelines are agreed in writing before work starts, so any open input becomes a documented assumption rather than a silent slip.
Questions buyers ask before choosing between Tyk and KrakenD
Does KrakenD Community Edition cover API quotas?
The supplied KrakenD material confirms multi-layer rate limiting in the Community Edition, but it does not describe a separate quota feature, so confirm quota behavior with KrakenD before assuming it matches Tyk. Tyk Gateway's open-source build lists rate limiting and quotas alongside API versioning and per-version access control, with Redis holding the state. If your plans depend on monthly or per-consumer allowances, ask KrakenD how counters stay consistent in a stateless design where every node operates independently. Request a written example of a per-consumer quota enforced across several nodes, and confirm whether that behavior needs an Enterprise Edition feature.
Is Tyk Gateway enough without the Dashboard?
The open-source Tyk Gateway can run on its own for routing and policy work, but the Dashboard, Developer Portal and Operator all require a license, so the answer depends on how your team creates keys, publishes APIs and onboards consumers. The gateway itself covers JWT, bearer tokens, Basic Auth, client certificates, rate limiting, versioning and hitless configuration reloads. Without the Dashboard, your engineers own configuration and key administration through the gateway's own interfaces, which is workable for a small API estate and harder as consumer numbers grow. If you need self-service key issuance for developers, that capability sits in the licensed stack, so confirm with Tyk what the Self-Managed license covers and whether Tyk Cloud fits your hosting rules.
What makes the total cost of Tyk and KrakenD differ?
License fees are only one line in the total, and the larger differences usually come from the components you run and the people who maintain them.
- Licenses: the full Tyk Self-Managed platform needs a license, while KrakenD Community Edition is Apache-2.0 and KrakenD sells an Enterprise Edition with SLAs, security, governance and 24/7 support.
- Infrastructure: Tyk's open-source gateway depends on Redis, and the full Self-Managed stack adds Tyk Pump and PostgreSQL, while KrakenD nodes hold no central persistence.
- People: operations, upgrades, plugin maintenance and on-call coverage recur for both, and their size depends on how much state and tooling each stack adds.
Ask each vendor for a written quote that separates one-time fees from annual recurring fees, names the support tier, and states the term. Ask DeployOpen for a fixed-scope quote built from your written requirements.
How long does a gateway migration take and what drives it?
No supplied fact gives a migration duration, so the timeline depends on the inventory you bring to scoping. The largest drivers are the number of routes, versions and consumers with issued keys, followed by the custom logic that must move.
- Plugins: Tyk plugins written in Python, JavaScript, Go or another gRPC-capable language need reimplementing with KrakenD's Lua, Martian or Google CEL extensions.
- Aggregation: APIs that depend on middleware-driven composition may need redesign around KrakenD's response aggregation.
- Policies: rate limits, quotas, access control and key migration each need to be mapped and tested.
- Cutover: parallel running, traffic shifting and rollback criteria add effort.
DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for a scoping workshop that produces a route and policy inventory.
Can our team run either gateway without outside help?
Yes, if your operators already run the infrastructure each stack needs, and the difference lies in how many stateful components and specialized skills you take on. Tyk's open-source gateway needs Redis, and the full Self-Managed platform adds a Dashboard, Developer Portal, Tyk Pump and PostgreSQL, with Kubernetes deployment available through the tyk-oss Helm chart. KrakenD runs as stateless, declaratively configured nodes suited to GitOps pipelines, distributed as packages and an official Docker image, with telemetry to Prometheus, Jaeger, Zipkin or Datadog. Your team will need Redis and management-stack operations skills for Tyk, and configuration pipeline and observability skills for KrakenD. DeployOpen can implement either stack under a fixed scope and provide ongoing support, upgrades and testing through retainers.
How does identity integration differ between Tyk and KrakenD?
Both gateways validate tokens, but the surrounding identity workflows differ and need confirmation against your identity provider. Tyk Gateway supports JWT, bearer tokens, Basic Auth and client certificates, with IP allowlisting and granular per-version and per-operation access control. KrakenD's technical features list OAuth and JWT security alongside multi-layer rate limiting and circuit breakers. Before choosing, confirm how each gateway fetches signing keys from your provider, whether it supports token introspection, how claims map to authorization rules, and how mutual TLS is configured for service-to-service calls. Also confirm which developer-facing key issuance and self-service workflows fall under Tyk's licensed components, since those shape how your identity team and API consumers interact with the gateway.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. For a Tyk or KrakenD decision, that work can start with a side-by-side check of your traffic patterns, identity provider, and Kubernetes or VM footprint, then move to a proof of concept that tests the components you actually plan to run. DeployOpen has no preferred gateway. It does not hold vendor partner, reseller or certified provider status with Tyk or KrakenD, so the recommendation follows from your requirements and the written scope, and it can come out in favor of either product or of neither.
Most engagements are fixed-scope. Before work begins, scope, deliverables and timelines are agreed in writing, so you know exactly which gateway components, plugins, identity flows, backup routines and documentation are included. A quote follows from that written scope. DeployOpen does not publish a price list, so ask for the scope items that drive cost: which Tyk components are licensed for your environment, whether a Redis deployment needs its own build and backup design, how many KrakenD configuration files and backend services must be migrated, and whether ongoing upgrades, security testing or support should run under a retainer. Ask for those items to be listed separately in the quote so you can compare options fairly.
DeployOpen does not issue audit reports, attestations or certifications. If your team must show evidence to an assessor, DeployOpen can prepare systems, configuration baselines, access controls and records for the gateway, but the independent auditor or certification body makes the determination. Confirm early which evidence your assessor expects, and confirm with each vendor which features and editions your compliance controls depend on, such as the licensing terms for the Tyk Dashboard and Developer Portal or the enterprise support terms offered by KrakenD, before the scope is signed.
