Command-line interface (CLI)

Command reference#

Each command has its own page with syntax, options, examples and behavior.

Install and check the version#

Install Node.js 22+ and npm first. A global installation exposes inquir on your PATH. The npm package name and the command name are different: install @inquir/compute-cli, then run inquir.

Use @latest for an up-to-date workstation. Pin @0.3.0 when you need the version documented here, especially in CI. npx can run it without a global installation.

node --version
npm --version
npm install -g @inquir/compute-cli@latest
inquir --version
inquir --help

npx --yes @inquir/compute-cli@0.3.0 --version
npx --yes @inquir/compute-cli@0.3.0 --help

Update, Windows and PATH#

Re-run the install command to update the global package, then verify the binary your shell actually finds. Installing a newer package does not replace a different copy earlier in PATH. Node version managers may maintain a separate set of global packages for each Node version.

On Windows, run the PowerShell checks below. npm prefix -g is the directory containing npm command shims; make sure the intended prefix is on your user PATH, then reopen the terminal. If PowerShell blocks the .ps1 shim, run inquir.cmd directly. Avoid changing execution policy just to run the CLI.

On macOS/Linux, inspect command -v inquir and type -a inquir. A Node version manager avoids permission problems with system-owned global directories. The startup update check is cached for up to 12 hours; automatic replacement applies only to an interactive global npm installation. CI, JSON output and npx do not self-replace.

npm install -g @inquir/compute-cli@latest
inquir --version
inquir upgrade --help

Get-Command inquir -All
where.exe inquir
npm prefix -g
npm list -g @inquir/compute-cli --depth=0
inquir.cmd --version

inquir config set autoUpdate false
inquir doctor --no-update
inquir config set autoUpdate true

Sign in and choose credentials#

inquir login opens a browser pairing flow. Approve the displayed device code with your Inquir account, then wait for the terminal to finish. The CLI stores a Personal Access Token (PAT) and the API URL in ~/.inquir/config.json; on Windows this is under your user profile. --browserless prints the URL and code without opening a browser.

A PAT represents your account and can target workspaces where you have the required permissions. A workspace API key stays scoped to its workspace; choosing another workspace does not broaden its access. For CI, inject INQUIR_TOKEN or INQUIR_API_KEY through your secret store instead of putting a credential in shell history. Use one credential type per job.

logout removes locally stored credentials for the selected CLI environment. Revoke the token in the dashboard when you also want to invalidate it on the server.

inquir login
inquir whoami
inquir workspaces

inquir login --browserless
inquir config path
inquir logout

Workspaces, local links and CLI environments#

A workspace owns functions, applications and access rules. Choose the default with inquir use <slug-or-id>. --workspace overrides it for one command. inquir use ... --local writes the workspace selector into the nearest inquir.config.json; it requires an initialized local source directory.

Workspace precedence is: --workspace, INQUIR_WORKSPACE, the selected named credential environment, the local config link, then the saved default. Inspect whoami before deploying when switching accounts or repositories.

--env staging selects a saved CLI credential profile; it does not set application variables or select a function deploy stage. Create a profile with login --env. For function deployment stages use --stage (alias --environment). For application variables use apps update --set.

inquir workspaces
inquir use acme-prod
inquir whoami
inquir list --remote --workspace acme-prod

inquir login --env staging --api-url https://staging.example.com
inquir whoami --env staging
inquir config show --env staging

Choose functions or container applications#

Use the function commands for request/event-driven code: local execution, packaged deployment, remote invocation and invocation history. Use apps for a long-lived Docker container: HTTP service, API, database or background worker. A function in web mode is still a function; it is not converted into an application project.

Application projects group only container applications. inquir init scaffolds local source/configuration files; it does not create a remote application project. These are separate concepts even though both may be called a project in a terminal.

Create and run an SDK function locally#

Start in an empty directory. init writes inquir.config.json, a sample hello function and package dependencies. It installs dependencies unless --skip-install is given. The commands below install explicitly so a failed install is easy to see. Local Node functions run on your machine; match the documented Node version.

