Microsoft just put serverless compute on Azure Front Door
Azure Front Door now lets you run JavaScript functions at the edge during request processing. It is called Edge Actions, and it is in public preview. The idea is simple: instead of routing traffic to an origin server for every decision, you execute lightweight code at the closest edge Point of Presence (PoP) and react in real time.
The use cases are the kind you want close to the user. A/B testing without hitting the origin. Header manipulation for security policies. Request rejection based on payload inspection. Dynamic origin selection per request based on geo, device type, or custom headers. All of this happens at the edge, milliseconds from the client, before the request ever reaches your backend.
How it works
You write a JavaScript function, upload it to Azure Front Door through the portal or the rules engine configuration, and assign it to a route. When a request hits that route, Front Door executes your function at the edge before forwarding the request or returning the response. The function gets access to the full request object (headers, method, URL, body) and can return a modified request, a custom response, or an error.
Microsoft runs these in a Hyperlight sandbox. Hyperlight is Microsoft’s micro-VM technology for running untrusted code in a minimal virtual machine. It is the same isolation model they have been developing for Wasm workloads, repurposed here for JavaScript. This is a step up from the typical V8 isolate sandboxing you see in Edge Workers, Cloudflare Workers, or Deno Deploy. Hyperlight gives you hardware-level isolation between functions without the overhead of a full VM.
The constraints tell you a lot
The preview has hard limits that shape what you can build:
- Code size: 16KB max per action
- Execution time: 10ms max per request
- Versions: 3 max per action
- Supported: JavaScript (ES2020+)
16KB and 10ms is not where you build a complex application. It is where you build a decision. The constraint forces you to write focused, single-purpose functions. A routing rule. A header transform. A quick security check. If your logic needs more than 500 lines of JS, you should be running it at the origin, not the edge.
The 10ms execution limit is worth internalizing. That is fast. Your function does not have time for network calls, file reads, or heavy computation. You get the request, you inspect it, you make a decision, you return. Any I/O has to happen inline or not at all. This is serverless under the tightest constraints outside of eBPF.
One implication that is easy to miss: you cannot authenticate against a backend database at the edge. If your routing decision needs to check a user’s subscription tier or feature flag, that data has to be embedded in the request itself (JWT claims, custom headers from the client SDK) or encoded in the function. There is no connection pool, no cache, no KV store from the edge action. Plan for that upfront.
Where this fits in the CDN landscape
Cloudflare Workers have been doing this for years. Fastly has Compute@Edge. AWS has Lambda@Edge and CloudFront Functions. Edge compute is table stakes for modern CDNs. What makes Edge Actions interesting is the Azure Front Door integration.
Azure Front Door is not just a CDN. It is a global load balancer, a WAF, a TLS terminator, and a traffic router. Edge Actions slot into the request pipeline after the WAF rules and before the origin selection. That means your function runs after Azure has already blocked malicious traffic, decrypted TLS, and applied routing rules. You are working on clean, routed, inspected requests. Your function does not need to worry about the security layer that already handled the attack surface.
That matters more than raw runtime features. In the Cloudflare model, your Worker runs first, and you have to handle security yourself or layer it on top. With Edge Actions, you inherit the full Front Door security posture before your code executes. If you are already using Front Door with WAF policies and a rules engine, Edge Actions are a natural extension of the configuration you already have.
Getting started
If you have an Azure Front Door Standard or Premium profile, Edge Actions are available under the Rules Engine section in the portal. The Microsoft Learn docs have a quickstart covering the setup: create an action, write your JavaScript, assign it to a route. The 16KB limit means you will probably fit the whole thing in a single file, no bundler needed.
What would I use it for right now? A/B testing headers on a static site without modifying the origin. Blocking specific user-agent patterns at the edge before they hit the server. Rewriting redirect paths based on geography. Each of these is a 5-10 line function that saves a round trip to the origin and back.
Edge Actions are in public preview. No SLA, no production commitment yet. But the direction is clear: the edge is where decisions get made, and the origin is where work gets done. Microsoft wants you making those decisions in Azure Front Door, as close to the user as possible.