MuleSoft's Flex Gateway is fast, lightweight, and powerful. It helps us control and secure APIs close to where they run. But to use it well, we must choose the right way to deploy it. In this post, we explore four key deployment patterns: Standalone, Sidecar, Ingress, and Egress. We’ll describe each one and explain when to use it.
Standalone Deployment
In this pattern, Flex Gateway runs by itself. It does not share its container or machine with any other app. It handles API traffic directly. Flex Gateway acts as a standalone unit. It serves as the first point of contact for requests moving through the system.This gateway watches over one or many internal API flows. Every request travels through Flex Gateway before it reaches the APIs meant for internal use.
This means no outside exposure. Flex Gateway becomes the gatekeeper.
Traffic passes through Flex Gateway before reaching the consumer APIs. It applies security, rate limits, and other policies.
When to use it:
Use standalone when we want clear separation. This pattern works best when APIs are spread across many systems. It gives us full control over traffic. We can update the gateway without touching the apps.
Sidecar Deployment
In the sidecar model, Flex Gateway runs next to the application it protects. Both the gateway and the app share the same pod or unit, often inside a Kubernetes environment. They operate independently but stay close, like two parts of one machine.Flex Gateway listens to every API request, applies policies, and then passes it to the app. Because they run side by side, communication is fast and efficient. This setup gives us fine-grained control over each service.
Sidecar deployment is ideal in microservices architectures. It allows us to apply different rules to each service, based on its purpose or sensitivity. We don’t need a central gateway to handle all traffic. Instead, each service gets its own lightweight guard.
This pattern works well in modern, container-based platforms. It blends flexibility with speed. We can update policies for one service without affecting others. It also supports local traffic management, keeping everything inside the cluster.
When to use it:
Use sidecar when we want tight control over how individual services handle traffic. It’s best for distributed systems where each service needs its own layer of protection and monitoring. Use the sidecar pattern in containerized environments like Kubernetes clusters or Docker deployments. It is perfect when we want to manage traffic for each service without leaving the cluster. The gateway is close to the app, so responses are fast.
Ingress Deployment
In the ingress model, Flex Gateway stands at the edge of the system. It manages all external traffic entering the internal network. Every request from the outside world must pass through the gateway before reaching the protected APIs.This pattern is most often used. It is the most common deployment model for Flex Gateway. It offers a central point of control, where we apply security, routing, and monitoring rules.
Flex Gateway is typically placed behind a load balancer, which helps distribute incoming requests evenly. The consumer application is outside the network. It does not share the same environment as the APIs or the gateway. This makes the ingress setup ideal for public-facing services.
In some cases, Flex Gateway can serve as both an ingress and an egress point—controlling traffic both in and out of the system.
When to use it:
Use ingress when we want to manage who comes in from outside. It helps us protect internal APIs and guide traffic safely and efficiently. This pattern is ideal for cloud or hybrid environments with many external consumers.
Egress Deployment
In the egress model, Flex Gateway controls outbound traffic. It sits at the edge of the internal network, inspecting requests that leave the system and head toward external APIs or services.This pattern is important when we want to apply security or compliance rules to data that exits our trusted environment. Flex Gateway can enforce policies such as logging, rate limiting, or restricting access to certain external domains. It acts like a final checkpoint, ensuring only approved traffic leaves the system.
In egress deployments, the consumer APIs or services live outside the organization’s network. These may be third-party platforms, external partners, or public cloud APIs. Flex Gateway reviews each request before it leaves, helping prevent data leaks and unauthorized access.
This pattern is useful in industries with strict data controls—such as finance, healthcare, or government. It also supports zero-trust security models, where every connection is verified, even if it’s outbound.
In some cases, Flex Gateway can play a dual role, handling both ingress and egress traffic. This allows us to manage and monitor traffic flowing in both directions from a single point.
When to use it:
Use egress when protecting data that leaves the network is as important as guarding what comes in. It’s ideal for environments that connect to external services and need full visibility into outbound requests.
Conclusion
In summary, each pattern fits a different need.- Choose standalone for flexibility and control.
- Choose sidecar for speed and tight integration.
- Choose ingress for central control of incoming traffic.
- Choose egress for guarding data that goes out.