codegen discovers assets and writes .inquir/generated/client.ts and the registry; regenerate them instead of editing generated files. list shows local assets; list --remote (-r) shows remote functions. debug uses the local inspector and prints the debugger URL.

Create payload.json with the JSON shown below. Payload files work across Bash, PowerShell and Windows Command Prompt without inline-JSON quoting differences. run and invoke also accept --payload or JSON on stdin; a payload file takes precedence over an inline payload.

mkdir inquir-demo
cd inquir-demo
inquir init --name inquir-demo --skip-install --yes
npm install
inquir codegen
inquir list

{
  "name": "World"
}

inquir run hello --payload-file ./payload.json
inquir debug hello --payload-file ./payload.json

Deploy and invoke functions#

From an SDK workspace, use --asset hello to deploy exactly the discovered asset. A positional hello is supported for compatibility only when it is not an existing directory. Explicit --asset avoids confusing a directory and an asset with the same name.

Without --asset, deploy packages a source directory, automatically detects Node.js, Python or Go, and chooses handler or web mode. This route does not require inquir init or the SDK. --handler index.handler, --start "node server.js" and --runtime override detection. Web-mode code must listen on the supplied PORT.

--dry-run inspects detection and packaging without deploying. It is not a guarantee that the server will accept the deployment. Normal deployment follows build logs and waits for completion; --no-logs suppresses streaming but still waits. Memory is in MB; the function timeout is in milliseconds.

inquir deploy --asset hello --workspace acme-prod
inquir invoke hello --payload-file ./payload.json
inquir list --remote

inquir deploy ./api --dry-run
inquir deploy ./api --name billing --runtime nodejs22 --handler index.handler
inquir deploy ./api --name billing --start "node server.js"

inquir deploy --asset hello --stage staging --memory 512 --timeout 30000 --set LOG_LEVEL=info
inquir deploy --asset hello --env-file ./.env.production --layer LAYER_ID

Function logs, deployment history and rollback#

logs hello lists recent invocations and shows the latest invocation logs. It is not a continuous container-log stream. deploys hello lists deployments; copy a real deploy ID into status. status --follow follows that deployment until it finishes.

Function rollback creates a deployment from a retained successful deployment. Without an ID it selects the previous successful, non-active deployment. Check the result before reissuing a command after a network timeout: losing the CLI connection does not establish that the operation was cancelled.

inquir logs hello --limit 20
inquir deploys hello --limit 20
inquir status DEPLOY_ID
inquir status DEPLOY_ID --follow
inquir sync status

inquir rollback hello
inquir rollback hello DEPLOY_ID --no-logs

Create applications and select their project#

New applications belong to a project. With no project selected, apps create automatically creates a project named after the application. To group an API, database and worker together, create or select one project first. You do not need to repeat --project on every command.

projects use stores a directory-specific selection, rooted at the nearest inquir.config.json when present. It is isolated by API, workspace and signed-in identity. apps create --project overrides it once. projects add attaches an existing application; apps deploy keeps its membership and does not accept --project.

Plain apps create web --port 3000 creates application configuration; deploy an image or Dockerfile next. Database templates are the exception: they create the configured database and its first release. Project commands do not move serverless functions into application projects.

inquir projects list
inquir projects create shop
inquir projects use shop
inquir apps create web --port 3000
inquir apps create worker
inquir projects current

inquir projects add shop existing-app
inquir apps create cache --template redis --project shop
inquir projects use --clear

Deploy a Dockerfile or container image#

The target application must exist. Without --image or --build, apps deploy web uploads the source directory, builds its Dockerfile on the platform and creates a release. Use --dir, --context, --dockerfile, --target and repeatable --build-arg to describe a different build layout. A local Docker daemon is not required for this remote build path.

By default, deploying creates a release for inspection. --promote asks the platform to route production traffic to it after health checks succeed; the CLI then waits for the production pointer as well as health. --no-wait returns when the release is queued. For source deployment, the build still completes before a release can be queued.

