Express Gateway placed a common entry point in front of application APIs. It routed incoming requests and applied policies such as authentication or rate limits using Node.js and Express middleware. That let services share those controls instead of implementing all of them separately. The project is no longer maintained, so existing users need a replacement that preserves the request behavior, credentials and custom middleware their clients depend on.
Deployment and operating notes
The recovered chart packages Express Gateway, a Node.js gateway built around Express middleware. Its upstream README now carries a deprecation notice stating that the project is no longer maintained. This does not retire Express itself, and it does not prove that another API gateway can execute the same policies or plugins.
Before replacement, export gateway and system configuration, consumers, credentials, custom plugins and any backing data store. Inventory policy order, authentication, rate limits, rewrites and error responses because those are part of the external API contract. Evaluate a supported gateway using representative allowed and denied requests, not just route reachability. Custom JavaScript middleware may need rewriting or moving into a separate service. Keep credentials out of migration logs and plan how tokens or API keys remain valid or are rotated. Run the replacement on a separate address, compare behavior, then switch a limited set of clients. A route rollback is useful only while the original credential and state dependencies remain intact.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Original publication: 2018-09-09T23:11:30+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
Express Gateway is an API Gateway that sits at the heart of any microservices architecture. This chart bootstraps all the components needed to run Express Gateway on a Kubernetes cluster using the Helm package manager.
Express Gateway is an API Gateway that sits at the heart of any microservices architecture, regardless of what language or platform you’re using. Express Gateway secures your microservices and exposes them through APIs using Node.js, ExpressJS and Express middleware. Developing microservices, orchestrating and managing them now can be done insanely fast all on one seamless platform without having to introduce additional infrastructure.
Main Features
- Built Entirely on Express and Express Middleware
- Dynamic Centralized Config
- API Consumer and Credentials Management
- Plugins and Plugin Framework
- Distributed Data Store
- CLI
- REST API
Roadmap
The Express Gateway roadmap consists of three parts:
- FeatHub – features requested and voted on by any community member, this feeds into the…
- Roadmap – the published roadmap of all features under considerations and projected timeframes, the highest priority items are put into the…
- Waffle board – a real-time as a public task board on Waffle.io with the backlog of stories for the next release
With Express Gateway, you actually get to leverage the vast ecosystem of Express.js middleware and another open source to get the job done.
Community Driven
As part of our ongoing commitment to the community, as sponsors of the Express Gateway project, we expanded on our initial ideas and built out a Roadmap that was flexible enough to adapt based on community input, but also sent the right external signal so if you or anyone else wanted to get more involved, we could share our initial vision.
Flexible
In several user interviews, a few key insights stood out. Even when you’re trying to launch an open source project, the same design thinking principles till apply. In order to attain the kind of flexibility we were looking for, the team decided to stick to a few core concepts:
- Create a gateway for any language, framework
- Make this gateway with all microservice use cases in mind
Simple
Above all else, we wanted to make Express Gateway simple. API Gateways and microservices are complicated enough.
Here are a few things we focused on during the initial build phase:
- * A declarative config separated from the code to control it all
- * Building some of the most commonly used gateway policies like OAuth2, rate limiting etc
- * A full-blown consumer and credential management system out of the box
- Auto-detect and hot-reload config changes
Plugging into our latest release
In case you missed it, we also just had a recent release that included an extensible Plugin Framework. Express Gateway 1.2.0 adds a new plugin engine that allows anyone to add their own extension entities within a plugin. Then you can install and utilize it dynamically within Express Gateway.
The Quick & Dirty:
An Express Gateway plugin acts as a container and has three key things:
- Package.json
- A folder for each entity extension
- Manifest.js
- The package.json declares all dependencies that the plugin requires, just like any Node.js modules.
- We got to work breaking down all of the installations, entity extension point folders, manifest.js, and more of that magic.
All about the code
But, how easy is it to get started with an open source API Gateway like Express Gateway?
Well, let’s see.
Get the start of a real-time app up and running, complete with authentication. First, install your dependencies by running.
The post Express Gateway appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →