Docker serverless functions without writing Dockerfiles
Each function runs in its own Docker container—but you declare package.json, requirements.txt, or go.mod instead of maintaining Dockerfiles, image registries, and orchestration YAML. Get HTTP endpoints, cron schedules, webhook ingress, and background jobs from the same serverless control plane.
Last updated: 2026-06-23
- Per-function Docker isolation with managed base images for Node.js 22, Python 3.12, Go 1.22
- No Dockerfile, fly.toml, or Kubernetes manifests for typical handlers
- Native modules and CGO via layers—not edge isolate restrictions
- One gateway for HTTP, cron, webhooks, and async pipeline steps
Answer first
Direct answer
Docker serverless functions without writing Dockerfiles. 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 attaches gateway routes, cron triggers, or pipeline steps.
When it fits
- You want Docker-grade isolation and native dependencies without maintaining Dockerfiles and image pipelines per endpoint.
- HTTP APIs, cron jobs, webhooks, and background steps should share one function catalog—not 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 often end up on ECS Fargate, Cloud Run, Fly Machines, or Railway services—each path needs Dockerfiles or buildpack config, image pushes, health checks, and ingress wiring before the first handler 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
Docker isolation with a serverless deploy model
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 attaches gateway routes, cron triggers, or pipeline steps.
Hot containers optionally keep warm Docker slots 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.
What you get
What managed Docker serverless includes
Managed images, not hand-written Dockerfiles
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.
Layers for native dependencies
sharp, bcrypt, numpy, pandas, and CGO packages attach as layers mounted into the container at runtime—full Linux userspace without a custom image build pipeline.
Gateway + jobs in one catalog
HTTP routes, webhook ingress, cron schedules, and background pipeline steps target the same function IDs. One secrets model and one execution history across invocation types.
Optional warm pools
Enable hot containers when Docker cold starts matter on busy routes. Tune pool depth and idle timeouts against measured p95/p99—not assumptions.
What to do next
How to ship Docker serverless functions on Inquir
Author handler + manifest
Write a handler for Node.js, Python, or Go. Declare dependencies in the standard manifest for that runtime—no Dockerfile unless you are comparing DIY Docker elsewhere.
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.
Wire routes, schedules, or pipelines
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
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.
{ "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, cron jobs, webhooks, and background steps should share one function catalog—not separate Docker services.
When to skip it
- You need arbitrary OS packages or a fully custom base image on every deploy—managed runtimes optimize the common case, not bespoke distro builds.
- 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. Custom Dockerfiles are not the default deploy path on Inquir.
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, cron, webhooks, and job 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 hot containers to keep a pool of warm Docker slots for selected functions. Measure tail latency with realistic payloads before relying on warmth alone.