Docker serverless: functions without a Dockerfile, apps with one
Each function runs in its own Docker container built from package.json, requirements.txt, or go.mod—no Dockerfile to maintain for a small handler. When you do have a Dockerfile or an image, deploy it as a container app with releases, rollback, volumes and a private network. HTTP endpoints, webhooks, and pipelines with scheduled and background runs live in the same workspace.
Last updated: 2026-06-28
- Per-function Docker isolation with managed base images for Node.js 22, Python 3.12, Go 1.22
- Functions need no Dockerfile; container apps build from yours or run your image
- Native modules and CGO declared in inquir.yaml—not edge isolate restrictions
- Shared functions for HTTP, webhooks, and pipelines with scheduled or async runs
Answer first
Direct answer
Docker serverless: functions without a Dockerfile, apps with one. Inquir builds per-function containers from managed runtime images. You ship handler code and dependency manifests; the platform produces the container, schedules it on demand, and connects gateway routes or pipeline steps. Recurring work uses a schedule on the pipeline.
When it fits
- You want Docker-grade isolation and native dependencies without maintaining Dockerfiles and image pipelines per endpoint.
- HTTP APIs, webhooks, and scheduled or background pipelines should share one function catalog without separate Docker services.
Tradeoffs
- A Dockerfile per micro-endpoint does not scale operationally: image CVE scans, base image updates, and replica tuning become weekly chores.
- Edge isolates avoid Docker ops but ban native modules, subprocesses, and most private-network patterns—forcing a second platform for anything heavier than routing.
Workload and what breaks
Why “Docker + serverless” usually means operator work
Teams that want Docker isolation for a small handler often end up on a container service—ECS Fargate, Cloud Run, Fly Machines or Railway—where even one HTTP handler needs a Dockerfile or buildpack config, image pushes, health checks, and ingress wiring before it sees traffic.
Cron jobs, webhooks, and background workers frequently become separate Docker services with their own deploy pipelines, secrets, and monitoring—even when the business logic is a single HTTP handler.
Trade-offs
What DIY Docker serverless misses
A Dockerfile per micro-endpoint does not scale operationally: image CVE scans, base image updates, and replica tuning become weekly chores.
Edge isolates avoid Docker ops but ban native modules, subprocesses, and most private-network patterns—forcing a second platform for anything heavier than routing.
How Inquir helps
Two Docker paths in one workspace
Inquir builds per-function containers from managed runtime images. You ship handler code and dependency manifests; the platform produces the container, schedules it on demand, and connects gateway routes or pipeline steps. Recurring work uses a schedule on the pipeline.
Warm containers optionally keep Docker slots ready for steady traffic. The same container boundary serves gateway HTTP invokes, scheduled jobs, and async handoff—without you maintaining a container fleet or cluster control plane.
When a service needs its own Dockerfile—a web app, a worker with system packages, a database—deploy it as a container app: inquir apps deploy builds the Dockerfile on the platform or releases your image, with digest-pinned releases, a health check, rollback, volumes and a private .apps.internal address.
What you get
What managed Docker on Inquir includes
Managed images for functions
Node.js 22, Python 3.12, and Go 1.22 base images are maintained by the platform. Add dependencies to package.json, requirements.txt, or go.mod—no FROM/WORKDIR/RUN blocks for standard functions.
Native dependencies from inquir.yaml
sharp, bcrypt, numpy, pandas, and CGO packages are declared in inquir.yaml and installed at deploy—full Linux userspace without a custom image build pipeline.
Gateway + jobs in one catalog
HTTP routes, webhook ingress, and pipeline steps target the same function IDs. Pipelines own their schedules; every invocation shares one secrets model and execution history.
Optional warm pools
Enable warm containers when Docker cold starts matter on busy routes. Tune pool depth and idle timeouts against measured p95/p99—not assumptions.
Your Dockerfile as a container app
Services with their own Dockerfile or image run as container apps: releases behind a health check, rollback, volumes, Postgres and Redis templates and a private network, next to your functions.
What to do next
How to ship Docker serverless functions on Inquir
Author handler + manifest
Write a handler for Node.js, Python, or Go and declare dependencies in the standard manifest for that runtime—no Dockerfile needed on the standard path.
Deploy through the platform
Publish from the browser IDE or CLI. Inquir builds the per-function container image from the managed base and your dependency closure.
Connect routes and pipeline steps
Attach HTTP paths on the gateway, cron expressions on pipelines, or async handoff from webhooks—the same Docker-backed function handles each entry point.
Code example
For a function: a dependency manifest instead of a Dockerfile
For most functions you declare dependencies in the language manifest. The platform assembles the container; you focus on handler logic and gateway routing. A service with its own Dockerfile deploys as a container app instead.
{ "name": "resize-api", "type": "module", "dependencies": { "sharp": "^0.33.0" } }
import sharp from 'sharp'; export async function handler(event) { const input = Buffer.from(event.body ?? '', 'base64'); const out = await sharp(input).resize(320).jpeg().toBuffer(); return { statusCode: 200, headers: { 'Content-Type': 'image/jpeg' }, body: out.toString('base64'), isBase64Encoded: true, }; }
When it fits
Choose Docker serverless on Inquir when…
When this works
- You want Docker-grade isolation and native dependencies without maintaining Dockerfiles and image pipelines per endpoint.
- HTTP APIs, webhooks, and scheduled or background pipelines should share one function catalog without separate Docker services.
When to skip it
- A function needs arbitrary OS packages or a custom base image—deploy that code as a container app from your own Dockerfile instead.
- Sub-millisecond global edge latency on tiny pure-JS handlers—V8 isolates at the edge are a better fit for that profile.
FAQ
FAQ
Do I write a Dockerfile for each function?
No for standard Node.js, Python, and Go handlers. Declare dependencies in package.json, requirements.txt, or go.mod; the platform builds from managed base images. When you need a custom image, deploy it as a container app: inquir apps deploy builds your Dockerfile on the platform or releases an existing image.
How is this different from ECS Fargate or Cloud Run?
Those services run containers you package and wire to load balancers and schedulers yourself. Inquir couples container builds, gateway routing, webhooks, and pipelines with schedules and run history in one serverless-oriented control plane.
Is every function in its own Docker container?
Yes—each function gets an isolated container with its own dependency closure. That limits blast radius and avoids shared-interpreter conflicts across unrelated handlers.
Can I reduce Docker cold starts?
Enable warm containers to keep a pool of warm Docker slots for selected functions. Measure tail latency with realistic payloads before relying on warmth alone.