Workers Compatibility (Beta): port Cloudflare Workers and Lambda into FastFN¶

Verified status as of March 28, 2026. Runtime note: FastFN auto-installs function-local dependencies from requirements.txt / package.json; host runtimes are required in fastfn dev --native, while fastfn dev depends on a running Docker daemon. This beta feature reduces migration overhead so teams can reuse existing handlers with minimal changes.

Goal¶

Port existing code with small deltas:

Cloudflare Workers (fetch(request, env, ctx))
AWS Lambda Node/Python (handler(event, context)), including Node callback handlers (handler(event, context, callback)).

Current beta scope¶

Implemented for:

Node
Python

Per-function activation in fn.config.json:

{
  "invoke": {
    "adapter": "cloudflare-worker"
  }
}

Supported values:

native (default): FastFN contract (handler(event))
aws-lambda
cloudflare-worker

Real 1:1 mapping examples¶

1) Cloudflare Worker (real repo example)¶

Reference used:

advissor/nodejs-cloudflare-workers/src/index.js

That example uses:

export default { async fetch(request, env) { ... } }
CORS preflight
path versioning (/api/v1/...)
Response JSON output

In FastFN beta, business logic maps 1:1. Current practical Node delta is export syntax (CommonJS):

module.exports = {
  async fetch(request, env, ctx) {
    return new Response('ok');
  },
};

fn.config.json:

{
  "invoke": {
    "adapter": "cloudflare-worker"
  }
}

2) AWS Lambda Node (official docs)¶

Official reference:

AWS Lambda Node.js handler

aws-lambda adapter supports:

async handler: handler(event, context)
callback handler: handler(event, context, callback)

AWS official note:

AWS recommends async/await and documents callback-based handlers as supported only up to Node.js 22.

fn.config.json:

{
  "invoke": {
    "adapter": "aws-lambda"
  }
}

Node callback example¶

exports.handler = (event, context, callback) => {
  callback(null, {
    statusCode: 200,
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ ok: true, requestId: context.awsRequestId }),
  });
};

Beta notes¶

cloudflare-worker reproduces handler shape and core request/response behavior, not Cloudflare isolate/distributed infrastructure.
For Workers-style in Node today, module.exports.fetch = ... is the most stable form.
In Lambda callback mode, FastFN resolves on the first valid completion (callback or Promise), with double-resolution guards.

Full plan¶

Phase 0 (done)¶

invoke.adapter per function.
Node/Python aws-lambda compatibility.
Node/Python cloudflare-worker compatibility.
Node Lambda callback support.
Dedicated adapter unit tests.

Phase 1 (next)¶

Native Node ESM support for export default { fetch }.
1:1 provider fixtures under tests/fixtures/compat/.
Adapter contract tests (headers/query/status/binary/errors).

Phase 2 (hardening)¶

ctx.waitUntil now runs as best-effort background work with rejection logging; cancellation policy is the remaining gap.
Clear parity boundary doc (what is emulated vs not emulated).
CI regression matrix for adapters.

Phase 3 (beta to stable)¶

Exit criteria (coverage, stability, migration feedback).
Provider migration guides.
Compatibility versioning strategy if needed.

References¶

Key takeaway¶

Compatibility mode lets you reuse existing handlers while you migrate, which is often faster and safer than rewriting working business logic on day one.

What to keep in mind¶

The adapter matches handler shape and request/response mapping, not the provider's full platform behavior.
Test headers, body encoding, errors, and callback or Promise completion before moving production traffic.
Keep native for new endpoints unless you have a real compatibility reason to do otherwise.

When to use it¶

Use cloudflare-worker or aws-lambda adapters to bring existing code over with minimal edits.
Stay with native for greenfield FastFN code.
Treat the beta label seriously for latency-sensitive or compliance-sensitive paths until the contract matrix is fully hardened.