New applications are private by default. Use apps update --ingress public to request Public Networking. --port is the container HTTP port; your process must listen on the container interface, normally 0.0.0.0, not only localhost. Configure a health endpoint that actually exists. IDs such as BUILD_ID and RELEASE_ID below mean values returned by the preceding commands.

inquir apps create web --port 3000
inquir apps update web --ingress public
inquir apps deploy web --dir ./web --health-path /health --promote
inquir apps status web

inquir apps create static-web --port 80
inquir apps update static-web --ingress public
inquir apps deploy static-web --image nginx:alpine --port 80 --health-path / --promote

inquir apps build web --dir ./web --context . --dockerfile Dockerfile --build-arg NODE_ENV=production
inquir apps builds web
inquir apps deploy web --build BUILD_ID
inquir apps promote RELEASE_ID

Inspect, redeploy and roll back applications#

apps status shows application endpoints, production and recent releases. apps logs accepts an application, release ID or build ID and streams the corresponding logs; stop watching with Ctrl+C. Its default container tail is 200 lines; use --tail to change it.

apps redeploy creates a new release from the production build or image reference using the current application settings. It promotes automatically unless --no-promote is given. An image tag can point to new content when pulled again; use immutable digests when reproducibility matters. Volume-backed applications are recreated and have downtime during the swap.

apps rollback web returns production to the previous release when the platform can do so. It does not restore database contents. apps stop stops a non-production release; apps delete archives the application and stops its releases. apps exec web -- ... executes in the application’s production container, not an arbitrary preview release, and is a command execution API rather than an interactive terminal.

inquir apps status web
inquir apps logs web --tail 100
inquir apps logs BUILD_ID
inquir apps exec web -- ls -la /app
inquir apps redeploy web
inquir apps rollback web

inquir apps stop RELEASE_ID
inquir apps delete unused-app

Environment variables, resources and networking#

Save application variables with repeatable apps update --set KEY=VALUE (or set initial values on apps create). Apply the saved configuration with a new deploy or apps redeploy. Do not put application settings on apps deploy --set or apps deploy --ingress: those flags are not applied by that handler in CLI 0.3.0. --env always selects CLI credentials.

Application memory is a ceiling in MB; CPU is in vCPUs. Updates preserve unrelated saved runtime fields. --tcp name:port declares a private raw TCP port; append :public only when public TCP access is intended. The public host port is assigned by the platform. --egress full|none controls outbound access; --ingress private|public controls Public Networking.

Use the verified private endpoint reported by apps status; do not manufacture a hostname from a display name. Private names resolve inside the workspace network and are not intended to resolve on your laptop. A provisioning state means the platform has not yet confirmed readiness; it is not proof of successful DNS or connectivity.

inquir apps update web --set LOG_LEVEL=info --set NODE_ENV=production
inquir apps update web --memory 512 --cpu 0.5 --health-path /health
inquir apps update web --ingress public --egress full
inquir apps redeploy web
inquir apps status web

Databases, private connections and volume backups#

The postgres and redis templates configure a database image, persistent volume, credentials and the first release. Choose the application project first so the database and consumer appear together. apps connect db web writes DATABASE_URL or REDIS_URL into the consumer without printing the password; redeploy the consumer to apply it. --overwrite intentionally replaces an existing connection variable.

connection-url --private requires a ready private address; --public requires explicitly available public access. With neither flag the command prefers private connectivity and can fall back to public. The printed URL contains credentials: use connect when you do not need to inspect it.

For custom services, mount --volume data:/app/data; :ro makes the mount read-only. --volume-runner pins the volume and application to a runner. Data stays on that machine; selecting another runner does not transfer it. Backups require volume and server support. They are crash-consistent snapshots; restore overwrites the volume and stops the application while it runs.

inquir projects use shop
inquir apps create db --template postgres
inquir apps status db
inquir apps connect db web
inquir apps redeploy web

