Serverless without
the shared blast radius.
Deploy Python or Node.js code and every invocation boots its own Firecracker microVM — no warm shared workers, no state carried between runs, no container quietly leaking one customer's secrets to the next. Hardware isolation, function-shaped.
One microVM per invocation. Then it's gone.
An invoke boots a fresh Firecracker microVM, extracts your bundle into /fn/, runs the entrypoint, and destroys the machine. Nothing carries over between runs — noisy neighbours are impossible by construction, not by policy.
Nothing survives between runs
There is no warm worker to poison: no /tmp residue, no module-scope cache another tenant filled, no environment left over from the last caller. Each run gets VM-level isolation with its own kernel — kill -9 can't escape the sandbox.
# deploy an entire directory (recommended)
pandastack fn deploy ./my-project/ \
--name data-processor \
--runtime python \
--entrypoint handler.py
# invoke it
pandastack fn invoke <function-id>
# golden metrics + run history
pandastack fn metrics <function-id>
pandastack fn runs <function-id>Ship the directory, dependencies and all.
fn deploy tars your whole project — entrypoint, helper modules, data files, requirements — and stores it privately in GCS. No flattening your codebase into one file to fit someone else's upload form.
Directory bundles
Everything lands in /fn/ inside the microVM, so from utils import … just works. node_modules, .git, and friends are excluded automatically.
Python & Node.js
python runs handler.py, nodejs runs handler.js. requirements.txt and package.json install automatically inside the VM — failures are non-fatal.
Custom templates
Bake numpy, pandas, or a model into a template once with pandastack template build, then deploy heavy functions onto it with --template.
Versions & env
Every deploy increments version and keeps the old bundle, so any run traces back to exact code. fn update --env changes config with no redeploy.
The difference is structural.
Single-zip platforms reuse warm containers to hide cold starts — which is exactly how state, secrets, and noisy neighbours leak between runs. A fresh microVM per invocation removes the whole failure class.
| PandaStack function | zip-file serverless | |
|---|---|---|
| Per-invocation runtime | a fresh microVM, destroyed after the run | warm shared workers |
| Code you can ship | full directory bundles with dependencies | single-file uploads |
| State between runs | none — by construction | leaks through warm containers |
| Metrics | p50/p95/p99, error rate, cold-start rate — automatic | wire up your own |
| Code storage | private in GCS, every version kept | platform-managed, opaque |
Call it from anywhere, watch it from one place.
Trigger runs from the CLI, the SDKs, or a public HTTPS endpoint — and every invocation is recorded to ClickHouse with golden metrics and a queryable run history.
Invoke on demand
pandastack fn invoke or an SDK call triggers a run; fn runs lists the full history for auditing what executed and when.
Public HTTPS endpoints
Deploy with --public and any HTTP request to your fn-*.pandastack.ai URL runs the function in a fresh microVM — webhooks, lightweight APIs, demos.
Golden metrics, automatic
p50/p95/p99 latency, error rate, and cold-start rate per function — aggregated at /v1/functions/<id>/metrics with no instrumentation on your side.
Cron when you need it
Pre-register a function, attach a schedule with --cron, push the bundle later — it starts firing the moment code lands. See /features/schedules.
The internals are public.
Functions are sandboxes wearing a smaller interface — the whole substrate is open source, docs included.
Ship on the millisecond cloud.
Free tier with $5.40/mo usage credit. No card. Apache-2.0.