Plugins are built using WebAssembly (Wasm) format and use Proxy-Wasm APIs.
Wasm is an open and
standardized binary instruction format that enables a host to load and run
Wasm modules with customer-provided code. Wasm has a number of benefits for
executing customer code, including sandboxing for security, support for
multiple languages, portability, broad and growing support within the
industry, and improved performance relative to other VM-based options such
as JavaScript.
Proxy-Wasm is an open
source project started by Google. It defines APIs that let you
customize the behavior of network proxies by implementing callbacks to be
executed during HTTP request and response processing.
How plugins work
You can use Service Extensions with Application Load Balancers
and Media CDN as follows:
Service Extensions helps you create the following key resources
that help you add custom code in the processing path:
Plugins, which contain the custom code that you want to deploy.
Plugin versions, which are versions of your Wasm module. You can indicate
which version of your Wasm module that a plugin is to use as its main (active) one.
Limitations
This section lists some limitations with plugins.
Limitations on resources
Plugins are strictly constrained in how many resources they can use:
A plugin can use up to 1 msec of normalized vCPU per invocation. A
CPU millisecond is platform dependent, but the normalized platform is
approximately equal to a processor with a 4 GHz clock speed. An
invocation is an independently billed phase of execution, which can be
request headers, request body, response headers, or response body.
A plugin can use up to 16 MiB of memory per VM instance. An instance
must be able to serve up to 1000 concurrent requests, which means that a
plugin can hold up to 16 KiB of memory per stream. Keep in mind that
the total memory use includes global state and stack allocations.
Use the plugin tester to
benchmark a plugin's CPU and memory characteristics.
Limitations on APIs
Plugins can use a subset of the Proxy-Wasm ABI. Plugins don't support
timers, custom metrics, shared data, shared queues, or outbound network
calls.
HTTP trailer events aren't supported.
Limitations with header manipulation
The maximum size of any mutation (headers or body chunks) is 128 KiB.
Plugins can't override the processing mode of the ext_proc stream.
Header manipulation through plugins is not supported for some headers. The
processor ignores any modifications in these headers, and continues to
process the request.
For Media CDN plugins, the following are not supported:
When you configure either REQUEST_BODY or RESPONSE_BODY for an
extension, if the load balancer receives a matching request, it removes the
Content-Length header from the response and switches to
chunked body encoding.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[],[],null,["# Plugins overview\n\nThis page provides overview information about the integration of\nplugins with Cloud Load Balancing Application Load Balancers and\nMedia CDN.\n\nThis feature is in [Preview](/products#product-launch-stages) for Media CDN.\n\nPlugins are built using WebAssembly (Wasm) format and use Proxy-Wasm APIs.\n\n- [Wasm](https://webassembly.org/) is an open and\n standardized binary instruction format that enables a host to load and run\n Wasm modules with customer-provided code. Wasm has a number of benefits for\n executing customer code, including sandboxing for security, support for\n multiple languages, portability, broad and growing support within the\n industry, and improved performance relative to other VM-based options such\n as JavaScript.\n\n- [Proxy-Wasm](https://github.com/proxy-wasm) is an open\n source project started by Google. It defines APIs that let you\n customize the behavior of network proxies by implementing callbacks to be\n executed during HTTP request and response processing.\n\nHow plugins work\n----------------\n\nYou can use Service Extensions with Application Load Balancers\nand Media CDN as follows:\n\n1. [Prepare plugin code](/service-extensions/docs/prepare-plugin-code) as follows:\n\n 1. Create custom code by using one of the Proxy-Wasm SDKs:\n\n - [Rust](https://github.com/proxy-wasm/proxy-wasm-rust-sdk)\n\n - [Go](https://github.com/proxy-wasm/proxy-wasm-go-sdk)\n\n - [C++](https://github.com/proxy-wasm/proxy-wasm-cpp-sdk)\n\n 2. Compile your code into a Wasm module.\n\n 3. Upload your compiled plugin code to an Artifact Registry repository.\n\n2. [Create a plugin](/service-extensions/docs/create-plugin) that contains the\n uploaded plugin code.\n\n3. Configure the plugin in [Cloud Load Balancing extensions](/service-extensions/docs/lb-extensions-overview)\n or [Media CDN extensions](/service-extensions/docs/media-cdn-extensions-overview).\n\nPlugin resources\n----------------\n\nService Extensions helps you create the following key resources\nthat help you add custom code in the processing path:\n\n- *Plugins*, which contain the custom code that you want to deploy.\n\n- *Plugin versions*, which are versions of your Wasm module. You can indicate\n which version of your Wasm module that a plugin is to use as its main (active) one.\n\nLimitations\n-----------\n\nThis section lists some limitations with plugins.\n\n### Limitations on resources\n\nPlugins are strictly constrained in how many resources they can use:\n\n- A plugin can use up to 1 msec of normalized vCPU per invocation. A\n CPU millisecond is platform dependent, but the normalized platform is\n approximately equal to a processor with a 4 GHz clock speed. An\n invocation is an independently billed phase of execution, which can be\n request headers, request body, response headers, or response body.\n\n- A plugin can use up to 16 MiB of memory per VM instance. An instance\n must be able to serve up to 1000 concurrent requests, which means that a\n plugin can hold up to 16 KiB of memory per stream. Keep in mind that\n the total memory use includes global state and stack allocations.\n\nUse the [plugin tester](/service-extensions/docs/plugin-best-practices#testing) to\nbenchmark a plugin's CPU and memory characteristics.\n\n### Limitations on APIs\n\n- Plugins can use a subset of the Proxy-Wasm ABI. Plugins don't support\n timers, custom metrics, shared data, shared queues, or outbound network\n calls.\n\n- HTTP trailer events aren't supported.\n\n### Limitations with header manipulation\n\n- The maximum size of any mutation (headers or body chunks) is 128 KiB.\n\n- Plugins can't override the processing mode of the `ext_proc` stream.\n\n- Header manipulation through plugins is not supported for some headers. The\n processor ignores any modifications in these headers, and continues to\n process the request.\n\n For Media CDN plugins, the following are not supported:\n - Headers: `CDN-Loop`, `connection`, `keep-alive`, `proxy-authenticate`, `proxy-authorization`, `proxy-connection`, `te`, `trailers`, `transfer-encoding`, `upgrade`, or `X-user-IP`.\n - Headers starting with: `x-forwarded`, `x-goog-`,`x-google`, `x-gfe`, or `x-amz-`.\n\n For Cloud Load Balancing plugins, the following are not supported:\n - Headers: `connection`, `keep-alive`, `proxy-authenticate`,\n `proxy-authorization`, `proxy-connection`, `sec-user-ip`, `te`,\n `trailer`, `transfer-encoding`, `upgrade`, `x-dont-count-ads`,\n `x-dont-show-ads`, `x-gr`, `x-proxyuser-ip`, or `x-user-ip`.\n\n Additionally, for `LbTrafficExtension`, these headers are also not\n supported: `method`, `authority`, `scheme`, or host headers.\n - Headers starting with: `sec-gfe-`, `sec-google-`, `x-amz-`,\n `x-forwarded-`, `x-gfe-`, `x-goog-`, `x-google-`, or `x-gproxy-`.\n\n### Limitations with HTTP/1.1 clients and backends\n\nWhen you configure either `REQUEST_BODY` or `RESPONSE_BODY` for an\nextension, if the load balancer receives a matching request, it removes the\n`Content-Length` header from the response and switches to\nchunked body encoding.\n\nWhat's next\n-----------\n\n- [Prepare the plugin code](/service-extensions/docs/prepare-plugin-code)\n- [Create a plugin](/service-extensions/docs/create-plugin)"]]