Enterprise API governance meets cloud-native agility — deployed in minutes, running anywhere. Here's everything you need to know.
APIs are the nervous system of modern business. From mobile apps to enterprise systems, from microservices to AI platforms — everything talks through APIs. But as companies expand across hybrid and multi-cloud environments, governing that nervous system becomes a serious challenge.
Before Flex Gateway, organisations were forced into an uncomfortable compromise between heavyweight enterprise control and cloud-native agility. Flex Gateway closes that gap — entirely.
In this post we'll unpack what Flex Gateway is, why it exists, and get it running in under 10 minutes with a real backend API.
Section 01
The API Governance Dilemma
Every organisation managing APIs at scale eventually hits one of three walls. If any of these sound familiar, you've felt the problem Flex Gateway was built to solve.
🦕
Heavyweight Legacy Gateways
Slow to deploy. Painful to scale. Architecturally opinionated in ways that actively fight your modern stack.
☁️
Cloud-Native Gaps
Nimble proxies lack the deep policy management, lifecycle control, and analytics enterprises depend on.
🌐
Hybrid Complexity
Multiple gateways across on-prem and clouds creates inconsistent policies, fractured observability, and operational risk.
These aren't niche edge cases — they're the daily reality of platform engineering teams. The traditional options force a choice between governance and agility. Flex Gateway refuses to accept that trade-off.
Section 02
What Is Flex Gateway?
Flex Gateway is a lightweight, Envoy-based API gateway built for modern distributed architectures. Unlike the traditional Mule Runtime — a full integration engine — Flex Gateway is purpose-built for one job: standing in front of your APIs and enforcing governance with minimal overhead.
⚡
Built on Envoy
Flex Gateway's runtime is based on Envoy Proxy — the same battle-tested engine behind Istio and AWS App Mesh. You get proven performance characteristics and a familiar extension model via WebAssembly (WASM) custom policies.
The headline capability: it runs anywhere.
🐳
Container
Docker
Single container, local or cloud. Pull image and run in seconds.
Works out of the box
☸️
Orchestration
Kubernetes
Helm chart deployment, sidecar or standalone mode.
Helm ready
🖥️
Native
Linux
Native service on bare metal or VMs. Supports systemd.
Native service
☁️
Serverless
Fargate / GCR
AWS Fargate, Google Cloud Run — fully serverless operation.
Zero infra
Section 03
Architecture Overview
Flex Gateway separates into two planes: a control plane (Anypoint Platform or YAML config) and a data plane (the Envoy-based runtime). This separation is what makes it so flexible — you can swap the control plane without touching the runtime.
Control Plane → Data Plane → Backend Services
🔗 Connected Mode⚙ Local Mode
Control Plane
☁️ ANYPOINT PLATFORM
API Manager · Analytics · Policy Hub · Design Center
The lightweight Envoy-based data plane that processes API traffic with minimal overhead and maximum throughput.
⚙ Core Engine
☁️
Control Plane
Anypoint Platform
Central hub for policy definition, API lifecycle management, analytics, and observability across all environments.
🔗 Connected Mode
📄
Config Layer
YAML Configuration
Declarative spec defining listeners, routes, and policies. Version-controlled, GitOps-friendly, no platform required.
⚙ Local Mode
🗄️
Upstream
Your Backend Services
Any API, any language — Node.js, Java, Python, .NET. Hosted anywhere: on-prem, cloud, or hybrid.
🌐 Language Agnostic
Modes
Connected vs Local Mode
Understanding the two operational modes is fundamental before you deploy anything.
Feature
☁ Connected Mode
⚙ Local Mode
Config source
Anypoint Platform
YAML files
Internet required
Yes
No
Analytics & dashboards
Full
Limited
GitOps workflow
Possible
Native fit
Best for
Enterprise, multi-region
Edge, air-gapped, dev
Section 04
Hands-On: First Gateway in 10 Minutes
Enough theory. Let's build something real. We'll spin up a Node.js backend, configure Flex Gateway in Local Mode, run it in Docker, and verify traffic flows correctly — end to end.
01
Create the Mock Backend API
A minimal Express server simulating a product catalog service — the upstream target Flex Gateway will route to.
server.js
constexpress=require('express');
constapp=express();
constPORT=3000;
app.use(express.json());
constproducts= [
{ id:1, name:'API Gateway', category:'infrastructure', status:'active' },
{ id:2, name:'Service Mesh', category:'networking', status:'active' },
{ id:3, name:'Event Bus', category:'messaging', status:'beta' },
];
// List all products
app.get('/api/products', (req, res) => res.json(products));
// Get single product by ID
app.get('/api/products/:id', (req, res) => {
constproduct= products.find(p => p.id ===parseInt(req.params.id));
product
? res.json(product)
: res.status(404).json({ error:'Product not found' });
});
// Health check with timestamp
app.get('/health', (req, res) =>
res.json({ status:'UP', timestamp:newDate() })
);
app.listen(PORT, () => console.log(`✅ Backend API on http://localhost:${PORT}`));
The entire gateway behaviour — listeners, routes, upstream targets, and policies — expressed as a single declarative YAML file. Version-controllable. GitOps-ready.
gateway-config.yaml
apiVersion:gateway.mulesoft.com/v1alpha1kind:Gatewaymetadata:name:product-gatewaylabels:environment:developmentteam:platform-engineeringspec:# ── Network Listener ─────────────────────────────────────────listeners:-name:http-listenerport:8081protocol:HTTPhost:"0.0.0.0"# ── API Routes ───────────────────────────────────────────────routes:# Public product catalog — read-only-id:public-productspath:-"/api/products"-"/api/products/*"methods: ["GET"]
upstream:url:"http://host.docker.internal:3000"timeout:30s# Health check — rate-limited to protect the endpoint-id:health-checkpath:-"/health"-"/status"methods: ["GET"]
upstream:url:"http://host.docker.internal:3000"policies:-rate-limiting:maxRequests:100period:60# 100 requests per minute max
💡
host.docker.internal
This hostname resolves to your host machine from inside a Docker container. Works automatically on macOS and Windows Docker Desktop. On Linux, add --add-host=host.docker.internal:host-gateway to your docker run command.
03
Run Flex Gateway with Docker
Pull the official image and mount your config file. The gateway starts in seconds.
terminal — docker run
# Pull the latest Flex Gateway imagedocker pull mulesoft/flex-gateway:latest
# Launch the gateway with your config mounteddocker run -d \
--name flex-gateway \
-p 8081:8081 \
-v $(pwd)/gateway-config.yaml:/etc/mulesoft/flex-gateway/conf.d/gateway-config.yaml \
mulesoft/flex-gateway:latest
# Confirm the container is healthydocker psdocker logs flex-gateway
Shell
Volume mount path
Status
macOS / Linux
$(pwd)/gateway-config.yaml
✓ Works
Windows PowerShell
${PWD}\gateway-config.yaml
✓ Works
Windows cmd.exe
C:\projects\gateway-config.yaml
⚠ Full path
04
Test Your Gateway
Your backend runs on port 3000. The gateway listens on port 8081. All traffic now flows through the gateway layer — routed, controlled, and observable.
terminal — test requests
# List all products (via gateway)curl http://localhost:8081/api/products
# Fetch a single product by IDcurl http://localhost:8081/api/products/2
# Health check (rate-limited route)curl http://localhost:8081/health
# Request with custom headers — gateway passes them upstreamcurl-H"X-API-Key: demo-key" \
-H"Accept: application/json" \
http://localhost:8081/api/products
# Test 404 handlingcurl http://localhost:8081/api/products/999
# → {"error":"Product not found"}
🔍
What Just Happened
Your backend is now completely decoupled from consumers. The upstream URL, paths, and policies are all defined in one YAML file. Move your backend to a different port, host, or cloud region — consumers don't see a thing. That's the power of a gateway layer.
Part 1 Wrap-up
Key Takeaways
01
Architecture
Flex Gateway is a lightweight, Envoy-based API gateway built for cloud-native and hybrid architectures.
⚡
02
Operation Modes
Runs in Connected Mode (Anypoint Platform-managed) or Local Mode — YAML config, zero platform dependency.
🔀
03
Configuration
Fully declarative — routes, policies, and listeners are all expressed as versioned code.
📄
04
Deployment Targets
Runs on Docker, Kubernetes, native Linux, and serverless — your stack, your choice.
🚀
05
Out of the Box
Even a basic setup gives you routing, policy enforcement, and backend decoupling from day one.
✅
Coming Up
What's in Part 2
Part 1 was the foundation. In Part 2 we go production-grade — real Kubernetes deployments, enterprise security policies, and a CI/CD pipeline that deploys config changes with zero downtime.
☸️
Kubernetes
Helm chart deployment with HPA auto-scaling
🔐
Security
JWT, OAuth 2.0 introspection, and IP allowlisting
🚦
Traffic Policies
Rate limiting by client, circuit breaking, request transformation
🔄
CI/CD
GitHub Actions pipeline for automated zero-downtime config deploys
Comments
🍪 We use cookies to enhance your experience and analyze traffic.
See our Cookie Policy.
Comments
Post a Comment