Inquir Compute

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.

Deploy a function →Function deployment docs

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—exactly the shape of “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 without a local Docker dance for every change.

API gateway for backend functions

Centralize auth and path rules for inbound HTTP.

Jobs and pipelines for async work

Represent async work explicitly 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 and worker shapes.

Configure

Wire gateway routes or pipeline triggers; bind secrets to functions in the product, not in git.

Observe

Use execution history as the feedback loop for reliability work.

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.

handlers/echo.mjs

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

Is Kubernetes used under the hood?

You interact with Inquir’s UI and API; workers use Docker (and Firecracker microVMs on Linux when enabled). 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.