Container runtime built around functions
One container per function—familiar FS and deps without hand-rolling a VM farm.
Situation
Shared runtimes leak complexity
When everything runs in one interpreter, dependency conflicts and accidental global state become production incidents.
Security reviews ask harder questions if unrelated tenants or features share memory.
Sharp edges
Why not raw VMs only
VMs per function are heavy for small teams; containers hit a middle density.
Pure PaaS without isolation guarantees pushes risk to application discipline alone.
How Inquir fits
What you get
Package each function with its dependencies and let the platform schedule containers per function.
The same container boundary serves gateway HTTP invokes, pipeline lambda steps, and async jobs.
Capabilities
Engineering benefits
Reproducibility
Build artifacts that match production more closely than ad hoc hosts.
Blast radius
Limit failures and leaks to a single function instance.
Polyglot
Mix Node, Python, and Go where each excels.
Steps
How to ship functions with Inquir’s container runtime
Same per-function containers for gateway invokes, pipeline steps, and async jobs.
Author
Declare entrypoints and dependencies per function.
Deploy
Ship bundles through the browser or API workflows.
Run
Let the scheduler place containers on available capacity.
Code example
Boundary reminder
Treat the container as the unit of dependency closure.
// Platform bundles deploy artifacts; you focus on handler + package manifests.Fit
When containers help
When to use
- Conflicting libraries across functions
- Security-sensitive isolation requirements
When not to use
- Extremely tiny scripts where overhead dominates
FAQ
FAQ
Can functions read and write local disk?
Treat filesystems inside containers as ephemeral unless your deployment explicitly documents durable volumes; persist user data to external stores.
How does container isolation help security reviews?
Separate processes and file systems per function reduce blast radius compared to one shared interpreter serving unrelated routes.
Does every function need its own container image?
Each function carries its own dependency closure; that trades a bit of overhead for reproducible deploys and fewer “works on the server” surprises.