CI/CD with GitHub Actions

Deploy from GitHub Actions with the published CLI, @inquir/compute-cli. The workflow runs it with npx, authenticates with a token from the repository secrets, and runs the same commands you use locally; a failed build or deploy exits non-zero and fails the job.

Credentials. In the console open Settings → API Keys, create a token under Personal Access Tokens (Create token), and store it as the Actions secret INQUIR_TOKEN. Put the workspace slug in the repository variable INQUIR_WORKSPACE. The CLI reads both from the environment, never prompts in CI and masks the token in its output. A token acts with the permissions of the account that created it, so give CI a token of its own, choose its lifetime, and revoke it when it is no longer needed.

Deploy a function on push#

inquir deploy packages the directory, detects the runtime, streams the build log and waits for the result; --ci switches to plain output and a non-zero exit code on failure. Pin the CLI version so the workflow does not change under you: the CLI never updates itself under npx or in CI.

# .github/workflows/deploy.yml — deploy a function with the Inquir CLI on every push to main
name: Deploy to Inquir Compute

on:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      INQUIR_TOKEN: ${{ secrets.INQUIR_TOKEN }}         # Personal Access Token
      INQUIR_WORKSPACE: ${{ vars.INQUIR_WORKSPACE }}    # workspace slug
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      # Packages the directory, streams the build log, exits non-zero on failure
      - run: npx --yes @inquir/compute-cli@0.4.1 deploy ./functions/hello --ci

Deploy an application on push#

For a container application the job uploads the source, builds the Dockerfile on the platform and starts a release that has to pass its health check. With --promote the release takes production by itself once it is healthy; that needs the token of a workspace owner or admin, and workspace API keys cannot promote. Leave --promote out to stop at a release next to production and promote it after a review.

# .github/workflows/deploy-app.yml — build and release a container application
name: Deploy the web service

on:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      INQUIR_TOKEN: ${{ secrets.INQUIR_TOKEN }}         # owner/admin token if you use --promote
      INQUIR_WORKSPACE: ${{ vars.INQUIR_WORKSPACE }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      # Builds ./Dockerfile on the platform, waits for the health check and,
      # with --promote, lets the release take production once it is healthy
      - run: npx --yes @inquir/compute-cli@0.4.1 apps deploy web --dir . --promote

Previews for pull requests#

• Functions: --stage (alias --environment) deploys into a named stage instead of production, for example --stage preview-pr-N with N the pull request number, in a workflow that runs on pull_request. Non-production stages expire after a period without deploys (see Quotas and limits).
• Applications: deploy without --promote. The release runs next to production, and after a review it is promoted with inquir apps promote <releaseId> or Promote in the console.
• Every run prints its result; add --json to either command to read the release or deploy id in a later step.