A per node proxy is a service mesh deployment pattern where one proxy or proxy set serves multiple workloads on the same host. It can reduce resource overhead and simplify some operational concerns, but it often introduces more complex routing, policy, and debugging workflows than a sidecar model.
How a per node proxy changes the service mesh model
A per node proxy places shared proxy capacity on each host rather than attaching a separate proxy to every workload. That shifts the mesh from a workload-isolated pattern to a host-shared pattern, which can reduce CPU and memory overhead while changing how traffic steering, policy enforcement, and troubleshooting are organized.
The main trade-off is granularity. A sidecar model usually makes traffic and policy boundaries easier to reason about for a single workload, while a per node proxy asks operators to manage routing and policy for multiple workloads through one shared dataplane. That can be efficient at scale, but the operational model becomes less direct when a host runs many services with different communication patterns.
Why teams use it
Teams often choose per node proxying when density and efficiency matter. Shared proxies can lower resource consumption, simplify some deployment mechanics, and reduce the overhead of running and updating a proxy for every workload instance.
The pattern can also fit environments where workloads are relatively stable on a host, or where operators want a smaller number of proxy processes to observe and maintain. In those cases, the architecture can make the service mesh less expensive to operate, especially on nodes with many small services.
That benefit comes with a design assumption: the host-level proxy becomes a common control point. When that proxy is responsible for multiple workloads, any routing mistake, policy defect, or observability gap can affect more than one service at once. The pattern is therefore attractive when efficiency is a real priority, but it should be adopted with awareness that the shared boundary increases the blast radius of operational errors.
Operational and security implications
Per node proxying changes how visibility, policy, and failure domains behave. Debugging can become harder because a single proxy instance may carry traffic for several workloads, making it less obvious which service caused an unexpected route, denied request, or latency spike. The model can also complicate identity-to-traffic attribution inside the mesh if the operator does not have strong metadata and telemetry.
From a security perspective, the shared proxy is a concentration point. If its configuration is weak, or if a compromise affects the proxy process or host networking path, the impact can extend across every workload using that proxy. Guidance in the OWASP API Security Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because the pattern depends on strong authorisation, logging, and configuration discipline around shared traffic paths.
When the mesh also carries workload identity, the shared proxy should be treated as security infrastructure, not just plumbing. The SPIFFE workload identity specification is a useful reference for thinking about how workload identity and trust material can be attached to runtime traffic decisions in a host-shared design.
How it compares with sidecar-based deployments
A sidecar proxy stays closer to the individual workload and usually offers more explicit per-service isolation. That can make policy scoping, troubleshooting, and blast-radius control easier, especially in mixed environments where different services have different trust requirements.
A per node proxy can be a better fit when the priority is consolidation rather than isolation. The trade-off is that the operator gives up some of the directness of per-workload control in exchange for a more compact dataplane. The right choice depends on whether the organisation values efficiency, isolation, or operational clarity more highly for the specific cluster.
For teams standardising mesh deployment decisions, the pattern is often part of a wider platform governance discussion. The mesh should be validated against baseline hardening and control expectations such as those described in CIS Benchmarks, especially where node-level controls, network paths, and configuration consistency are part of the deployment risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API Security Top 10 | Shared proxy routing and policy shape API access control and abuse exposure. |
| Recommendation — Review proxy-enforced API authorisation and log denied or unusual requests. | ||
| NIST SP 800-53 Rev 5 | AC — Access Control | Per-node proxies centralise enforcement of who may reach shared workload paths. |
| AU — Audit and Accountability | A shared proxy needs audit visibility to separate workload traffic and trace decisions. | |
| CM — Configuration Management | Host-shared proxies depend on consistent, tightly controlled mesh configuration. | |
| Recommendation — Apply AC controls to constrain shared proxy-mediated access paths. Enable AU logging to attribute proxy decisions to the affected workload. Use CM controls to validate and track proxy configuration changes. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Mesh traffic policy and trust handling map to cloud IAM-style control expectations. |
| Recommendation — Align shared proxy policy with IAM-managed trust and access rules. | ||
Practitioner Guidance
What to watch for: use a per node proxy only when the operational gain is worth the shared failure domain. It is most defensible in environments with strong node hardening, mature telemetry, and clear ownership of proxy policy and routing behaviour.
Governance implication: the proxy becomes a shared platform dependency, so teams should define who owns its configuration, how changes are validated, and what workload-level exceptions are allowed.
Practitioner takeaway: the pattern is efficient, but efficiency should not hide the fact that one proxy now speaks for many workloads.
Related resources from NHI Mgmt Group
- What is the difference between using shared IAM identity components and keeping node identity static per cluster?
- When is a reverse proxy better than a VPN for access control?
- What is the difference between a managed gateway and a reverse proxy in front of a gateway?
- How can teams spot proxy abuse on compromised Linux systems?