inquir apps connection-url db --private
inquir apps connect db web --overwrite

inquir apps backups db create
inquir apps backups db list
inquir apps backups db restore BACKUP_ID

Replicas, sleep/wake and custom domains#

always keeps an application running; --replicas 1..8 requests horizontal replicas where the platform supports them. http sleeps after an idle interval and wakes on HTTP traffic. manual requires an explicit wake. These are application scaling policies, not a promise that stateful volumes can be replicated across machines.

Idle timeout must be at least 5 minutes; activation timeout is 5 seconds to 5 minutes; stabilization is non-negative. pause is for http/manual applications. An HTTP request wakes http mode, while manual mode remains paused until wake.

To add a domain, bind it, publish the exact ownership and routing DNS records printed by the CLI, then verify. The command does not change records at your DNS provider. Remove a binding with --remove only when you intend to disconnect that hostname.

inquir apps scale web always --replicas 2
inquir apps scale web http --idle-timeout 15m --activation-timeout 60s --stabilization 60s
inquir apps pause web
inquir apps wake web

inquir apps domain web shop.example.com
inquir apps domain web shop.example.com --verify
inquir apps domain web

CI/CD, pinned versions and JSON output#

Install a pinned CLI version in CI and provide credentials through environment variables. Set CI=true and INQUIR_NO_AUTO_UPDATE=1 for reproducibility. Use a least-privilege workspace API key, or a PAT with the required workspace access. Browser login is not needed in a job that supplies a credential.

Function deploy --ci waits for completion and returns a non-zero code on failure. For containers use apps deploy --promote --json and keep the default wait: without waiting, a queued operation is not a completed deployment. JSON mode suppresses status chatter; container/build log streaming sends log lines to stderr and is not a JSON event feed.

The workflow below deploys an existing ./api function directory. Define INQUIR_API_KEY in GitHub Actions secrets first. It does not grant permissions to a repository automatically. The separate Inquir deploy action supports configured GitHub OIDC trust; raw CLI 0.3.0 has no login --oidc flow. See the CI/CD guide for keyless deployment.

name: Deploy function
on: workflow_dispatch
permissions:
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      CI: "true"
      INQUIR_API_URL: https://api.inquir.org
      INQUIR_API_KEY: ${{ secrets.INQUIR_API_KEY }}
      INQUIR_NO_AUTO_UPDATE: "1"
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
      - run: npm install -g @inquir/compute-cli@0.3.0
      - run: inquir deploy ./api --ci --json

inquir apps deploy web --dir ./web --promote --json
inquir apps status web --json

Global flags and configuration#

Global flags may appear around the command. Command-specific flags still belong to their handler; apps create --help, inquir help deploy and the command sections above explain the relevant scope. Use config show for the resolved configuration; credentials are masked. config path locates the credential file without printing it.

inquir config show
inquir config get apiUrl
inquir config get autoUpdate
inquir config path
inquir help deploy
inquir apps --help
inquir projects --help

Troubleshooting and coding-agent integration#

Start with doctor: it checks Node/CLI versions, configuration, credentials and API connectivity. For a missing asset use list, check functionsDir and run from the correct local root. For a missing remote resource use whoami and the remote inventory before creating a second copy.

For a failed container release, inspect its release/build ID, logs, listening port, health check, memory and saved environment variables. If a private address is provisioning, inspect application readiness and the database’s private connection URL; enabling public access is not a repair for private networking. After changing saved runtime settings, create a new release.

inquir mcp starts an MCP server over stdio using the same CLI credentials. Configure your MCP client to launch the inquir command with the mcp argument. On Windows, a client that cannot execute npm shims can launch node with the absolute path to the installed @inquir/compute-cli/dist/index.js, followed by mcp. Tools can deploy and execute commands, so choose the intended workspace and permissions first.

inquir --version
inquir doctor --json
inquir whoami
inquir list --remote
inquir apps list
inquir apps status web
inquir apps logs web --tail 100

inquir mcp