Deploy backend functions without Kubernetes
Run HTTP handlers, scheduled jobs, and background work with functions, routes, containers, secrets, and execution history — without making Kubernetes your daily control plane. Functions and routes instead of cluster YAML—same isolation, less ceremony.
Last updated: 2026-06-28
Answer first
Direct answer
Deploy backend functions without Kubernetes. Inquir keeps the deployment surface at functions and routes while still giving you containers, secrets, and history. You are not pretending serverless means “no isolation,” and you are not maintaining Kubernetes manifests for every new handler.
When it fits
- You want structure now without hiring a platform team first.
- Your workloads map naturally to stateless handlers with explicit IO.
Tradeoffs
- Someone has to own etcd backups, CNI quirks, and ingress certificates before the first customer feature ships.
- GitOps and Helm are powerful, but they are heavy reading when your immediate need was “run this function every night”.
Workload and what breaks
Why teams look for functions without Kubernetes
Kubernetes is the respectable answer for “real” infrastructure, yet a huge share of products mainly need HTTP entrypoints, something that fires on a schedule, and a place to drain background work. That is why teams look for a way to deploy functions without Kubernetes until complexity truly demands a cluster.
Jumping straight to a cluster before those basics work slows early teams; refusing any structure leaves you rewriting shell scripts into microservices six months later.
Trade-offs
Why Kubernetes-first is heavy for simple backends
Someone has to own etcd backups, CNI quirks, and ingress certificates before the first customer feature ships.
GitOps and Helm are powerful, but they are heavy reading when your immediate need was “run this function every night”.
How Inquir helps
A serverless middle ground
Inquir keeps the deployment surface at functions and routes while still giving you containers, secrets, and history. You are not pretending serverless means “no isolation,” and you are not maintaining Kubernetes manifests for every new handler.
If you later need a bigger orchestrator, the habits you built—small handlers, explicit triggers—translate more cleanly than a monolith split in a hurry.
What you get
What you keep without Kubernetes
Deploy functions from the browser
Edit, save, and ship handlers without running a local Docker build for every change.
API gateway for backend functions
Centralize authentication and path rules for inbound HTTP at the gateway instead of re-implementing them in every service.
Jobs and pipelines for async work
Model async work explicitly as jobs and pipeline steps instead of hiding it in process forks.
What to do next
How to deploy functions without Kubernetes
Deploy without Kubernetes as your daily control plane when gateway routes, functions, and pipeline triggers are enough.
Author
Start from templates for common HTTP handler and background worker shapes, then adapt the code to your logic.
Configure
Wire gateway routes or pipeline triggers, and bind secrets to functions in the product rather than in git.
Observe
Use execution history as the feedback loop for reliability work—every invocation is recorded with logs and timing.
Code example
Focus stays on the handler
The unit of deployment is code plus metadata—not a Helm chart or Kubernetes manifest per endpoint. Default routes use the simple event shape (path); AWS-style routes use rawPath instead.
export async function handler(event) { const path = event.path ?? event.rawPath ?? ''; return { statusCode: 200, body: JSON.stringify({ path }), }; }
When it fits
Reasonable expectations
When this works
- You want structure now without hiring a platform team first.
- Your workloads map naturally to stateless handlers with explicit IO.
When to skip it
- You already invested in cluster-wide policy engines and CRDs as your primary interface.
FAQ
FAQ
Is Kubernetes used under the hood?
You interact with Inquir’s UI and API; workers run your code in isolated Docker containers. You are not asked to manage Kubernetes manifests or Helm charts to publish a function.
Can I still export to containers?
Yes. Think of containers as the isolation unit while your workflow stays function-centric.
How do I test locally?
Follow docs for local invocation patterns; keep parity with environment variables used in production.