Apache APISIX vs Tyk: which gateway fits your team
Choose Apache APISIX when you want the gateway and its plugins under Apache-2.0, with configuration held in etcd and a plugin model your developers can extend in Lua, or through external plugin runners in Java, Go and Python. APISIX's traditional and decoupled modes both depend on a shared etcd cluster, so this fits teams that already operate etcd or can take it on. Its standalone mode removes etcd and loads configuration from conf/apisix.yaml or conf/apisix.json, which suits GitOps-driven estates. Choose Tyk when your team wants an MPL-2.0 gateway written in Go on Redis, and accepts that the Tyk Dashboard, Developer Portal and Operator need a commercial license. Tyk's documented extension languages include Python, JavaScript, Go and any language with gRPC support, which suits teams whose developers already work in those languages.
The decision turns on three questions. First, which components you must license: the APISIX gateway and plugins are Apache-2.0 end to end, while Tyk's Dashboard, Developer Portal, Pump and Operator sit behind a commercial license, so ask Tyk in writing which of your planned features fall in the ee folder. Second, which config store your operations team can run: etcd for APISIX, or Redis for Tyk, along with the failure modes and backup routine each one needs. Third, which languages your developers will write plugins in, and whether you need Java support in particular. Confirm current release support with each vendor before you commit, since version dates change.
Which gateway fits which scenario
This table maps common team situations to the gateway that fits them better, with the supplied facts behind each choice. Read each row against your own constraints, since a single requirement such as a license rule or a plugin language can settle the decision.
| Scenario | Better fit | Reason |
|---|---|---|
| Kubernetes-first platform team that wants declarative API config | Apache APISIX | APISIX offers a separate Ingress Controller (2.2.0, August 18, 2026) and standalone mode reads a YAML file that hot-reloads, while the Tyk Operator requires a license. |
| Team that wants a GUI-driven API management portal | Tyk (with a commercial license) | The Tyk Dashboard and Developer Portal are part of the self-managed platform that needs a license; the open source gateway alone has no equivalent UI for this. |
| Air-gapped environment with no external license checks | Apache APISIX | APISIX runs in standalone mode with no etcd and configuration from a local file, and its plugins are under Apache-2.0. Confirm the air-gapped install steps with each project. |
| Team with Lua or Go plugin developers | Either, depending on language | APISIX plugins can be written in Lua natively or through plugin runners in Java, Go and Python. Tyk plugins support Python, JavaScript, Go or any gRPC language. Match the language to your existing skills. |
| Team that must avoid any commercial license for core operations | Apache APISIX | Tyk Gateway is MPL-2.0 but the ee folder is commercially licensed, and Dashboard, Developer Portal and Operator need a license. APISIX's plugins sit under Apache-2.0, so confirm your needs fall within the open source scope. |
| Team that needs Redis-backed rate limiting and quotas as a core feature | Tyk | Tyk Gateway runs with Redis and ships rate limiting and quotas in the open source gateway. APISIX stores configuration in etcd, so confirm how its rate limit plugins store counters in your topology. |
| Team needing gRPC, WebSocket, MQTT or TCP/UDP proxying in one gateway | Apache APISIX | The APISIX repository lists HTTP/3 with QUIC, gRPC, WebSocket, MQTT, Dubbo and TCP/UDP proxying. Confirm Tyk's support for each protocol you need, since its README emphasizes REST, SOAP, GraphQL, gRPC, TCP and MCP. |
| Team that needs an open source MCP gateway in a single product | Tyk | Tyk's README lists MCP support as part of its open source gateway. Confirm the APISIX AI gateway functions you need before deciding. |
How APISIX and Tyk are built and deployed
Both gateways sit in front of your APIs, but they store configuration and depend on different components. The cards below trace each choice to what your team backs up, which ports it exposes, and which components it must patch on a regular cycle.
APISIX on NGINX with etcd
APISIX runs on NGINX and ngx_lua with LuaJIT, and in traditional and decoupled modes it keeps configuration in etcd. Your backup plan must cover the etcd cluster as the source of truth for routes, consumers and plugin settings, and etcd health directly affects whether configuration changes can be made. Confirm who owns etcd snapshots and restore testing before you commit.
APISIX file-driven standalone mode
In standalone mode APISIX has no etcd and reads conf/apisix.yaml or conf/apisix.json, checking for changes every second and hot-reloading without a restart. Backups become file versioning, which suits teams that already manage configuration in Git. The trade-off is that changes must go through the file or the API you choose, so agree on one change path with your platform team.
Tyk Gateway in Go with Redis
Tyk Gateway is written in Go and runs with Redis as its shared data store. Redis holds the state the gateway needs at runtime, so you should confirm its persistence, replication and failover design with your operations team. Because the open source gateway is one component, your day-two work centers on Redis, the gateway binary and its plugin runtime rather than a configuration database you manage separately.
Tyk Self-Managed commercial stack
The full Tyk Self-Managed platform adds Tyk Dashboard, the Developer Portal, Tyk Pump, Redis and PostgreSQL, and it requires a license. Each added component is another database, service and patch target to back up, monitor and upgrade. Ask Tyk exactly which of these components your target design needs, because the open source gateway alone does not include the Dashboard or Portal.
APISIX Admin API ports
In traditional mode APISIX serves client traffic on port 9080 and the Admin API on port 9180. Restricting access to 9180 is the main network control you own, because anyone who reaches it can change routes and plugins. Plan firewall rules, admin credentials and internal-only exposure for 9180 separately from the public listener on 9080.
Tyk install paths and patching
Tyk Gateway can be installed with Docker, the tyk-oss Helm chart on Kubernetes, Ansible, Red Hat, CentOS or Ubuntu packages, or from source. Each path sets who applies gateway upgrades and where Redis is hosted, so choose one path your team can patch on schedule. Confirm with Tyk how release notes and security fixes reach open source users, since the Gateway release cadence is the baseline you will track.
Protocols, plugins and authentication compared
This table compares what each open-source gateway handles at the protocol, plugin, authentication and operations layers, using only the documented facts for each project. Read each row as a question to answer for your own traffic, and confirm any cell you cannot trace to a source before you rely on it. The main takeaway is that APISIX leads on breadth of plugins and protocol proxying, while Tyk's built-in authentication and API management features sit closer to the gateway core, and the Dashboard, Developer Portal and Operator require a license.
| Capability | Apache APISIX (Apache-2.0) | Tyk Gateway (MPL-2.0) |
|---|---|---|
| Protocol support | HTTP, HTTPS, HTTP/3 with QUIC, gRPC, WebSocket, MQTT, Dubbo, TCP and UDP proxying | REST with native OpenAPI support, SOAP, GraphQL, gRPC, TCP and MCP |
| MQTT and Dubbo proxying | Yes | No |
| Plugin count and built-in coverage | More than 100 built-in plugins covering authentication, security, traffic control, observability and AI gateway functions | Built-in middleware for JWT, bearer tokens, Basic Auth, client certificates, rate limiting and quotas, versioning and IP allowlisting; confirm the full plugin inventory in Tyk's documentation |
| Custom extension languages | Lua plugins in worker processes, external plugin runners for Java, Go and Python, WebAssembly (experimental in the architecture documentation) | Python, JavaScript, Go, or any language that supports gRPC |
| OpenID Connect integration | openid-connect plugin works with Keycloak, Auth0, Microsoft Entra ID, Google and Okta, supporting authorization code, client credentials, token introspection and PKCE | JWT and bearer token validation are built in; confirm which identity providers and OIDC flows Tyk supports in your version |
| Other built-in authentication | Documented in the plugin catalog, including the openid-connect plugin; confirm the full list for your release | JWT, bearer tokens, Basic Auth and client certificates |
| Rate limiting and quotas | Traffic control plugins are documented; confirm the exact limiter behavior and any shared state requirements in your topology | Rate limiting and quotas are built into the gateway |
| API versioning and access control | Route and plugin configuration can be scoped per route; confirm how versioned APIs are modeled in your design | API versioning, granular per-version and per-operation access control, and IP allowlisting are built in |
| Configuration reload behavior | Hot-loads routes and plugins; file-driven standalone mode checks conf/apisix.yaml or conf/apisix.json every second and reloads without restart | Hitless configuration reloads; confirm behavior under your Redis and Dashboard setup |
| Kubernetes operation | Separate APISIX Ingress Controller (2.2.0, August 18, 2026); traditional, decoupled and standalone modes | tyk-oss Helm chart for the open source gateway; Tyk Operator for declarative management requires a license |
| Components that need a commercial license | None of the documented gateway, plugin or ingress components are described as commercially licensed; confirm with the vendor or API7.ai for any enterprise add-on | Tyk Dashboard, Developer Portal, Tyk Pump integration in the full Self-Managed platform, and Tyk Operator require a license |
How OIDC and JWT logins work in each gateway
In APISIX, OIDC login and token validation run as a plugin on the route itself. The openid-connect plugin can be configured for the authorization code flow, the client credentials flow, token introspection and PKCE, and the APISIX documentation names Keycloak, Auth0, Microsoft Entra ID, Google and Okta as working identity providers. The decision you face is which flow each route needs: browser-facing routes usually need the authorization code flow with PKCE, while service-to-service routes usually need client credentials or introspection. Check the plugin's configuration keys and session handling against your exact provider in the openid-connect plugin documentation before you assume a flow works end to end.
In Tyk Gateway, the documented authentication options are JWT, bearer tokens, Basic Auth and client certificates, with IP allowlisting and per-version, per-operation access control on top. Token validation is therefore available at the gateway, but the Tyk README does not describe a packaged OIDC login flow with browser redirects, PKCE handling or provider-specific setup for the open source Gateway. Your team should plan to confirm how the login redirect, session and token refresh are handled, either in an external identity layer or in custom code, and whether the Developer Portal or Dashboard components that may cover this need a commercial license. Confirm the JWT signing method, key source and claim mapping you need, since these decide how portable the setup is across providers.
Run a proof of concept with your actual identity provider, tenant and each flow your applications use, including token expiry, refresh and revocation behavior, before committing to either gateway. Record the configuration each platform requires, who maintains it, and whether any part depends on a component that needs a license.
Which components are free and which need a license
The APISIX project itself is released under the Apache License 2.0 (Apache-2.0), and the project's documentation and repository describe the gateway's core as open source under that license. The APISIX downloads page does not mark any release as long-term support, so a team that needs a fixed support window should plan its upgrade cadence around the release notes rather than assume a long-term branch exists.
- Project license: The gateway, its built-in plugins and the APISIX Ingress Controller are covered by the Apache-2.0 terms listed in the repository.
- Plugin coverage: The documentation describes more than 100 built-in plugins, so authentication, traffic control and observability features do not sit behind a separate paid tier in the project documentation.
- Support windows: The downloads page does not mark a release as long-term support. Ask whether you need a vendor-backed support window and, if so, who provides it.
- Commercial products built on APISIX: API7 Enterprise is a separate commercial product from API7.ai built on APISIX. Its license and features are not part of the open-source project.
Before you deploy, confirm with the APISIX community or a commercial provider what support, patch and upgrade commitments apply to the version you choose.
The Tyk Gateway code is licensed under the Mozilla Public License 2.0 (MPL-2.0), with one exception: the ee folder in the repository falls under a separate commercial Enterprise Edition license. The gateway itself runs without a license, but several components around it need a commercial agreement, as the Tyk README states.
- Gateway: The Gateway is MPL-2.0 and, according to the README, ships with no feature lockout in the gateway itself.
- Enterprise folder: Code in the
eefolder is under a separate commercial Enterprise Edition license, so review that folder's terms before reusing any code from it. - Dashboard, Developer Portal and Pump: The full Tyk Self-Managed platform, which includes the Dashboard, Developer Portal and Tyk Pump alongside Redis and PostgreSQL, needs a license.
- Operator: The Tyk Operator for Kubernetes-native declarative API management requires a license.
- Tyk Cloud: Tyk Cloud manages the full stack as a hosted service and is available with a free trial. Its subscription terms are separate from the self-managed license.
Ask Tyk for written confirmation of which components your deployment model requires, because the README is a summary rather than a contract.
Both gateways have paid layers beyond the open-source code, and the cost of those layers depends on who operates the platform. For APISIX, paid products come from separate commercial vendors. For Tyk, the paid layer is largely the Dashboard, Developer Portal, Pump and Operator. Independent of either vendor, implementation and support work is a separate cost that a fixed-scope engagement or retainer can cover.
- Vendor subscriptions: Commercial support, portal and management features come from the vendor that owns the product, and each one has its own edition terms.
- Hosting and infrastructure: Self-managed deployments of either gateway still require infrastructure such as etcd for APISIX or Redis and PostgreSQL for Tyk Self-Managed. These are operating costs even when the software is free.
- Implementation and upgrades: Planning, hardening, documenting and upgrading a gateway is labor, whether done in-house or by an outside partner under a written scope.
- Support windows: Ask each vendor which versions receive security fixes and for how long, since those dates drive upgrade budgets.
Request a written quote that lists each licensed component, its edition and the support terms, and confirm current edition terms directly with each vendor before you commit.
What drives the running cost of each gateway
Running cost for either gateway is set less by the software price than by the components you must operate, the people who can operate them, and the parts of the stack that sit behind a license. Each card below names one cost driver, who gets paid for it, and what to request in a written quote before you commit.
Configuration store and data stores
APISIX in traditional or decoupled mode depends on an etcd cluster for configuration, so you operate and back up that cluster as a stateful service. Tyk Gateway with open-source components runs on Redis, and the full Self-Managed stack adds Dashboard, Developer Portal, Tyk Pump, Redis and PostgreSQL. Ask the vendor or partner to list every stateful component in your target topology, who patches each one, and what high availability layout the quote assumes. Standalone APISIX mode removes etcd but changes how configuration is managed.
Team skills and operating knowledge
APISIX asks operators to understand NGINX, LuaJIT and the Lua plugin model, and to troubleshoot etcd. Tyk asks operators to know Go-based deployment, Redis operations and, for the full platform, PostgreSQL. Staff who already run one of these stacks lower the onboarding cost of the other, and the difference is usually in on-call readiness rather than in the first install. Ask for the hours of onboarding and runbook work the proposal includes, and whether training is part of scope.
License fees for required components
The Tyk Gateway code is MPL-2.0, but the Dashboard, Developer Portal and Tyk Operator for Kubernetes require a commercial license, so a team that needs a UI, portal or declarative Kubernetes management pays for those parts. APISIX plugins are Apache-2.0 and the plugin catalog is open. Confirm which features on your list sit in the open-source code and which need a paid edition, and ask for the license terms and renewal basis in writing.
Upgrade effort and release cadence
APISIX 3.19.0 was released on September 28, 2026, and the downloads page does not mark any release as long-term support, so your team must plan regular upgrades. Tyk Gateway v5.15.1 was published on October 2, 2026. Each upgrade touches the gateway, its plugins and, for Tyk, any paid Dashboard or Operator components on matching versions. Ask the partner how many upgrade cycles per year the retainer covers, how plugin compatibility is tested, and whether rollback is part of scope.
Support and services options
Community support covers the open-source code, but production support, SLA terms and vendor-led upgrades are sold separately by each vendor and by third parties. APISIX has commercial support offered by API7.ai, and Tyk sells Self-Managed and Cloud subscriptions. DeployOpen plans, implements, hardens, backs up and supports self-hosted platforms on a fixed scope, with ongoing support available as a retainer. Compare these as separate line items, and ask for the response times and escalation paths each option commits to in writing.
One-time and recurring costs
One-time costs include architecture, initial deployment, plugin or policy migration and the first security review. Recurring costs include license renewals, infrastructure for etcd or Redis and PostgreSQL, upgrades, backups, on-call time and support contracts. Ask any quote to separate these two groups, and state the assumptions for node count, traffic profile and retention. Without that split, a low first-year number can hide a higher annual run rate.
Moving an API estate from one gateway to the other
This sequence moves routes, upstreams, certificates and identity settings from one gateway to the other in controlled stages, so each change can be checked against live traffic before the old gateway is retired. It works in either direction, whether the move is from Tyk to APISIX or from APISIX to Tyk.
Inventory routes, plugins and auth policies
The platform team exports every route, upstream, consumer, certificate and plugin or middleware setting from the source gateway, and the security team lists the authentication method each API uses, such as JWT, client certificates, Basic Auth or OpenID Connect. Include rate limits, quotas, IP allowlists and API versions, since these are often set per consumer or per operation and are easy to miss. The step is done when every API has a row in one inventory with its owner, its auth method and its traffic profile, and the owners have signed off on it.
Map each plugin behavior to the target
For each item in the inventory, the platform engineers identify the equivalent feature in the target gateway and record any gap in writing. APISIX covers its behavior through more than 100 built-in plugins, and Tyk covers much of the same ground through its middleware and access control settings, but the names, parameters and defaults differ, so each mapping must be checked rather than assumed. Custom plugins written in Lua, Java, Go, Python or WebAssembly need a separate decision on whether to port, replace or retire them. The output is a mapping sheet with a status for each item: equivalent, partial, rebuild or drop.
Rebuild configuration in the target model
The engineers recreate the routes and policies in the target's configuration model. In APISIX that means choosing between etcd-backed configuration through the Admin API and file-driven standalone configuration in conf/apisix.yaml or conf/apisix.json, which reloads when the file changes. In Tyk it means writing API definitions for the Tyk Gateway, and deciding whether Dashboard and Operator are needed, since both require a commercial license. Store the resulting configuration in version control and review it like code. The step is complete when a test environment serves every mapped route and the tests for each auth method pass.
Migrate what transfers and rebuild what does not
Routes, upstream definitions, TLS certificates and the identity provider configuration usually carry across with edits to format and endpoints. Rate limit counters and cached state do not transfer, because they live in the source gateway's store, which is Redis for Tyk and etcd or the local node state for APISIX. Plan for those counters to reset at cutover and confirm with the business owners that a reset is acceptable for each limited API. Confirm that the certificate private keys are moved through your secrets process, not copied through a configuration export. The output is a written list of what was moved, what was rebuilt and what was reset.
Run both gateways in parallel
Both gateways run side by side in the same environment, with the new gateway receiving mirrored or test traffic while the old gateway continues to serve production. Compare status codes, latency, authentication decisions and rate limit responses between the two for the same requests. Watch the logs and metrics in your existing observability stack, since both gateways produce their own. The step is done when the differences found in comparison are either fixed or accepted in writing by the API owners.
Shift traffic in stages
Move a small set of low-risk APIs first, then increase the share of traffic gradually, keeping the old gateway ready to take traffic back. Change DNS, load balancer targets or ingress rules one group at a time, and record each stage with the time, the APIs involved and the observed error rate. Set rollback criteria before each stage starts, so the decision to roll back is not made under pressure. The stage is complete when all traffic for that group is served by the new gateway for an agreed period and the agreed checks pass.
Retire the old stack
Once all traffic is on the new gateway and the rollback window has closed, decommission the old gateway, its database or Redis instance, and any licenses or subscriptions that covered it. Remove stale DNS records, certificates and secrets, and update the runbooks, architecture diagrams and monitoring alerts. Confirm that backups of the old configuration and data are retained for the period your records policy requires. The step is done when the old gateway no longer receives traffic, the license or subscription is cancelled or not renewed, and the decommission record is filed.
What implementing each gateway involves and where projects run long
Plan the APISIX work around its configuration store first. In traditional and decoupled modes, etcd holds every route, upstream and plugin setting, so the team must size the etcd cluster for its route count and change rate, confirm how it is backed up and restored, and decide who may write to it. The Admin API listens on port 9180 in traditional mode, so restrict it to a management network, rotate its key on a schedule and keep it off client-facing listeners. If you need plugins written in Java, Go or Python, set up a plugin runner and test how it behaves on restart, since WebAssembly support is still experimental. On Kubernetes, choose between the APISIX Ingress Controller (2.2.0 was released on August 18, 2026) and another deployment path, and confirm how each handles your certificate and route objects. Check the deployment modes documentation for the cautions that apply to your chosen mode.
The Tyk work centers on Redis and the licensing boundary. Tyk Gateway runs with Redis, so Redis availability, persistence and backup become part of the gateway project even though the gateway code is open source under MPL-2.0. Decide early whether you need the Dashboard, Developer Portal, Tyk Pump and PostgreSQL, because the full Self-Managed platform requires a license, and so does the Operator for Kubernetes-native declarative management. Map each licensed component to a named team and a procurement step before the design is final. For custom logic, Tyk supports plugins in Python, JavaScript, Go or any language with gRPC support, so choose one language, name an owner for it and test every upgrade against your plugins. Ask the vendor to confirm current license terms for each component in writing, using the Tyk Gateway README as the starting reference.
Questions buyers ask before choosing between APISIX and Tyk
What drives the cost and effort of running APISIX or Tyk Gateway?
Software licensing is only part of the bill. For APISIX, the Apache License 2.0 covers the project itself, so the recurring cost is the infrastructure, the etcd cluster you operate, and the people who run it. For Tyk, the open source Tyk Gateway also has no license fee, but the full Tyk Self-Managed platform needs a license, so the cost depends on whether you need the Dashboard, Developer Portal or Operator. Ask any vendor or partner for a quote that separates one-time setup, recurring licensing, hosting and support.
Which Tyk components require a commercial license?
Tyk Gateway code is under the Mozilla Public License 2.0, except the ee folder, which uses a separate commercial Enterprise Edition license. The full Tyk Self-Managed platform, which includes 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 a hosted service with a free trial. Confirm the exact terms for your edition directly with Tyk before you rely on them in a budget.
Can a team run APISIX or Tyk Gateway without outside help?
A capable platform team can run either gateway in-house, but the work is not trivial. APISIX requires you to operate etcd for traditional and decoupled modes, or to manage file-driven standalone configuration, and to maintain its Lua and plugin runner setup. Tyk requires Redis and, if you use the commercial platform, Dashboard and PostgreSQL. Outside help is most useful for initial architecture, hardening, upgrades and documentation. DeployOpen offers implementation, hardening, upgrades and retainer-based support on fixed-scope terms, and a written scope will state what is included.
How long does a proof of concept take, and what does it depend on?
No supplied fact gives a duration for a proof of concept, so ask for a timeline in the written scope rather than relying on a general figure. The length depends on how many routes and authentication flows you need to prove, whether you require the commercial Tyk components, how much of your identity provider integration is in scope, and whether your Kubernetes or VM target already exists. Ask for milestones, the test cases that define success, and what the client team must provide.
How does Kubernetes operation differ between APISIX and Tyk?
APISIX offers traditional, decoupled and standalone deployment modes, and standalone mode can load configuration from a YAML or JSON file that is hot-reloaded when it changes. Tyk Gateway can be installed on Kubernetes with the tyk-oss Helm chart, and its Operator, which handles declarative management, requires a license. Confirm which Kubernetes integration pattern you need, how configuration will move through your GitOps pipeline, and which component handles ingress before you compare operational effort.
What should we include in a written scope when comparing the two gateways?
Start with the protocols you must carry, such as HTTP, gRPC, WebSocket, GraphQL or TCP, and the authentication flows your identity provider needs, including OpenID Connect, JWT or client certificates. Add the plugin or middleware you must write yourself and the languages your team will use, the deployment mode, and the editions and licenses in scope. Require a pass or fail test list, the upgrade path for the version you choose, and the handover documentation. Ask each vendor or partner to price the same written scope so the comparison is fair.
Which gateway is harder to exit later?
Switching cost depends on where each gateway stores its routing and policy logic. APISIX stores configuration in etcd in traditional and decoupled modes, or in a file or API in standalone mode, so exporting routes and plugin settings is a matter of preserving that configuration and your custom plugins. Tyk stores API definitions and policies in its own configuration, and the commercial Dashboard adds management data in PostgreSQL. Ask for a migration plan that covers both route definitions and custom middleware before you commit.
How DeployOpen helps you choose and implement a gateway
DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms inside your own infrastructure, so the APISIX or Tyk decision is tested against your real traffic, identity provider and Kubernetes setup. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope names which gateway components, deployment mode and protocols are in or out for your environment.
- We confirm which Tyk components you would license, such as Dashboard, Developer Portal and Operator, before any build starts.
- Scope records identity provider, OIDC flows and rate-limiting requirements so the comparison is judged on your use case.
How we build
- We stand up the chosen gateway in your cloud account, data center or air-gapped network, with configuration stored as your team specifies.
- Plugin or middleware work covers authentication, traffic control and logging, written in the languages your team will maintain.
- Testing covers route behavior, authentication flows, failover and configuration reload under realistic traffic patterns you supply.
How we hand over
- Deliverables include architecture notes, runbooks for configuration changes, and upgrade steps for the release line you choose.
- We document licensing boundaries so your team knows which features depend on a commercial Tyk license and which do not.
- Handover includes walkthroughs with platform, security and compliance staff, plus evidence records for your assessors.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover tracking of APISIX and Tyk release notes, so your team reviews upgrades on a planned schedule.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
