3scale end of life: your options explained

Red Hat has announced that 3scale API Management 2.x is the last major release of the product. Full support ends on 30 June 2027. Extended Life Support for self-managed installations ends on 30 June 2029. The hosted SaaS offering shuts down in June 2027. The dates are Red Hat's, published on its 3scale life-cycle page; check it for the current wording before you plan around them.

If you run 3scale in production, none of this breaks anything today. It does mean that the clock is running on three things at once: security fixes, the hosted option, and the people who still know the platform well. This article sets out what changes when, and the three paths that actually work.

What the dates mean in practice

Until June 2027 nothing changes for a subscription customer: fixes, advisories and support continue. Self-managed customers who move to Extended Life Support after that date keep receiving critical fixes until June 2029, but no new features and, in practice, a slower cadence.

From June 2027 the hosted SaaS no longer exists. Anyone on it has to be somewhere else by then: a self-managed 3scale, or another gateway. For a Nigerian institution this coincides with the CBN data-localisation deadline of 1 January 2027, which already requires the API layer of payment systems, its identity provider, keys and logs, to run in Nigeria. A hosted gateway abroad fails both tests.

From June 2029 no fix comes from Red Hat at all. The components keep running; the question is who patches OpenResty, Ruby on Rails and Redis underneath them when the next advisory lands.

What is actually at risk

An API gateway is not a peripheral component. It holds the credentials of every consumer, the rate limits that protect the core, and a record of every call. Three things degrade once support is gone:

• Security. Advisories keep arriving for OpenResty, Rails and Redis. Without a maintained build, each one becomes a manual backport or an accepted risk.
• Operability. 3scale is several moving parts: APIcast, Porta, Apisonator, Zync, the operator. When the engineer who set it up leaves, the runbooks tend to leave with them.
• Compliance evidence. Auditors ask who supports the platform in the payment path. "Nobody, since 2029" is not an answer a compliance officer wants to give.

Path one: stay on 3scale under independent support

The open-source 3scale components are released under the Apache License 2.0. They can be built, patched and run by anyone with the skills, which is what independent support means: a provider that answers tickets, tracks advisories and, where Red Hat ships no fix, builds a patched image of APIcast, Porta or Apisonator and tests it before you deploy it.

This is the right path when the platform works, the APIs are stable, and a migration would compete with the CBN programme for the same people. It buys time on your terms rather than the vendor's, and it can run past 2029 for as long as a contract does.

Two things to check before signing with anyone: whether they can really rebuild the Ruby, OpenResty and Redis layers, and whether they say so in writing. Advisories alone are free; patched builds are the service.

Path two: migrate to Red Hat's successor

Red Hat's own direction is Connectivity Link, built on the Kuadrant project: Gateway API with Envoy, and rate limiting and authentication expressed as Kubernetes policies. For a team that stays on OpenShift it is the natural target, because the platform, the identity provider and the operations model do not change; only the gateway does.

The work is a mapping exercise. Every 3scale plan, limit and policy becomes a route, a RateLimitPolicy or an AuthPolicy. Consumers keep authenticating against the same Keycloak. Both gateways run in parallel behind a traffic split, limits and analytics are compared daily, and APIs move one at a time with a rollback defined before each switch. Done properly, no partner changes a credential.

Path three: migrate to another open-source gateway

If OpenShift is not a given, or the team wants a gateway with a larger community, the usual candidates are Kong Gateway, Apache APISIX and Gravitee. Each covers the 3scale feature set: plans and rate limits, key and token validation, a developer portal, analytics. The differences are in the plugin ecosystems, the storage they rely on and how policies are expressed.

The migration method is the same as above: inventory, policy mapping, parallel run, cut-over API by API. The extra step is choosing the target with the workload in front of you rather than from a comparison table, which is why an assessment comes first.

How to decide

Three questions settle most cases:

1. Do the APIs change often? If not, staying on 3scale under support is cheap and safe. If they do, the gateway is a live part of your delivery pipeline and a maintained one pays for itself.
2. Is OpenShift staying? If yes, Kuadrant keeps everything else in place. If not, look at Kong, APISIX or Gravitee alongside the platform decision.
3. What else is happening before 2027? For Nigerian institutions the CBN programme takes priority. A gateway migration that competes with it for people is a migration that slips; support that holds the line until 2028 may be the better sequence.

Whichever path you take, the first step is the same: an inventory of what you run, which versions, which custom policies, and which advisories are open. That is a two-week exercise and it turns the end-of-life dates from a worry into a plan.

NuxFamily provides independent support for open-source 3scale and migrations to Kuadrant, Kong, APISIX and Gravitee. A free 30-minute assessment call is the usual way to start.

3scale and Red Hat are trademarks of Red Hat, Inc. NuxFamily is an independent service provider and is not affiliated with, endorsed by or sponsored by Red Hat, Inc.