Serverless containers for functions and full container apps
Every Inquir function runs in an isolated Docker container—not a V8 edge isolate—so native modules and real Node.js 22, Python 3.12 and Go 1.22 environments just work. When a process has to stay up, deploy it as a container app from any Dockerfile or image, with releases, rollback, volumes, Postgres and Redis templates and a private network. No cluster to manage either way.
Last updated: 2026-06-28
- Per-function container isolation — dependencies never clash across functions
- Native modules from inquir.yaml: sharp, bcrypt, numpy, pandas, cgo — no isolate limits
- Node.js 22, Python 3.12, Go 1.22 behind one gateway and pipeline
- Container apps for services that stay up: any Dockerfile or image, releases, rollback, private network
Answer first
Direct answer
Serverless containers for functions and full container apps. Each function runs in its own isolated container. Native modules declared in inquir.yaml work because the runtime is a real container environment, not an isolate shim. Heavy Python libraries, native Node.js addons, and Go CGO packages all run as expected.
When it fits
- Your function needs native modules, subprocesses, or outbound database/API calls that edge isolates forbid.
- You want Node.js, Python, and Go in one gateway without splitting vendors per language.
- You need a long-running service next to your functions—deploy it as a container app from a Dockerfile or an image.
Tradeoffs
- Provisioning a VM or a Kubernetes Deployment for each function means owning OS updates, scaling policies, ingress certificates, and rolling deploys before writing any business logic.
- Managed container services like ECS or Cloud Run help, but each still requires wiring load balancers, health checks, and task definitions—more ceremony than most backends need.
Workload and what breaks
Why edge isolates are not enough for heavier workloads
V8 isolates are fast and globally distributed—ideal for tiny logic at the edge. But they ban native addons, restrict filesystem access, cap memory, and block access to private networks. Sharp for image resizing, bcrypt for password hashing, numpy for data processing, and any C-extension Python library need a real runtime environment.
Functions backed by real containers fill the gap: you still deploy code and get HTTP endpoints without managing a cluster, but the execution environment is a full OS-level runtime instead of a sandboxed JavaScript engine.
Trade-offs
Why VMs and Kubernetes are too heavy for most teams
Provisioning a VM or a Kubernetes Deployment for each function means owning OS updates, scaling policies, ingress certificates, and rolling deploys before writing any business logic.
Managed container services like ECS or Cloud Run help, but each still requires wiring load balancers, health checks, and task definitions—more ceremony than most backends need.
How Inquir helps
Container isolation without cluster operations
Each function runs in its own isolated container. Native modules declared in inquir.yaml work because the runtime is a real container environment, not an isolate shim. Heavy Python libraries, native Node.js addons, and Go CGO packages all run as expected.
The same container boundary serves gateway HTTP invocations, pipeline steps—including scheduled runs—and async jobs.
Services that must stay up—web apps, APIs with WebSockets, databases—run as container apps: build your Dockerfile on the platform or release an existing image, pin releases by digest behind a health check, roll back, mount volumes and reach other apps over a private network. See the container apps docs for details.
What you get
What container-backed functions unlock
Native modules from inquir.yaml
Declare sharp, bcrypt, canvas, grpc, numpy, pandas, or any C-extension library in inquir.yaml build.dependencies. Runs correctly because the runtime is a real container—not a V8 isolate.
Full standard library access
Node.js fs, child_process, crypto; Python subprocess, os, ctypes; Go os/exec and CGO—the full language runtime, not an edge-isolate subset. Functions stay sandboxed: network is off by default and system packages are not installable.
Warm containers for steady traffic
Enable warm containers to keep a pool of pre-warmed instances ready. Useful for functions with consistent traffic that need low p95 latency.
Polyglot in one gateway
Mix Node.js, Python, and Go functions behind one API gateway, one secrets model, and one execution history—no separate infrastructure per language.
Container apps for long-running services
Any Dockerfile or image runs as an app with digest-pinned releases, a health-gated switch, rollback, volumes, Postgres and Redis templates and a private .apps.internal address—in the same workspace as your functions.
What to do next
How container-backed functions work on Inquir
Choose a runtime
Node.js 22, Python 3.12, or Go 1.22. Declare dependencies in package.json, requirements.txt, or go.mod—a function needs no Dockerfile.
Declare native dependencies in inquir.yaml
List language packages in build.dependencies and OS libraries in build.system. The deploy installs them into the function image.
Connect gateway routes and pipeline steps
Attach the function to an HTTP route or a pipeline step. Add a schedule to the pipeline for recurring work—the same container handles each invocation.
Code example
Native module example: sharp image processing
Sharp uses native C++ bindings—runs fine in Inquir containers, fails in most edge isolates. The function receives image bytes via HTTP body or pipeline payload.
import sharp from 'sharp'; export async function handler(event) { // Body is base64 for binary payloads routed through the gateway const input = Buffer.from(event.body ?? '', 'base64'); const thumbnail = await sharp(input) .resize(320, 240) .jpeg({ quality: 82 }) .toBuffer(); return { statusCode: 200, headers: { 'Content-Type': 'image/jpeg' }, body: thumbnail.toString('base64'), isBase64Encoded: true, }; }
When it fits
Use serverless containers when…
When this works
- Your function needs native modules, subprocesses, or outbound database/API calls that edge isolates forbid.
- You want Node.js, Python, and Go in one gateway without splitting vendors per language.
- You need a long-running service next to your functions—deploy it as a container app from a Dockerfile or an image.
When to skip it
- Your function is tiny, pure JavaScript, and must run at hundreds of edge POPs for global latency—V8 isolates are better for that.
FAQ
FAQ
Do I need to write a Dockerfile?
Not for a function: declare dependencies in package.json, requirements.txt, or go.mod and the platform builds the container from a managed base image for the chosen runtime; native modules and OS packages go into inquir.yaml. For a container app you bring a Dockerfile or an image, and the platform builds and releases it.
How do containers compare to Cloudflare Workers?
Workers run in V8 isolates optimized for edge latency; Inquir containers run full Node/Python/Go images optimized for native modules, heavier dependencies, and typical server-side outbound calls. Use Workers at the edge for caching and fan-out; use Inquir containers for origin logic.
Is cold start slower than edge isolates?
Container cold starts are slower than V8 isolate cold starts. Use warm containers (warm pools) to pre-warm functions that need steady low latency. Measure p95/p99 with realistic traffic before committing to a cold-only model.
Can I use Python ML libraries like numpy and pandas?
Yes. Python 3.12 containers support the full PyPI ecosystem including numpy, pandas, scikit-learn, and other libraries with C extensions—pip install them like any other dependency.