From npm install to production in one sitting
npm i -g @inquir/compute-cli && inquir login — that is the whole setup. From there, `inquir deploy` ships a serverless function and `inquir apps deploy` ships any Dockerfile as a long-lived container service, with build logs streaming into your terminal.
Last updated: 2026-06-23
Answer first
Direct answer
From npm install to production in one sitting. The CLI installs from npm and authenticates through your browser. `inquir deploy` packages the current directory as a serverless function and streams the build; `inquir apps deploy` builds your Dockerfile server-side (no local Docker required) or releases any public image, for HTTP services and raw TCP ports alike.
When it fits
- Shipping a function or container service without standing up CI first
- CI/CD pipelines that need scriptable deploys, promotes, and rollbacks
- Teams that want ECS-style release discipline without operating Kubernetes or ECS
Tradeoffs
- Click-to-deploy works until you need the second environment, the second teammate, or the second rollback at 2 a.m. Anything you cannot script, you cannot repeat.
- Going straight to Kubernetes solves repeatability by handing you a distributed system to operate. kubectl, manifests, ingress, image pull secrets — powerful, and far more machinery than one service needs.
- The middle ground is a CLI that owns the whole lifecycle: build, release, verify, promote, roll back — the same commands on a laptop and in CI.
Workload and what breaks
Shipping a small service should not require a platform team
The usual path to production runs through a dashboard, a YAML pipeline, a container registry you administer yourself, and a deployment system someone has to keep healthy. For a function or a single container, that overhead dwarfs the actual work.
CLIs that only wrap a REST API do not fix this: you still assemble build, push, release, health checking, and rollback out of separate parts — and the sharp edges show up during an incident, not during setup.
Trade-offs
Dashboards demo well; terminals ship
Click-to-deploy works until you need the second environment, the second teammate, or the second rollback at 2 a.m. Anything you cannot script, you cannot repeat.
Going straight to Kubernetes solves repeatability by handing you a distributed system to operate. kubectl, manifests, ingress, image pull secrets — powerful, and far more machinery than one service needs.
The middle ground is a CLI that owns the whole lifecycle: build, release, verify, promote, roll back — the same commands on a laptop and in CI.
How Inquir helps
One binary, the whole lifecycle — with ECS-style orchestration underneath
The CLI installs from npm and authenticates through your browser. `inquir deploy` packages the current directory as a serverless function and streams the build; `inquir apps deploy` builds your Dockerfile server-side (no local Docker required) or releases any public image, for HTTP services and raw TCP ports alike.
Underneath sits an ECS-like control plane without the ECS: every build is pushed to a private registry and released by immutable digest, new releases must pass health checks before traffic moves, and replicas are placed across the worker fleet with automatic recovery when a machine disappears. You get orchestration semantics — releases, promotes, rollbacks, self-healing — without running an orchestrator.
Day-2 lives in the same tool: `inquir logs` and `inquir apps logs` for output, `apps exec` for a shell in a running container, `rollback` to any retained release, and `inquir upgrade` keeps the CLI itself current.
What you get
What the CLI covers
Functions
init scaffolds a handler, run executes it locally, deploy streams the remote build, invoke/logs/rollback close the loop — Node.js, Python, and Go.
Container apps
apps deploy builds the Dockerfile in your directory or releases any image; HTTP routing, raw TCP ports, and persistent volumes are flags, not config files.
ECS-style releases
Digest-pinned images in a private registry, health-gated promotes, retained releases for instant rollback, replicas spread across workers with automatic recovery.
CI and automation
Personal access tokens instead of browser login, plain-text and JSON output, and exit codes that mean what they say — every command scripts cleanly.
AI-agent ready
inquir mcp exposes the platform as an MCP server, so coding agents can deploy and inspect services with the same permissions you have.
What to do next
Three commands between an empty directory and production
Install and log in
npm i -g @inquir/compute-cli, then inquir login opens the browser once and stores a workspace-scoped token.
Deploy
inquir deploy for a function, or inquir apps deploy for a container service — both stream the build and end with a live URL.
Operate
Watch logs, exec into containers, promote a preview release, or roll back — from the same terminal session.
Code example
The whole lifecycle, as typed
No YAML, no registry credentials, no kubeconfig — the CLI owns build, release, and rollback end to end.
# once per machine npm i -g @inquir/compute-cli && inquir login # serverless function: scaffold, test locally, ship inquir init hello --runtime nodejs inquir run hello --payload '{"name":"World"}' inquir deploy # streams the build, prints the URL # container service: any Dockerfile, or any image inquir apps deploy web # builds ./Dockerfile server-side inquir apps deploy cache --image redis:7-alpine --tcp redis:6379 inquir apps logs web --follow inquir apps rollback web # back to the previous digest-pinned release
When it fits
Where the CLI is the right interface
When this works
- Shipping a function or container service without standing up CI first
- CI/CD pipelines that need scriptable deploys, promotes, and rollbacks
- Teams that want ECS-style release discipline without operating Kubernetes or ECS
When to skip it
- Editing code in the browser and deploying from there — that is the web IDE flow, no CLI required
FAQ
FAQ
Do I need Docker installed locally?
No. `inquir apps deploy` uploads your build context and builds the Dockerfile on the platform, streaming the log back. Local Docker is only useful if you want to test the image yourself first.
Is this ECS? What actually runs my containers?
It is ECS-shaped, not ECS: builds are pushed to a private registry, releases are pinned to image digests, health checks gate every promote, and replicas are placed across a worker fleet that recovers automatically when a machine fails. You get those semantics without an AWS account or a cluster to manage.
How does authentication work in CI?
Interactive machines use `inquir login` (browser device flow). CI uses a personal access token via environment variable — same commands, no browser, scoped to a workspace you choose.
How do rollbacks work?
Previous releases stay retained with their exact image digest. `inquir rollback` (functions) or `inquir apps rollback` (containers) re-activates one — no rebuild, and the health gate still applies before traffic moves.