Flow Proxy: Edge Processing Today, Forwarding Ahead
You'll notice a name change in your Universal Agent settings: Flow Proxy is now Flow Proxy (Edge Processing). The engine, configuration, and behavior are identical. Nothing breaks, nothing migrates. We're updating the name because Flow Proxy is growing into a collection of modes, and we want the labels to be clear about what each one does.
- Nothing changes operationally. Your existing Flow Proxy capability continues to decode, enrich, and sample flow at the edge exactly as it does today.
- The name tells you what it does. "Edge Processing" makes it explicit that this mode handles decoding and enrichment locally before forwarding to Kentik.
- A new collection mode is coming alongside it. Flow Proxy (Forwarding), a lightweight forwarding engine, is entering limited release for select customers. The name change keeps the two engines distinct.
What's new?
Flow Proxy (Edge Processing) is the engine you already run. It decodes, enriches (SNMP/rDNS), and samples flow at the edge before forwarding to Kentik. Same binary, same config, same behavior. The label in the Universal Agent UI now reads "Flow Proxy (Edge Processing)" instead of "Flow Proxy."
Flow Proxy (Forwarding) is a new, separate capability entering limited release. It captures raw flow and ships it to Kentik with minimal local processing, using roughly 10x less compute than edge decoding. SaaS-side enrichment only available in Edge Processing today is in active development for Forwarding Mode to complement it. This is available to select customers today; broader availability will follow.
What this means for Flow Proxy users
If you run Flow Proxy today, here's what to expect going forward:
- Now: You'll see the updated name in your Universal Agent settings. No action required.
- Soon: Flow Proxy (Forwarding) becomes available more broadly as a separate capability for select customers who want lightweight collection without edge enrichment.
- Next: We're building a unified Flow Proxy experience that combines both engines into a single capability with a mode selector. Instead of managing two separate capabilities on your agents, you'll pick a delivery mode from one place. Fewer capabilities to configure, fewer to monitor, and a clear path to switch between engines as your needs change.
Here is an early view into a prototype we've been working on for mode selection (this is early work and subject to change):
If you run Kproxy (legacy) as a standalone agent today you should still be planning to migrate to a Universal Agent Flow Proxy by the May 1, 2027 deprecation date as previously announced to avoid running unmaintained agents and to benefit from our latest innovations.
No action required
No action is needed. The name update is already live in the Universal Agent for all customers. We will be posting a follow up announcement once the unified Flow Proxy experience is live.