Deploy backend services and functions without Kubernetes
Run long-lived services as container apps from a Dockerfile or an image—Postgres and Redis from templates, a private network between services, volumes, releases and rollback—and put HTTP handlers, scheduled jobs and background work in functions and pipelines next to them. One workspace, without making Kubernetes your daily control plane.
Last updated: 2026-06-28
Answer first
Direct answer
Deploy backend services and functions without Kubernetes. Inquir runs both shapes of backend work in one workspace. Services that must stay up deploy as container apps: a Dockerfile or an image, digest-pinned releases behind your health check, rollback, volumes, Postgres or Redis from a template, and a private address for every app. Short work deploys as functions behind gateway routes and pipeline triggers. Neither asks you for Kubernetes manifests, and both share secrets, logs and history.
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 managed middle ground
Inquir runs both shapes of backend work in one workspace. Services that must stay up deploy as container apps: a Dockerfile or an image, digest-pinned releases behind your health check, rollback, volumes, Postgres or Redis from a template, and a private address for every app. Short work deploys as functions behind gateway routes and pipeline triggers. Neither asks you for Kubernetes manifests, and both share secrets, logs and history.
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.
Container apps without manifests
inquir apps deploy builds your Dockerfile on the platform or releases an existing image; health check, replicas, volumes and ports are release settings, not YAML.
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 run a full container service?
Yes. Deploy any Dockerfile or image as a container app with inquir apps deploy. It gets releases behind a health check, rollback, a private .apps.internal address and optional volumes, and it lives in the same workspace as your functions.
How do I test locally?
Follow docs for local invocation patterns; keep parity with environment variables used in production.