Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.zavu.dev/llms.txt

Use this file to discover all available pages before exploring further.

​
Runtime versions

Each Zavu Function is built against a specific runtime layer — a sealed bundle containing @zavu/functions, our SDK, and a small set of curated libraries. Layer versions are immutable: once a function is deployed against zavu-functions-runtime:7, it keeps using that exact version forever, even if we publish newer ones. This means your function is stable. We can iterate the runtime without breaking what’s already live.

​
How pinning works

+-----------------------+        +---------------------------+
| You: zavu deploy      | -----> | Function pinned to v7     |
+-----------------------+        +---------------------------+
                                              ^
                                              |
                                          (forever)
+-----------------------+
| Zavu: publishes v8    |
+-----------------------+

# Your function is still on v7. Unaffected.

+--------------------------------+        +--------------------------+
| You: zavu deploy --update-runtime| ---->| Function now pinned to v8|
+--------------------------------+        +--------------------------+
  • First deploy: function is pinned to whatever the latest runtime layer was at deploy time.
  • Subsequent deploys (zavu deploy): keep the same pin. The runtime doesn’t change even if newer versions are available.
  • Opt-in upgrade (zavu deploy --update-runtime): bump to the latest.

​
Checking your pin

curl https://api.zavu.dev/v1/functions/$FN_ID \
  -H "Authorization: Bearer $KEY" \
  | jq '.function.runtimeLayerArn'

"arn:aws:lambda:us-east-1:885869031099:layer:zavu-functions-runtime:7"
The trailing :7 is the version number. Same ARN across deploys means same runtime.

​
Auditing per-deployment

Every deployment record stores which runtime ran: 
curl https://api.zavu.dev/v1/functions/deployments/$DEPLOYMENT_ID \
  -H "Authorization: Bearer $KEY" \
  | jq '.deployment | {version, runtimeLayerArn, deployedAt}'

{
  "version": 4,
  "runtimeLayerArn": "arn:...:zavu-functions-runtime:7",
  "deployedAt": "2026-04-12T14:23:00.000Z"
}
Useful for “which deploy was on which runtime when the bug happened?”.

​
Upgrading

zavu deploy --update-runtime
This deploys the current source code AGAINST the latest runtime version. If the latest is v8 and you were pinned to v7:
  • New Lambda layer ARN written to your function.
  • All subsequent zavu deploy (without the flag) keep you on v8.

​
When you should upgrade

Most of the time, never. Stay pinned. Upgrade only when:
ReasonAction
Security advisory for your current runtimeUpgrade immediately. We’ll email you.
New feature you want (defineFlow, new SDK methods, etc.)Upgrade when convenient.
Curated dep version bump that fixes a bug affecting youUpgrade.
Performance improvements in cold-start, bundle sizeUpgrade when convenient.
Nothing changed and the new version is just a refactorDon’t bother.

​
When you should NOT upgrade

  • Breaking change in the framework that touches a method you use. Read the changelog first. Upgrade after fixing your code.
  • Dependency bump in a curated lib (zod, hono, etc) — if your code depends on specific behavior, test first.

​
Support policy

StatusReceives security patchesAccepts new deploysFunctions keep running
active (latest)✅✅✅
deprecated✅ for 6 months✅✅
eol❌❌ (deploy fails)✅ existing only
When a version moves to deprecated or eol, we email project owners 60 days before the transition with the affected function list.
“EOL” never means “AWS deletes the layer”. We use skip_destroy in our infrastructure so deployed functions keep their runtime indefinitely. EOL only blocks new deploys — existing functions on EOL layers run forever.

​
Bulk upgrade

When a security patch lands, you can sweep all your functions: 
# List all (we'll add `--outdated` filter soon; for now use the API)
zavu senders list      # to find sender IDs
zavu agents executions # for activity insight

# Per function:
cd ./my-function
zavu deploy --update-runtime
For programmatic bulk migration: 
for fn_id in $(curl -s https://api.zavu.dev/v1/functions \
  -H "Authorization: Bearer $KEY" \
  | jq -r '.items[].id'); do
  curl -X POST "https://api.zavu.dev/v1/functions/$fn_id/deploy" \
    -H "Authorization: Bearer $KEY" \
    -d '{"updateRuntime":true}'
done

​
What’s actually in a runtime layer

The current layer (~3 MB) contains:
PackageVersion rangePurpose
@zavu/functionsplatform-bundleddefineFunction, defineAgent, defineTool, verifyWebhook
@zavudev/sdklatest stableCall Zavu APIs
zod^3.22Schema validation
hono^4HTTP-friendly utilities
dayjs^1Date manipulation
Lambda built-ins—fetch, crypto, Buffer, etc.
If you import one of these in your function source code, esbuild marks it as external and the runtime resolves it from the layer — no npm install needed, no bundle bloat. To use a package NOT in the layer, declare it in package.json and the build worker installs it during zavu deploy: 
{
  "dependencies": {
    "openai": "^4.20.0"
  }
}

​
Rolling back

We don’t have a --runtime <arn> flag yet for explicit version pinning. If an upgrade breaks you and the previous runtime is still active/deprecated (not yet EOL), the workaround is to deploy from a previous source commit without --update-runtime: 
git checkout <pre-upgrade-commit>
zavu deploy   # uses the pinned runtime, no flag → keeps current pin
If the pin is already on the broken version, the most reliable rollback is to delete and recreate the function with the previous runtime explicitly provisioned by Zavu support.
This is rare in practice — runtime upgrades are tested in our staging environment before public release. But if you hit it, contact support and we’ll help with the manual repin.