Versioning and Rollout¶
Verified status as of March 28, 2026. Runtime note: FastFN auto-installs function-local dependencies from
requirements.txt/package.json; host runtimes are required infastfn dev --native, whilefastfn devdepends on a running Docker daemon. FastFN supports side-by-side versions (for examplev2) so you can ship changes without breaking existing clients.
1) Folder structure¶
Versioning is represented by a version subfolder under the function directory:
2) Example code¶
Default version (functions/hello/handler.js):
exports.handler = async (event) => {
const name = (event.query || {}).name || "World";
return { message: `Hello from V1, ${name}` };
};
Version v2 (functions/hello/v2/handler.js):
exports.handler = async (event) => {
const name = (event.query || {}).name || "World";
return { status: "success", data: { greeting: `Hello from V2, ${name}` } };
};
3) Calling default vs version¶
Default (if handler.js exists at the root of the function folder):
Versioned:
4) Rollout pattern¶
- Deploy the
v2/folder. - Test with
GET /hello@v2. - Migrate clients gradually.
- Remove the old default version when traffic reaches zero.
Next: Authentication and Secrets
Flow Diagram¶
flowchart LR
A["Client request"] --> B["Route discovery"]
B --> C["Policy and method validation"]
C --> D["Runtime handler execution"]
D --> E["HTTP response + OpenAPI parity"]
Objective¶
Clear scope, expected outcome, and who should use this page.
Prerequisites¶
- FastFN CLI available
- Runtime dependencies by mode verified (Docker for
fastfn dev, OpenResty+runtimes forfastfn dev --native)
Validation Checklist¶
- Command examples execute with expected status codes
- Routes appear in OpenAPI where applicable
- References at the end are reachable
Troubleshooting¶
- If runtime is down, verify host dependencies and health endpoint
- If routes are missing, re-run discovery and check folder layout
See also¶
Last reviewed:
March 28, 2026
·
Docs on fastfn.dev