# Runzivo > Runzivo builds fast, secure CI runners for modern software teams. - Runzivo self-service supports GitHub Actions on Linux x64. Sign in to the customer portal with GitHub, then connect a GitHub organization you own and select a repository where you can update a workflow. Personal repositories are not supported. - Use a repository where you can safely test a workflow change. Keep your existing workflow trigger and steps unchanged for the first run. - Change only the runner label at first. Your existing actions and job steps remain in the workflow. - Use the eligible label shown in the portal. - The rzv-ubuntu-24.04-x64-2vcpu-8gb, rzv-ubuntu-24.04-x64-4vcpu-16gb, rzv-ubuntu-24.04-x64-6vcpu-24gb, rzv-ubuntu-24.04-x64-8vcpu-32gb, rzv-ubuntu-24.04-x64-16vcpu-64gb, rzv-ubuntu-24.04-x64-32vcpu-128gb labels are available for real jobs today. - Each workspace receives 3,000 free equivalent minutes per UTC month, shared across its public and private repositories. A 2 vCPU runner consumes one equivalent minute for each runner minute. Unused minutes do not roll over. - New jobs cannot start once the free allowance is used up and no prepaid credits remain. The free allowance resets at the start of each UTC month. - Team and Business are billed monthly or yearly. A yearly plan costs 15% less than twelve monthly payments. Prices and included unit-minutes are on the pricing page. - A plan's included unit-minutes replace the free allowance. They are granted each month, on a yearly plan too, and do not roll over. Usage draws on included unit-minutes first, then prepaid credit, then overage up to the plan's monthly overage cap. Overage is invoiced monthly. - A sandbox is a Firecracker microVM in your workspace. You create it, run commands in it, open a terminal, stop it and start it again, from the rzv CLI, the customer API or the portal. Files in /workspace survive a stop and a start. - A sandbox lasts eight hours from its first start, by the wall clock. Stopping does not pause that time, starting again does not reset it, and it cannot be extended. After eight hours the sandbox expires and its VM and files are deleted. - A running sandbox uses unit-minutes from your workspace allowance or prepaid credit, at the multiplier of its size, from 1x for 2 vCPU to 8x for 16 vCPU. A stopped sandbox is not billed, and a start that never reaches running charges nothing. - Each start reserves 15 minutes ahead and adds more while the sandbox runs. When a run ends, only the seconds it ran are charged. credits_used shows the charge so far, including the current run. - Without credit, create and start are refused with credit_exhausted. If credit runs out while a sandbox runs, the sandbox fails with credit_exhausted and stops. Its files stay, and you can start it again after adding credit. - After you sign in to the customer portal, you stay signed in for 14 days without activity, and for 30 days at most. After 30 days you sign in again, even if you have been active. - Your sign-in survives browser restarts. - Only your own activity, such as opening pages or taking actions, keeps the session alive. Background refreshes in an open tab do not. --- Source: https://runzivo.dev/docs/getting-started/ # Getting started Sign in with GitHub, connect an organization, and run an eligible GitHub Actions job. ## Before you begin Runzivo self-service supports GitHub Actions on Linux x64. Sign in to the customer portal with GitHub, then connect a GitHub organization you own and select a repository where you can update a workflow. Personal repositories are not supported. Use a repository where you can safely test a workflow change. Keep your existing workflow trigger and steps unchanged for the first run. [Open the customer portal](https://app.runzivo.dev/) [Read the GitHub App installation guide](https://runzivo.dev/docs/github-app/) ## First run - Sign in with GitHub, then connect a GitHub organization and select the repository you want to authorize. - Copy the eligible Runzivo Linux x64 label into the job's runs-on value. - Commit and push the workflow change. - Run the workflow, then view the result in GitHub Actions and the portal. If the job cannot start, use the troubleshooting guide before changing workflow logic. [Review GitHub App permissions](https://runzivo.dev/docs/github-app-permissions/) ## Find your way around the portal The sidebar groups the portal by area. CI & Runners holds Jobs, Runners, Runner Templates, Repositories, Insights and Pipelines. Pipelines and AI Fix appear only when they are turned on for your workspace. Services marked Soon are planned and not available yet; they don't open a page. Workspace settings live under Settings, in tabs: General, Members & Teams, Billing & Credits, API Keys, Integrations, Notifications and AI (AI Settings in the sidebar). Your own profile, appearance, language and timezone are in the account menu at the top right. Collapse the sidebar with the button at its bottom left. When it's collapsed, hover or focus an icon to see its name, and select a section to open its menu. Press ⌘K (Command+K) on a Mac, or Ctrl+K elsewhere, to open Quick search from any page. ## Minimal workflow change Change only the runner label at first. Your existing actions and job steps remain in the workflow. Use the eligible label shown in the portal. The rzv-ubuntu-24.04-x64-2vcpu-8gb, rzv-ubuntu-24.04-x64-4vcpu-16gb, rzv-ubuntu-24.04-x64-6vcpu-24gb, rzv-ubuntu-24.04-x64-8vcpu-32gb, rzv-ubuntu-24.04-x64-16vcpu-64gb, rzv-ubuntu-24.04-x64-32vcpu-128gb labels are available for real jobs today. GitHub Actions · existing workflow job ```yaml jobs: test: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb steps: - uses: actions/checkout@v7 - run: npm test ``` On this page and page tools --- Source: https://runzivo.dev/docs/cli/ # Install the rzv CLI Install the rzv command-line tool, sign in, and choose a workspace. ## 1. Install on macOS or Linux The installer ships rzv 0.21.0 (release-2026-10-31-193326). It downloads the executable for your machine, verifies its SHA-256 checksum and installs it in ~/.local/bin. No separate Node.js installation or runtime is needed. Run this in a macOS or Linux terminal. If rzv is already installed, the same command updates it. Terminal · macOS and Linux ``` curl -fsSL https://runzivo.dev/downloads/rzv/install.sh | sh rzv version ``` Installing on Windows? Start here [See rzv releases, checksums and release notes](https://github.com/Runzivo/rzv-cli/releases) ## 2. Sign in Sign in with the GitHub identity you use for the customer portal. The CLI opens your browser at id.runzivo.dev, then stores a short-lived access token locally. It never prints a password or token to the terminal. Run whoami after sign-in to check your identity, profile and selected workspace. After upgrading from a version earlier than 0.19.0, sign in again to use the current identity provider. Terminal · sign in and check your identity ``` rzv login rzv whoami ``` ## 3. Select a workspace List the workspaces you belong to, then replace \ with an ID or slug from that list. Selection is saved for later workspace-scoped commands. Check whoami again to confirm the selection. Pass --workspace \, or -w, to use a different workspace for one command. RZV_WORKSPACE sets the default workspace for a shell. The older --account \ option is also accepted. Terminal · replace \ before running ``` rzv workspaces list rzv workspaces select rzv whoami ``` [Workspace command reference](https://runzivo.dev/docs/cli-commands/#workspaces-and-access) ## 4. Run your first read-only command List jobs in the selected workspace. Add --json when a script needs machine-readable output. This lists existing jobs; it does not start a workflow. Terminal · list jobs and inspect command help ``` rzv jobs list rzv jobs list --json rzv help jobs ``` [Read the rzv command reference](https://runzivo.dev/docs/cli-commands/) [Create your first sandbox](https://runzivo.dev/docs/sandboxes-quickstart/) ## Windows installation On Windows x86-64, download rzv-win32-x64.exe and SHA256SUMS from the same release. Open PowerShell in the download directory and calculate the executable's SHA-256 hash. Compare it with the matching entry in SHA256SUMS before running the file. After verification, rename the executable to rzv.exe and put it in a directory on PATH. Return to step 2 to sign in, then select a workspace. The shell installer above is for macOS and Linux, not Windows. PowerShell · verify the Windows download ``` Get-FileHash .\rzv-win32-x64.exe -Algorithm SHA256 ``` [Download the Windows executable and checksums](https://github.com/Runzivo/rzv-cli/releases) ## If rzv is not found The installer reports its install directory. If your shell cannot find rzv, add that directory to PATH. This example uses the default ~/.local/bin and applies to the current macOS or Linux shell. Add the same line to your shell's startup file to keep it for new terminals. Set RZV_INSTALL_DIR when running the installer to use a different directory. Terminal · macOS and Linux ``` export PATH="$HOME/.local/bin:$PATH" rzv version ``` ## Install a specific release Use the release tag when you need a fixed CLI version. This installs the version documented on this page. Terminal · macOS and Linux ``` curl -fsSL https://runzivo.dev/downloads/rzv/install.sh | sh -s -- --version=release-2026-10-31-193326 ``` ## Supported CLI platforms Builds are available for macOS on Apple Silicon and Intel, Linux on x86-64 and arm64, and Windows on x86-64. Each is a self-contained executable. Release files are rzv-darwin-arm64, rzv-darwin-x64, rzv-linux-arm64, rzv-linux-x64, and rzv-win32-x64.exe. CLI platforms do not change runner availability. Runzivo jobs run on Linux x64; macOS and Windows runners are not available instantly; they are provisioned on request (contact run@runzivo.dev). ## Use a separate sign-in profile Each profile keeps its own sign-in and selected workspace. This example creates a profile named work, lists profiles and makes work active. Use -p \ on any command for a one-off choice, or set RZV_PROFILE for a shell. Removing a profile removes its local sign-in. Terminal · optional profiles ``` rzv login -p work rzv profiles list rzv profiles use work rzv whoami -p work ``` ## Sign in without opening the browser automatically Use --no-browser to print the sign-in URL, then open it yourself. Run the CLI on the same machine as the browser, because the sign-in returns to a local callback listener. Terminal · manual browser opening ``` rzv login --no-browser ``` ## Sign out This removes the stored sign-in for the profile in use. Terminal · remove the current sign-in ``` rzv logout ``` ## Troubleshooting the CLI - “Credentials were rejected or expired”: sign in again with the command below. - “The requested workspace is not authorized for this account.”: list your workspaces and select one you can access. Contact support if you expect access. - “The customer API is unavailable”: wait and retry; contact support if it persists. - GitHub authorization denied or expired device code: GitHub's device flow was declined or timed out. Start authorization again. - GitHub installation authority denied: you must be an organization admin or owner. For an invalid or expired link state, start a fresh connection. Terminal · check sign-in, access and GitHub options ``` rzv login rzv workspaces list rzv help github ``` [See general troubleshooting and the support contact](https://runzivo.dev/docs/troubleshooting/) [GitHub connection commands](https://runzivo.dev/docs/cli-commands/#github) On this page and page tools --- Source: https://runzivo.dev/docs/ # Build on Runzivo. Run GitHub Actions on isolated runners, or give your coding agent a Linux sandbox. Start with a guide, then look up the details as you need them. ## Your first GitHub Actions job Connect a GitHub organization, choose your repositories and change the runner label. [Runner quickstart](https://runzivo.dev/docs/getting-started/) [Workflow templates](https://runzivo.dev/docs/runner-templates/) ## Your first sandbox Create an isolated Linux microVM, run commands and open an interactive terminal. [Sandbox quickstart](https://runzivo.dev/docs/sandboxes-quickstart/) [Sandbox API reference](https://runzivo.dev/docs/reference/) ## [Guides](https://runzivo.dev/docs/guides/) Step-by-step setup for CI runners, sandboxes and your workspace. ## [Platform](https://runzivo.dev/docs/platform/) Understand compute, limits, billing and workspace controls. ## [Reference](https://runzivo.dev/docs/reference/) Look up CLI commands and the Sandbox customer API. ## [Demos](https://runzivo.dev/docs/demos/) Illustrative sandbox walkthroughs and copyable runner workflows. ### CLI and AI tools - rzv CLI Sign in, manage your workspace and read jobs from your terminal. [Read guide](https://runzivo.dev/docs/cli/) - llms.txt An index of these docs for AI assistants and agents. [Open file](https://runzivo.dev/llms.txt) - llms-full.txt Every guide in one plain-text file for AI tools. [Open file](https://runzivo.dev/llms-full.txt) - Markdown pages Each guide is also published as Markdown: add .md to its URL. [Open file](https://runzivo.dev/docs.md) --- Source: https://runzivo.dev/docs/runner-templates/ # GitHub Actions runner templates Install the Runzivo GitHub App, select a private repository owned by a GitHub organization, then use the selected template's published runner label. ## Write a template ### Node.js Install locked npm dependencies, test, and build. rzv-ubuntu-24.04-x64-2vcpu-8gb Required files: package.json and package-lock.json. Commit package-lock.json before using the npm dependency cache. ```yaml name: Node.js on: push: branches: [main] pull_request: workflow_dispatch: permissions: contents: read concurrency: group: nodejs-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: test: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 15 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0 with: node-version: 24 cache: npm cache-dependency-path: package-lock.json - run: npm ci - run: npm test - run: npm run build ``` ### Python Install requirements and run pytest. rzv-ubuntu-24.04-x64-2vcpu-8gb Required files: requirements.txt and tests. ```yaml name: Python on: push: branches: [main] pull_request: workflow_dispatch: permissions: contents: read concurrency: group: python-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: test: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 15 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: actions/setup-python@e797f83bcb11b83ae66e0230d6156d7c80228e7c # v6.0.0 with: python-version: "3.13" cache: pip cache-dependency-path: requirements.txt - run: python -m pip install --requirement requirements.txt - run: python -m pytest ``` ### Go Vet, test, and build a Go module. rzv-ubuntu-24.04-x64-2vcpu-8gb Required files: go.mod and go.sum. ```yaml name: Go on: push: branches: [main] pull_request: workflow_dispatch: permissions: contents: read concurrency: group: go-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: test: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 15 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: actions/setup-go@44694675825211faa026b3c33043df3e48a5fa00 # v6.0.0 with: go-version-file: go.mod cache: true - run: go vet ./... - run: go test ./... - run: go build ./... ``` ### Java with Maven Build and test a Maven project with its committed Maven Wrapper. rzv-ubuntu-24.04-x64-2vcpu-8gb Required files: pom.xml, mvnw, and .mvn/wrapper/. Preserve the executable bit on mvnw. ```yaml name: Java with Maven on: push: branches: [main] pull_request: workflow_dispatch: permissions: contents: read concurrency: group: java-maven-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: test: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 20 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: actions/setup-java@dded0888837ed1f317902acf8a20df0ad188d165 # v5.0.0 with: distribution: temurin java-version: "21" cache: maven - run: ./mvnw --batch-mode verify ``` ### Docker build and GHCR publish Build pull requests and publish only from pushes to main. rzv-ubuntu-24.04-x64-2vcpu-8gb Required file: Dockerfile. ```yaml name: Docker build and GHCR publish on: push: branches: [main] pull_request: workflow_dispatch: permissions: contents: read concurrency: group: docker-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: build: if: github.event_name == 'pull_request' || github.event_name == 'workflow_dispatch' runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 25 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: docker/setup-buildx-action@e468171a9de216ec08956ac3ada2f0791b6bd435 # v3.11.1 - uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83 # v6.18.0 with: context: . push: false cache-from: type=gha cache-to: type=gha,mode=max publish: if: github.event_name == 'push' && github.ref == 'refs/heads/main' runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 25 permissions: contents: read packages: write steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: docker/setup-buildx-action@e468171a9de216ec08956ac3ada2f0791b6bd435 # v3.11.1 - id: metadata uses: docker/metadata-action@dc802804100637a589fabce1cb79ff13a1411302 # v6.2.0 with: images: ghcr.io/${{ github.repository }} - uses: docker/login-action@5e57cd118135c172c3672efd75eb46360885c0ef # v3.6.0 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83 # v6.18.0 with: context: . push: true tags: ${{ steps.metadata.outputs.tags }} cache-from: type=gha cache-to: type=gha,mode=max ``` ### Terraform Plan pull requests and apply main after you configure required environment reviewers. rzv-ubuntu-24.04-x64-2vcpu-8gb Required directory: terraform/. Configure a remote backend, provider credentials, and the terraform-apply environment with required reviewers before using apply. Commit .terraform.lock.hcl whenever the configuration uses providers. For a private repository, confirm the GitHub plan supports required environment reviewers before relying on the gate. Protect main so reviewed changes are required before a push can reach apply. An environment name alone is not an approval gate. The apply job plans again before applying, so it applies what main holds at that moment, not the pull request's earlier plan. Give the pull request plan job read-only cloud credentials; keep write credentials only on the terraform-apply environment. ```yaml name: Terraform on: push: branches: [main] pull_request: workflow_dispatch: permissions: contents: read concurrency: group: terraform-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: validate: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 15 defaults: run: working-directory: terraform env: TF_PLUGIN_CACHE_DIR: ${{ github.workspace }}/.terraform.d/plugin-cache steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: hashicorp/setup-terraform@b9cd54a3c349d3f38e8881555d616ced269862dd # v3.1.2 with: terraform_version: 1.16.7 terraform_wrapper: false - uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0 with: path: .terraform.d/plugin-cache key: terraform-${{ runner.os }}-${{ hashFiles('terraform/.terraform.lock.hcl', 'terraform/*.tf') }} - run: mkdir -p "$TF_PLUGIN_CACHE_DIR" - run: terraform fmt -check -recursive - run: terraform init -backend=false -input=false -lockfile=readonly - run: terraform validate plan: if: github.event_name == 'pull_request' needs: validate runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 15 defaults: run: working-directory: terraform env: TF_PLUGIN_CACHE_DIR: ${{ github.workspace }}/.terraform.d/plugin-cache steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: hashicorp/setup-terraform@b9cd54a3c349d3f38e8881555d616ced269862dd # v3.1.2 with: terraform_version: 1.16.7 terraform_wrapper: false - uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0 with: path: .terraform.d/plugin-cache key: terraform-${{ runner.os }}-${{ hashFiles('terraform/.terraform.lock.hcl', 'terraform/*.tf') }} - run: mkdir -p "$TF_PLUGIN_CACHE_DIR" - run: terraform init -input=false -lockfile=readonly - run: terraform plan -input=false -lock=false apply: if: github.event_name == 'push' && github.ref == 'refs/heads/main' needs: validate runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 20 environment: terraform-apply defaults: run: working-directory: terraform env: TF_PLUGIN_CACHE_DIR: ${{ github.workspace }}/.terraform.d/plugin-cache steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: hashicorp/setup-terraform@b9cd54a3c349d3f38e8881555d616ced269862dd # v3.1.2 with: terraform_version: 1.16.7 terraform_wrapper: false - uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0 with: path: .terraform.d/plugin-cache key: terraform-${{ runner.os }}-${{ hashFiles('terraform/.terraform.lock.hcl', 'terraform/*.tf') }} - run: mkdir -p "$TF_PLUGIN_CACHE_DIR" - run: terraform init -input=false -lockfile=readonly - run: terraform apply -auto-approve -input=false ``` ### Ansible Lint, syntax-check, and check-mode a local playbook. rzv-ubuntu-24.04-x64-2vcpu-8gb Required files: ansible/requirements-ci.txt, inventory.yml, and playbook.yml. ```yaml name: Ansible on: push: branches: [main] pull_request: workflow_dispatch: permissions: contents: read concurrency: group: ansible-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: validate: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 20 defaults: run: working-directory: ansible steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: actions/setup-python@e797f83bcb11b83ae66e0230d6156d7c80228e7c # v6.0.0 with: python-version: "3.13" cache: pip cache-dependency-path: ansible/requirements-ci.txt - run: python -m pip install --requirement requirements-ci.txt - run: ansible-lint playbook.yml - run: ansible-playbook --inventory inventory.yml --syntax-check playbook.yml - run: ansible-playbook --inventory inventory.yml --check playbook.yml ``` ### Rust Format-check, lint, test, and build a Cargo project. rzv-ubuntu-24.04-x64-2vcpu-8gb Required files: Cargo.toml and Cargo.lock. Commit Cargo.lock before using the Cargo cache. ```yaml name: Rust on: push: branches: [main] pull_request: workflow_dispatch: permissions: contents: read concurrency: group: rust-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: test: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 20 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: actions-rust-lang/setup-rust-toolchain@166cdcfd11aee3cb47222f9ddb555ce30ddb9659 # v1.17.0 with: toolchain: stable components: rustfmt, clippy - uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0 with: path: | ~/.cargo/bin/ ~/.cargo/registry/index/ ~/.cargo/registry/cache/ target/ key: rust-${{ runner.os }}-${{ hashFiles('Cargo.lock') }} - run: cargo fmt --check - run: cargo clippy --all-targets -- -D warnings - run: cargo test - run: cargo build --release ``` ### .NET Restore, build, and test a .NET solution. rzv-ubuntu-24.04-x64-2vcpu-8gb Required files: global.json and a solution. ```yaml name: .NET on: push: branches: [main] pull_request: workflow_dispatch: permissions: contents: read concurrency: group: dotnet-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: test: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 20 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: actions/setup-dotnet@d4c94342e560b34958eacfc5d055d21461ed1c5d # v5.0.0 env: DOTNET_INSTALL_DIR: ${{ runner.temp }}/dotnet with: global-json-file: global.json - uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0 with: path: ~/.nuget/packages key: dotnet-${{ runner.os }}-${{ hashFiles('**/*.csproj', 'global.json') }} - run: dotnet restore - run: dotnet build --no-restore --configuration Release - run: dotnet test --no-build --configuration Release ``` ### Reusable Go workflow Call a reusable Go validation workflow. rzv-ubuntu-24.04-x64-2vcpu-8gb Required files: go.mod and go.sum. Copy the selected file into .github/workflows/ before calling it from another workflow. ```yaml name: Reusable Go validation on: workflow_call: workflow_dispatch: permissions: contents: read concurrency: group: reusable-go-${{ github.workflow }}-${{ github.ref }} cancel-in-progress: false jobs: test: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 15 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: actions/setup-go@44694675825211faa026b3c33043df3e48a5fa00 # v6.0.0 with: go-version-file: go.mod cache: true - run: go vet ./... - run: go test ./... - run: go build ./... ``` On this page and page tools --- Source: https://runzivo.dev/docs/ai-coding-agent/ # Set up Runzivo with your AI coding agent Copy a prompt that gives an AI coding agent the Runzivo instructions for a small workflow change. ## Copy the prompt From the workspace home, select Onboard your agent to Runzivo. A generic prompt is also available here for an AI coding agent working in your repository. prompt.txt ``` Set up this repository to run GitHub Actions on Runzivo. First read https://app.runzivo.dev/agents.md and this repository's instructions. They take priority over the instructions below. Check that the Runzivo GitHub App is installed for this repository. You cannot install it. If it is missing, tell the user to use https://app.runzivo.dev/setup. Confirm the workspace's available labels in Setup before editing. Inspect .github/workflows and change only runs-on for eligible Linux x64 jobs. Keep everything else unchanged. Never read or write secrets. Skip ARM and GPU jobs. They are not available. Skip macOS and Windows jobs unless the workspace has provisioned capacity for them; they are not available instantly and are provisioned on request (contact run@runzivo.dev). Open a pull request for the change. Do not merge it unless the user asks. ``` ## What the agent changes The instructions tell the agent to confirm the labels available to your workspace in Setup before it edits a workflow. It changes eligible Linux x64 runs-on labels only, then proposes the change in a pull request for your review. The prompt tells the agent not to install the GitHub App or read or write secrets. It asks the agent to leave merging to you unless you request it. ## Read the public instructions [Open the agent instructions](https://app.runzivo.dev/agents) [Open the agent instructions as Markdown](https://app.runzivo.dev/agents.md) [Open the AI-readable Runzivo index](https://app.runzivo.dev/llms.txt) On this page and page tools --- Source: https://runzivo.dev/docs/github-app/ # Install the GitHub App Connect a GitHub organization and selected repository to Runzivo. ## Availability Start in the customer portal. After GitHub sign-in, connect your GitHub organization and select the repositories that can use Runzivo. Personal repositories are not supported. [Review GitHub App permissions](https://runzivo.dev/docs/github-app-permissions/) ## Connect GitHub from the portal Use the customer portal to connect GitHub. You must be an organization owner to complete the connection. The portal opens the Runzivo Shared GitHub App flow, where you select the organization and repositories, then returns you to your workspace. After installation, setup checks the current GitHub App permissions again instead of relying on a stale cached mismatch. [Open the portal to connect GitHub](https://app.runzivo.dev/) ## Repository selection During installation, an organization owner chooses Only select repositories and selects the repositories that will use Runzivo. A workflow label selects a supported runner configuration, but it does not grant repository access. [Review GitHub App permissions before installation](https://runzivo.dev/docs/github-app-permissions/) ## What the V1 integration is designed to do For a connected installation and selected repository, Runzivo: - Validates that a queued job comes from the connected installation and selected repository. - Creates a single-use JIT runner for an eligible repository. - Runner cleanup after a job completes, is cancelled, or cannot be assigned. ## Change repository access Use GitHub App installation settings to add or remove repositories. When you remove a repository in GitHub, it can no longer request new Runzivo capacity. Uninstalling or suspending the App stops new runner requests. When you restore access, update the selected repositories in GitHub before requesting new runners. On this page and page tools --- Source: https://runzivo.dev/docs/github-app-permissions/ # GitHub App permissions The permissions Runzivo requests, what they support, and the controls customers retain. 6 connected Current status Today Repository access Follows the repositories you select Runner execution Live for organization repositories Personal-account repositories Not supported · use an organization Organization scopes Manage self-hosted runners · Read members AI write features Early access, off by default ## Availability Updated 21 October 2026: Runzivo supports organization repositories only and does not request the Administration permission. This replaces the earlier statement that personal-repository support was planned. After GitHub sign-in, connect a GitHub organization you own, including a GitHub Free organization, and select the repositories you want to use. The currently eligible runner labels are rzv-ubuntu-24.04-x64-2vcpu-8gb, rzv-ubuntu-24.04-x64-4vcpu-16gb, rzv-ubuntu-24.04-x64-6vcpu-24gb, rzv-ubuntu-24.04-x64-8vcpu-32gb, rzv-ubuntu-24.04-x64-16vcpu-64gb, rzv-ubuntu-24.04-x64-32vcpu-128gb. Creating a workspace does not add repository access: select each repository during the Runzivo Shared GitHub App connection. Installation linking, JIT runner provisioning, and runner lifecycle transitions support the available GitHub Actions flow. Runzivo runs jobs for repositories owned by GitHub organizations. Repositories owned by a personal account are not supported: GitHub only lets an app register a runner on a personal repository if it holds Administration: Read and write, and Runzivo does not request that permission. To use Runzivo with a personal repository, create a free GitHub organization and move or fork the repository into it. The AI pipeline builder and CI fix agent are built and in early access. They are switched off and are not available for customer use until they are enabled for a workspace. This page describes the requested permission contract. A requested permission is not evidence that a live App registration has received it. [See the GitHub App setup guide](https://runzivo.dev/docs/github-app/) ## Requested repository permissions - Metadata: Read. Supports GitHub App configuration, signed intake, and selected-repository authorization. - Actions: Read and write. Supports queued-job admission, job lifecycle transitions, run history and job logs. - Contents: Read and write. The early-access pipeline builder and CI fix agent read repository files and write workflow changes to a new branch. - Workflows: Write. The early-access pipeline builder and CI fix agent change workflow files. - Pull requests: Read and write. The early-access pipeline builder and CI fix agent deliver their changes as pull requests. - Checks: Read and write. The early-access CI fix agent reads the failed checks it is asked to fix. - Issues: Read. Requested for planned assistant context; no available feature uses it. ## Requested organization permissions - Self-hosted runners: Read and write. Organization runner reservation, JIT registration, and removal use this access. Same-job binding remains unresolved. - Members: Read. Planned membership-change handling needs minimum organization, member, team, and membership-change identifiers. ## Installation scope During installation, customers choose Only select repositories. That choice limits repository permissions to the selected repositories, and customers can add or remove repositories later in GitHub App installation settings. Selected-repository access does not limit the separate organization permissions. Self-hosted runners and Members are organization-level scopes, requested for the purposes described above. Runzivo does not request Administration, Secrets, Variables, Environments, Packages, or Deployments permissions. Existing installations do not receive a new permission automatically. If Runzivo ever requests one, GitHub requires each installation owner to approve it before Runzivo can use it. ## Why these permissions are requested The requested permissions cover the available runner flow and the early-access pipeline builder and CI fix agent. Runzivo does not request Administration. GitHub grants that permission broad control over repository settings, branch protection, collaborators and deploy keys, which a runner service does not need. If requested permissions change in the future, GitHub or the customer may require a new approval. Runzivo will not assume an earlier installation approves later permission changes. ## Writes and workflow control Contents, Workflows and Pull requests write allow the pipeline builder and CI fix agent to deliver workflow changes. Both are in early access and are not available to customers yet. The CI fix agent changes CI files only, opens a pull request from a new branch, never pushes to an existing branch and never merges. Runzivo registers runners at the organization level with the Self-hosted runners permission. Because it does not hold Administration, it cannot change repository settings, branch protection, collaborators or deploy keys. Any future customer-initiated write requires authenticated customer action, tenant and selected-repository checks, and an operation-scoped installation token narrowed to the repository and permissions where GitHub supports narrowing. Repository writes are limited to a branch and pull request in the authorized repository, with no branch-protection or ruleset bypass. The one exception: a workspace owner can opt the pipeline builder in to commit a workflow file directly, still subject to branch protection. A runner executes the workflow a customer selects in GitHub Actions. Workflow steps can read or modify repository data, access secrets GitHub makes available to that job, and trigger actions with the workflow's own credentials. The App permissions do not directly grant access to a live job environment, job token, or stored Actions secrets. Secrets in code, logs, artifacts, or changed workflow content remain a risk. ## Customer controls and records Customers control repository access in GitHub App installation settings by adding or removing selected repositories. Suspending or uninstalling the App stops new runner requests. A revoked or unselected repository is denied by the authorization boundary. Raw webhook bodies are retained only in memory long enough to verify the signature and route a delivery. They are not logged or retained. Planned event acknowledgements retain nothing. Current queued-job handling persists only delivery ID, job, installation, and repository IDs, action, labels, admission decision, reason, and timestamp. It does not persist raw payloads. The current delivery-audit table has no purge. Tenant-approved retention and deletion work is a launch blocker for onboarding and processing. Before enabling future collection, Runzivo must apply tenant-approved retention and deletion to webhook, membership, PR or issue discussion, run metadata, logs, and metrics data. The Privacy Notice is a working draft for newsletter and Early Access information. It does not set a retention period or deletion process for GitHub App delivery audits. This page states the current GitHub App record handling and launch blocker; contact Runzivo for questions about the draft notice. [Read the privacy notice](https://runzivo.dev/legal/privacy/) On this page and page tools --- Source: https://runzivo.dev/docs/runners/ # Linux x64 runners Run eligible GitHub Actions jobs on available Linux x64 runners. ## V1 runner model Runzivo assigns each eligible GitHub Actions job a fresh Firecracker microVM. The environment is single-use and is destroyed after the job finishes, is cancelled, or cannot continue. A runner is registered with GitHub after a connected, selected repository requests a supported runner configuration. Every microVM is a cold boot; there is no pre-booted warm pool today. Runner hosts run in Ottawa (YOW) and Montreal (YUL), Canada. ## Runner labels Available Linux x64 labels are rzv-ubuntu-24.04-x64-2vcpu-8gb, rzv-ubuntu-24.04-x64-4vcpu-16gb, rzv-ubuntu-24.04-x64-6vcpu-24gb, rzv-ubuntu-24.04-x64-8vcpu-32gb, rzv-ubuntu-24.04-x64-16vcpu-64gb, rzv-ubuntu-24.04-x64-32vcpu-128gb. This example uses the 2 vCPU default: GitHub Actions · runner label ```yaml runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb ``` ## Capacity and sizes Runzivo currently supports Linux x64 only. The 2 vCPU, 4 vCPU, 6 vCPU, 8 vCPU, 16 vCPU, 32 vCPU runner sizes are available now. Run up to your plan's concurrent job limit. Jobs may queue when runner capacity is unavailable. For eligible capacity waits where Runzivo confirms the job never started and no runner resources remain allocated, Runzivo waits up to 900 seconds by default. This platform limit is configurable. When the wait expires, Runzivo ends the local attempt with zero execution charge, alerts staff, and provides rerun guidance. The attempt does not cancel the GitHub workflow or its sibling jobs. [Review pricing](https://runzivo.dev/pricing/) ## Docker in jobs Docker Engine is available in jobs. Jobs can pull images and run containers. Each job starts with an empty Docker state, because each job runs in a fresh microVM. The runner image includes Docker Engine 29.1.3, Docker Buildx 0.30.1 and Docker Compose v2 2.40.3, installed from Ubuntu 24.04 packages. On this page and page tools --- Source: https://runzivo.dev/docs/configuration/ # Configuration, environments, and secrets Keep GitHub Actions workflow configuration in GitHub and make the smallest runner-label change first. ## Workflow configuration Runzivo does not replace the GitHub Actions workflow format. Keep triggers, permissions, actions, environment settings, and steps in your repository workflow file. Start by changing only runs-on. Use the same workflow review process you use for any CI change. The V1 design lets GitHub assign a job to an eligible repository-scoped runner. GitHub Actions · existing workflow job ```yaml jobs: test: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb environment: stg steps: - uses: actions/checkout@v7 - run: ./ci/test.sh ``` ## Secrets and variables Manage repository and environment secrets in GitHub. A workflow step can read any secret GitHub makes available to that job, so use least privilege and do not print secrets in logs. The V1 design does not add repository secrets to runner configuration. It keeps platform credentials and control-plane secrets out of customer workers. ## Network-dependent jobs The V1 security baseline uses isolated workers with host-enforced network controls. If a job cannot reach a required internal service or external endpoint, contact support with the endpoint and job details before moving a production workflow. On this page and page tools --- Source: https://runzivo.dev/docs/usage-limits/ # Usage and limits Early Access is controlled so Runzivo can validate reliability, isolation, and capacity with real workloads. ## Early Access allowance Each workspace receives 3,000 free equivalent minutes per UTC month, shared across its public and private repositories. A 2 vCPU runner consumes one equivalent minute for each runner minute. Unused minutes do not roll over. New jobs cannot start once the free allowance is used up and no prepaid credits remain. The free allowance resets at the start of each UTC month. ## Concurrency Developer and Team: Run up to your plan's concurrent job limit. Jobs may queue when runner capacity is unavailable. Business: Higher concurrency limits, with optional dedicated, pre-warmed runner pools for guaranteed reserved capacity. Pre-warmed pools are a separately configured add-on, not included in every Business plan. Available on request; contact sales at run@runzivo.dev. ## What counts toward usage Runzivo records job execution and lifecycle events to operate the service, enforce limits, and investigate failures. Usage counts runner minutes, multiplied by the runner size. Insights in the portal shows recorded minutes by day and runner size. ## If you need more capacity Contact support with the repository, workflow, expected job duration, and desired concurrency. ## Prepaid credits After the free allowance, a workspace uses prepaid credits. Credit packs exclude tax, and no tax is collected yet: Starter pack, 5,000 equivalent minutes, CA$28, US$20, €18 or £15; Team pack, 25,000 equivalent minutes, CA$130, US$93, €83 or £70; Scale pack, 100,000 equivalent minutes, CA$495, US$353, €316 or £265. Team and Business plans are available in the portal under Billing & Credits. The plans guide covers renewal, grace and cancellation. [Read the Team and Business plans guide](https://runzivo.dev/docs/plans/) ## Pay by bank transfer Start the transfer in the portal under Billing & Credits. Choose CAD or USD, the minutes, and get payment instructions. Only owners and admins can do this. The portal shows a reference, RZV-XXXX-XXXX, and our bank details. Put the reference in the transfer memo. Credit is added after we match the deposit, and you get a receipt by email. If Pay by bank transfer isn't available in your workspace, email run@runzivo.dev. Runzivo does not publish bank account numbers on this site. Use the details the portal shows you. ## Card checkout Card checkout is available only for workspaces billed in Canada or the United States. Those workspaces can buy credit packs by card in the portal under Billing & Credits. Checkout is handled by Stripe. Workspaces billed in other countries can buy credits by bank transfer. On this page and page tools --- Source: https://runzivo.dev/docs/plans/ # Team and Business plans Subscribe to Team or Business, and what happens at renewal, after a failed payment and when a plan is cancelled. ## How a plan works Team and Business are billed monthly or yearly. A yearly plan costs 15% less than twelve monthly payments. Prices and included unit-minutes are on the pricing page. A plan's included unit-minutes replace the free allowance. They are granted each month, on a yearly plan too, and do not roll over. Usage draws on included unit-minutes first, then prepaid credit, then overage up to the plan's monthly overage cap. Overage is invoiced monthly. [See plan prices](https://runzivo.dev/pricing/) ## Subscribe - Owners and admins subscribe in the portal under Settings, Billing & Credits. Set the billing country first. Card checkout is available only for workspaces billed in Canada or the United States. - Choose Team or Business and Monthly or Yearly, agree to overage charges, and confirm it's you if the portal asks. - Pay with a card in the Stripe checkout. The plan starts when Stripe confirms the payment, not when the checkout page closes. ## Renewal A plan renews at the end of each paid term. Billing & Credits shows the plan, its status and the current paid period. ## If a renewal payment fails The plan becomes past due, and a grace period starts. Grace lasts 7 days by default. Included unit-minutes, prepaid credit and running work stay available. When grace ends, new overage stops until the renewal is paid. Paying ends the grace period. An unpaid monthly overage invoice stops new overage at once, with or without grace. ## Cancel or change a plan To cancel, or to change plan or billing interval, contact support. The portal has no cancel or plan-change action yet. A cancellation takes effect at the end of the paid term. The plan keeps working until then, and Billing & Credits shows the date it ends. Paid terms are not refunded. A change between monthly and yearly takes effect at renewal. [Open Support in the portal](https://app.runzivo.dev/support) On this page and page tools --- Source: https://runzivo.dev/docs/redeem-a-code/ # Redeem a code Add credit to a workspace with a promo code or prepaid voucher. ## In the portal Open Settings, then Billing & Credits, and select Redeem a code. Enter the promo code or prepaid voucher. Redeeming needs permission to change billing. Promo credit can expire. ## From the CLI Save the promo code or voucher in a local file, then replace \ with that file's path. The command does not store the code. Check the workspace balance after redemption. Redeeming needs permission to change billing. Terminal · redeem from a file and check the balance ``` rzv billing codes redeem --code-file rzv billing ``` [Read about the free allowance and prepaid credits](https://runzivo.dev/docs/usage-limits/) On this page and page tools --- Source: https://runzivo.dev/docs/insights/ # Insights See job counts, recorded minutes, duration, queue wait and the slowest workflows for a workspace. ## Open Insights In the customer portal, open CI & Runners, then Insights. Choose 7, 30 or 90 days (UTC); the default is 30. - Summary: jobs by day and status, recorded minutes by day and runner size, and median and P90 duration and queue wait. Recorded minutes show only for people who can view billing. - Heatmap: when jobs queue, by UTC weekday and hour. - Slow jobs: workflows ranked by P90 duration. ## From the CLI Read the same workspace data from a terminal. These examples cover seven UTC days. Set --days to a value from 1 to 90, and add --json for machine-readable output. Terminal · the last seven UTC days ``` rzv insights summary --days 7 rzv insights heatmap --days 7 rzv insights slow-jobs --days 7 ``` [Read the rzv command reference](https://runzivo.dev/docs/cli-commands/) On this page and page tools --- Source: https://runzivo.dev/docs/notifications/ # Notifications Read workspace notifications in the portal and choose which categories also reach you by email. ## Inbox and categories The portal keeps an inbox of workspace notifications. Each notification belongs to one category: billing, jobs, account, support or system. Under Settings, Notifications, choose for each category whether it appears in the portal, by email, or both. Runzivo can lock the email setting for some notifications. Failed-job notifications are in-app only. ## From the CLI Read the inbox and its current delivery settings. These commands need your own sign-in; API keys are not accepted. Use command help for marking notifications read or changing a category's settings. Terminal · inspect notifications and delivery settings ``` rzv notifications list rzv notifications settings show rzv help notifications ``` [Read the rzv command reference](https://runzivo.dev/docs/cli-commands/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes/ # Agent Sandboxes Isolated Linux microVMs where a workspace runs commands and opens a terminal, for up to eight hours. ## What a sandbox is A sandbox is a Firecracker microVM in your workspace. You create it, run commands in it, open a terminal, stop it and start it again, from the rzv CLI, the customer API or the portal. Files in /workspace survive a stop and a start. A sandbox lasts eight hours from its first start, by the wall clock. Stopping does not pause that time, starting again does not reset it, and it cannot be extended. After eight hours the sandbox expires and its VM and files are deleted. ## Statuses - pending waits for a host. starting and stopping wait for the host to confirm. - running has a VM up. Only a running sandbox accepts commands and terminals. - stopped keeps its files and is not billed. - deleting removes the VM and its files. deleted and expired sandboxes are gone. - failed names its cause in error. You can start a failed sandbox again until it expires. ## Who can use sandboxes Owners, admins and members can view sandboxes. Owners and admins can create, start, stop and delete sandboxes, run commands and open terminals. API keys are limited by their permissions and by their creator's role. [See API key permissions for sandboxes](https://runzivo.dev/docs/sandboxes-api/#authentication) ## Sandbox guides [Create your first sandbox](https://runzivo.dev/docs/sandboxes-quickstart/) [Open a terminal or run commands](https://runzivo.dev/docs/sandboxes-terminal/) [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) [Sandbox API reference](https://runzivo.dev/docs/sandboxes-api/) [Exec and terminal API reference](https://runzivo.dev/docs/sandboxes-api-exec/) [Connect with SSH, scp, sftp and rsync (Coming soon)](https://runzivo.dev/docs/sandboxes-ssh/) [The sandbox developer image (Coming soon)](https://runzivo.dev/docs/sandboxes-developer-image/) [Persistent disks for sandboxes (Coming soon)](https://runzivo.dev/docs/sandboxes-persistent-disks/) [Repository access in a sandbox (Coming soon)](https://runzivo.dev/docs/sandboxes-repositories/) [OpenHands tasks in a sandbox (Coming soon)](https://runzivo.dev/docs/sandboxes-openhands/) [Upcoming sandbox API endpoints (Coming soon)](https://runzivo.dev/docs/sandboxes-devx-api/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-quickstart/ # Create your first sandbox Create a Linux sandbox, write and inspect a file, then stop and delete it. Use the CLI walkthrough or the API and portal alternatives below. ## 1. Sign in and select a workspace Install the rzv CLI first. Sign in, list your workspaces and replace \ with an ID or slug from the list. Creating sandboxes, running commands and changing their state require an owner or admin role. The examples are commands to run, not captured results. Replace every placeholder in angle brackets before running a command. Use the sandbox ID returned by your own create request for the rest of this walkthrough. Terminal · sign in and select your workspace ``` rzv login rzv workspaces list rzv workspaces select ``` [Install the rzv CLI](https://runzivo.dev/docs/cli/) ## 2. Check sizes and capacity List your sandboxes before creating one. The response shows the sizes currently offered, the workspace's running limit, and each sandbox's status, time left and credits used. The CLI supports 2vcpu-8gb, 4vcpu-16gb, 8vcpu-32gb and 16vcpu-64gb. Available sizes depend on host capacity. This walkthrough uses 2vcpu-8gb; choose another offered size if it is unavailable. Creating or starting a sandbox also needs workspace credit. Terminal · check current availability ``` rzv sandboxes list ``` [Sizes, limits and billing](https://runzivo.dev/docs/sandboxes-limits/) ## 3. Create a sandbox Create and start a sandbox named code-check with a 20 GiB workspace disk. Copy the sandbox ID from the response. Wherever later examples say \, substitute that ID. The disk can be 5 to 64 GiB. The default is 20 GiB if you omit --disk-gib. To retry creation safely, supply the same --idempotency-key on both requests. Terminal · create a sandbox in the selected workspace ``` rzv sandboxes create --name code-check --size 2vcpu-8gb --disk-gib 20 ``` ## 4. Wait until it is running Inspect the new sandbox. If its status is pending or starting, repeat get until it becomes running before sending commands. A failed status includes the cause; resolve it before continuing. Terminal · replace \ with the returned ID ``` rzv sandboxes get ``` ## 5. Write a result file This command writes a line into result.txt in /workspace. It should finish successfully without printing the file's contents. The next step reads the file back. The -- separates rzv options from the remote command. Use explicit bash -lc for shell syntax such as redirection. Keep the script quoted so your local shell does not redirect the output into a local file. Terminal · write a file inside the sandbox ``` rzv sandboxes exec -- bash -lc 'printf "hello sandbox\n" > result.txt' ``` ## 6. Inspect the result Read the file in a second command. It should print hello sandbox followed by a newline. The CLI streams stdout and stderr and exits with the remote command's status. Terminal · read the file inside the sandbox ``` rzv sandboxes exec -- cat result.txt ``` ## 7. Stop when you need a break Stopping ends the running charge and keeps files in /workspace within the sandbox's lifetime. Inspect its status after the stop request. Start it again if you need to continue before it expires. The eight-hour lifetime begins at the first start. Stopping does not pause the clock, and starting again does not reset it. Terminal · stop and inspect the sandbox ``` rzv sandboxes stop rzv sandboxes get ``` ## Optional: resume a stopped sandbox Start the same sandbox again to return to its files before its eight-hour lifetime ends. Wait until its status is running before sending another command. Terminal · resume within the existing lifetime ``` rzv sandboxes start rzv sandboxes get ``` ## 8. Delete when finished Delete the sandbox you created for this walkthrough when you no longer need its files. Deletion removes the VM and its files. Check the list afterward for the resulting state. Terminal · delete the walkthrough sandbox ``` rzv sandboxes delete rzv sandboxes list ``` [More command and terminal examples](https://runzivo.dev/docs/sandboxes-terminal/) ## API alternative: create a sandbox Send a person's access token, or a workspace API key with the sandboxes:write permission, as a bearer token. Supply RZV_TOKEN securely and replace \ with your workspace's ID. Repeating client_operation_id returns the sandbox the first request created. Read the returned sandbox ID and wait until its status is running before sending an exec request. The API reference documents lifecycle and status requests. Terminal · replace the workspace ID and provide RZV_TOKEN ``` curl -X POST "https://api.runzivo.dev/v1/customer/tenants//sandboxes" \ -H "Authorization: Bearer $RZV_TOKEN" \ -H "Content-Type: application/json" \ -d '{"name":"agent-1","size":"2vcpu-8gb","client_operation_id":"agent-1-create"}' ``` [See API key permissions for sandboxes](https://runzivo.dev/docs/sandboxes-api/#authentication) [Sandbox lifecycle API reference](https://runzivo.dev/docs/sandboxes-api/) ## API alternative: run a command After the sandbox reaches running, replace \ with its returned ID. This example asks the Linux guest to identify its operating system. The exec API streams output and the final exit event. Terminal · execute in a running sandbox ``` curl -X POST "https://api.runzivo.dev/v1/customer/tenants//sandboxes//exec" \ -H "Authorization: Bearer $RZV_TOKEN" \ -H "Content-Type: application/json" \ -d '{"cmd":"uname -s"}' ``` [Exec and terminal API reference](https://runzivo.dev/docs/sandboxes-api-exec/) ## In the portal - 1\. Open Build & Deploy, then Sandboxes, and select New Sandbox. - 2\. Enter a name, choose an offered size, and select Create sandbox. - 3\. Wait until running, then use the terminal on the sandbox page. The page also shows status, time left and credits used. - 4\. Use Stop when you need a break, Start to continue within the lifetime, and Delete when finished. - If the page says Sandboxes are not available yet, they are not turned on for your environment. [Open the customer portal](https://app.runzivo.dev/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-terminal/ # Sandbox terminal and commands Run a command and inspect its result, pass arguments or a shell script, or open an interactive terminal in a running sandbox. ## Run a command Use a running sandbox and replace \ with its ID. Exec starts in /workspace unless you choose another directory. It streams stdout and stderr and ends with the command's exit code. This example should print Linux followed by a newline. If your client disconnects, the command is cancelled. Runzivo does not log commands or their output, and does not add them to the activity log. Terminal · identify the guest operating system ``` rzv sandboxes exec -- uname -s ``` ## Pass arguments exactly In rzv 0.21.0, two or more arguments after -- are passed as an exact argument list. Quote a value containing spaces so your local shell sends it as one argument. This example prints two words as one line. One argument after -- is treated as a shell script and is passed unchanged. For scripts with pipes, redirection or &&, the explicit bash -lc form in the next example makes the shell boundary clear. Terminal · preserve a value containing spaces ``` rzv sandboxes exec -- printf '%s\n' 'two words' ``` ## Write and inspect a file Use bash -lc with a single quoted script when the command needs shell operators. The quotes ensure \> runs in the sandbox rather than in your local shell. The first command writes result.txt; the second should print hello sandbox and a newline. Terminal · run shell redirection inside the sandbox ``` rzv sandboxes exec -- bash -lc 'printf "hello sandbox\n" > result.txt' rzv sandboxes exec -- cat result.txt ``` ## Choose a directory, timeout and environment Set --cwd for the remote working directory, --timeout for the command limit in seconds, and --env for comma-separated KEY=VALUE pairs. Environment values cannot contain commas. The defaults are /workspace and a 300-second timeout; the maximum timeout is 3600 seconds. This example runs in /workspace, allows 60 seconds and supplies a non-secret GREETING value. The quoted script expands GREETING in the sandbox and should print hello followed by a newline. Terminal · remote command options ``` rzv sandboxes exec --cwd /workspace --timeout 60 --env GREETING=hello -- bash -lc 'printf "%s\n" "$GREETING"' ``` ## Read the exit status A successful command exits with 0. A failing command returns its exit status. A timeout returns 124; exceeding the 8 MiB output cap returns 137 and marks the result truncated. Write large results to a file and inspect what you need instead of streaming them all. Use --json for scripts that need structured stdout, stderr and exit events. Output chunks carry base64-encoded data; the final exit event includes exit_code, timed_out and truncated. This format is a stream of events, not one JSON object. Terminal · stream machine-readable events ``` rzv sandboxes exec --json -- uname -s ``` [Exec event and close-code reference](https://runzivo.dev/docs/sandboxes-api-exec/) ## Open a terminal On macOS and Linux, ssh opens an interactive shell in a running sandbox through Runzivo; it does not connect to the VM directly. Every key, including Ctrl-C, goes to that shell. Leave with the shell's exit command. Windows and scripts should use exec instead. A shell starts at 80 by 24 and follows your window size. If the connection drops, the shell ends; open a new terminal to continue. Files in /workspace stay within the sandbox's lifetime. The portal also has a terminal on the sandbox page. Terminal · rzv sandboxes ssh ``` rzv sandboxes ssh ``` ## Connect your own terminal client For a browser or your own WebSocket client, request a single-use terminal ticket. JSON output includes url, ticket, expires_at, connect_url, sandbox_id and workspace_id. The ticket is a short-lived credential; keep it out of screenshots, logs and support messages. Use --workspace \ if the sandbox is outside the workspace currently selected in the CLI. Every command except ssh accepts --json. Terminal · request a ticket for your own client ``` rzv sandboxes terminal-ticket --json ``` [Terminal connection reference](https://runzivo.dev/docs/sandboxes-api-exec/) ## Limits and close reasons Each sandbox runs a limited number of commands and terminals at once, and an idle terminal closes. When a terminal closes, rzv sandboxes ssh and the portal say why. [See session limits](https://runzivo.dev/docs/sandboxes-limits/) [Read the close codes in the exec and terminal API reference](https://runzivo.dev/docs/sandboxes-api-exec/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-limits/ # Sandbox limits and billing Sizes, lifetime, running and session limits, and how sandbox compute is billed. ## Sizes and lifetime - Sizes are 2vcpu-8gb (1x), 4vcpu-16gb (2x), 8vcpu-32gb (4x) and 16vcpu-64gb (8x). Which sizes are offered depends on current host capacity. The sizes field of the list response names the ones you can create now; any other size is refused with size_unavailable. - The workspace disk is 5 to 64 GiB, 20 GiB by default. - Each sandbox lasts eight hours from its first start and cannot be extended. - A workspace can run 2 sandboxes at once by default. The list response shows your limit as max_running. ## Commands and terminals - Up to 4 commands and 2 terminals run in one sandbox at a time. - A command times out after 300 seconds by default, and at most 3600. A command still running 30 seconds past its timeout is cancelled with exit code 124. - Command output is capped at 8 MiB. Past that the command ends with exit code 137 and is marked truncated. - A terminal closes after 30 minutes with no input or output. ## Billing A running sandbox uses unit-minutes from your workspace allowance or prepaid credit, at the multiplier of its size, from 1x for 2 vCPU to 8x for 16 vCPU. A stopped sandbox is not billed, and a start that never reaches running charges nothing. Each start reserves 15 minutes ahead and adds more while the sandbox runs. When a run ends, only the seconds it ran are charged. credits_used shows the charge so far, including the current run. Without credit, create and start are refused with credit_exhausted. If credit runs out while a sandbox runs, the sandbox fails with credit_exhausted and stops. Its files stay, and you can start it again after adding credit. [See unit-minute pricing](https://runzivo.dev/pricing/) [Read about usage and credits](https://runzivo.dev/docs/usage-limits/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-ssh/ # Connect with SSH, scp, sftp and rsync Coming soon. Standard SSH access and editor connections are not available yet. ## Connect when enabled On macOS or Linux, install rzv and OpenSSH, sign in with rzv login and select your workspace. The sandbox will need to be running, and Runzivo will need to enable SSH for your environment. SSH from a Windows computer is not supported yet. Use rzv sandboxes exec instead. Connecting will need sandboxes:write. Generating configuration with an API key will need sandboxes:read. No public IP or public SSH port will be needed. Commands after enablement. Replace \ ``` rzv sandboxes ssh rzv sandboxes ssh -- 'uname -a' rzv sandboxes ssh-config rzv sandboxes ssh-config --write ssh .rzv scp file.txt .rzv:/workspace/ sftp .rzv rsync -a -e ssh ./project/ .rzv:/workspace/project/ ssh -N -L 8080:localhost:3000 .rzv ``` ## Use VS Code or Cursor These steps need a CLI release that supports SSH. No such release is available yet. Planned workflow: run ssh-config with --write as above. It maintains its own Host block and adds an Include to ~/.ssh/config, preserving other configuration. Add --workspace \ when generating configuration. An API key requires an exact workspace ID. Confirm plain ssh works, then install your editor’s Remote SSH extension, choose \.rzv and open /workspace. The generated ProxyCommand runs rzv sandboxes ssh --stdio with your profile, workspace and binding. Preserve host verification. We have not yet tested VS Code or Cursor against a live sandbox. Simplified. The generated file adds --profile, --workspace, --binding and a Match exec refresh. Use the generated file. ``` ProxyCommand rzv sandboxes ssh --stdio ``` ## Transfer files Use the generated SSH alias with scp, sftp or rsync. Review files before copying: source folders often contain credentials. Do not disable host-key checks or paste tokens into commands. Use rzv sandboxes terminal \ for the existing PTY shell. Only rzv sandboxes ssh \ with no extra arguments will fall back to that shell when SSH or OpenSSH is unavailable. Remote commands and file transfers will receive guidance instead. ## Forwarding and limits Local port forwarding will reach only services on the sandbox’s own localhost. Remote forwarding, SSH agent forwarding, X11, tunnels and Unix-socket forwarding will be disabled. Planned limits: at most two SSH sessions per sandbox. Sessions will close after thirty idle minutes or when the sandbox stops, expires or is deleted. ## Use case: review an agent’s work Planned workflow: connect your editor over Remote SSH and open /workspace. Let your coding agent edit files in the sandbox and inspect the diff before you commit. Forward a local preview port to a service listening on the sandbox’s localhost. Copy work out before the eight-hour sandbox lifetime ends. ## Related pages [Editor example](https://runzivo.dev/docs/sandboxes-devx-example-editor/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-developer-image/ # The sandbox developer image Coming soon. The developer image is not available yet. Its planned tools will be signed out. ## Planned tools, accounts signed out The planned developer image will include git, GitHub CLI (gh), Codex CLI, Claude Code, rsync, OpenSSH with SFTP, Node.js, Go, Rust and Python 3 with pip and venv. No Docker daemon or customer login will be included. ## Bring your own authorized access The preinstalled Codex and Claude Code will not use your workspace AI providers and will have no private-repository access. Use your own authorized login. ## Use case: test a change in Linux Once enabled, open a sandbox from your editor, edit a Python service and run its tests. Use the same environment for a Node frontend or a Go or Rust command. Review the output before copying changes back. ## Keep your work Work under /workspace survives a stop and start within the sandbox lifetime. The sandbox and its files expire eight hours after first start. Persistent disks are a separate coming-soon feature. On this page and page tools --- Source: https://runzivo.dev/docs/docker-layer-cache/ # Docker layer cache for CI Coming soon. Docker layer caching is in development and is not available yet. ## Use case: repeat a container build Once available, add a buildx step using RZV_DOCKER_CACHE_DIR. A later run of the same trusted ref on the same host will reuse matching layers while its cache is retained. Changed inputs rebuild affected layers. Check build output for CACHED on unchanged steps. No speedup is guaranteed. ## Workspace and repository boundaries Caches will separate workspaces, repositories and trust levels. Untrusted runs will use per-attempt scopes. The design keeps fork pull requests and other untrusted jobs out of any cache that trusted builds read. Concurrent jobs will use separate disk copies. The last completed snapshot will replace the earlier one. ## Cold builds remain normal The cache will be disposable, size-limited and subject to eviction. A different host will start cold. Shared cache reuse across hosts is not available. Never store secrets or the only copy of your data in a build cache. ## Availability and billing Saving a cache preference does not turn caching on. No price has been announced. Keep your working build workflow until caching is available for your workspace. Check this page for status. We have not set a launch date. ## Related pages [Buildx example](https://runzivo.dev/docs/docker-layer-cache-example/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-persistent-disks/ # Persistent disks for sandboxes Coming soon. Host-local persistent disks are in development and are not available yet. ## Use case: keep development data A persistent disk will keep a development database or downloaded dependencies separately from a sandbox’s temporary system disk. It will belong to one workspace and one physical host. Only one sandbox will write to it at a time. ## Host-bound storage The sandbox will have to run on the host holding the disk. If that host is unavailable, the disk will be unavailable. There will be no automatic failover. Today, /workspace files survive a stop and start only until the sandbox expires. That is not a persistent disk. ## Snapshots are not off-host backups The design takes local snapshots only while the disk is detached. Losing the host’s storage would lose both the disk and its local snapshots. Customer create, attach, restore and delete actions are not yet available. ## Price and status Persistent disks have no price yet. Check this page for status. We have not set a launch date. On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-repositories/ # Repository access in a sandbox Coming soon. Repository tokens are not available in production yet. Automatic private-repository login is not available yet. ## Use case: Codex or Claude Code on a private repository Once available, you will request a short-lived token for one repository selected in your workspace’s GitHub App installation. Git, Codex and Claude Code currently need your own authorized login. Tools in the planned developer image will never be preauthenticated. ## Permissions The repository will need to be selected in the workspace’s connected GitHub App installation, and the sandbox will need to be running in that workspace. Read will require sandboxes:write plus repositories:read. Push will require sandboxes:write plus repositories:write. An API key will need both permissions and will never exceed its creator’s current permissions. ## What push permits Push access will grant contents:write, including deletion of branches and tags and creation of releases. Branch protection will still apply. Workflow-file updates will not be granted. Prefer read access when a task does not need to push. ## Protect the token Tokens will normally expire in one hour. A token will work outside the sandbox until it expires. Never place tokens in Git remote URLs, shell commands, environment files or exec input. Automatic guest credential delivery is not available yet. ## Related pages [Private repository example](https://runzivo.dev/docs/sandboxes-devx-example-repository/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-openhands/ # OpenHands tasks in a sandbox Coming soon. OpenHands tasks are in development and not yet tested in a live sandbox. They are not available yet. ## Use case: delegate a bounded task Once enabled, ask OpenHands to add tests for one module under a fixed per-task AI budget and workspace spending caps. Tasks will need a supported workspace AI provider. Tasks are planned for OpenAI-compatible chat providers. Native Anthropic and Responses providers will not be supported. The design keeps provider keys outside the sandbox. A task is meant to stop when its budget runs out. If a call’s usage is unknown, Runzivo plans to count the full reserved amount. Review changes and test results before keeping them. ## Task controls after enablement Planned workflow: start the sandbox, open its Agent panel and select Start Agent Server. When task access is available, enter a prompt and select Submit task. Watch events, send a follow-up, pause, resume or cancel. Pause will wait for the current model call. Cancel will stop the server. Closing the panel will leave the task running. Restart the server for another task after completion. ## Access and lifetime Submit, steer, pause and resume will need sandboxes:write and ai_chat:use. Only the task owner will steer, pause or resume a task. Sandbox writers will be able to cancel it. Task events will need sandboxes:write. Readers will see status only. Anyone able to run sandbox commands, including through sudo, will have the active task’s AI access up to its budget. Share command access only with trusted people and code. Planned limits: sessions last at most one hour and end when the sandbox stops or expires. ## Billing No price has been announced for OpenHands tasks. Existing sandbox compute billing still applies. Installed Codex and Claude Code are separate tools with their own authorized logins. The panel will not estimate remaining spend. On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-devx-api/ # Upcoming sandbox API endpoints Coming soon. Planned API contract, subject to change. These API features are not available yet. ## Authentication and prefix Use a bearer access token or workspace API key. Paths below follow /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}. Permissions never grant access to another workspace. Runzivo turns SSH, repository tokens and OpenHands on separately. None is available in production yet. ## SSH and repository access - GET /ssh-host: sandboxes:read. 200 with host_ca_public_key and host_key_alias. Public trust material, no connection ticket. - POST /ssh-ticket: sandboxes:write. {public_key}. 201. Planned limits: a single-use ticket lasting 30 seconds and a user certificate valid for fifteen minutes. Never log credentials. - GET /ssh?ticket=...: 101 WebSocket. Raw SSH bytes. Use the CLI proxy and keep host-key verification. - POST /repository-token: {repository, push?}. 200. One authorized owner/name. The push field defaults to false. Read will require sandboxes:write plus repositories:read. Push will require sandboxes:write plus repositories:write. Guest delivery is not automatic. ## OpenHands task contract - GET /agent: 200. POST /agent with {}: 202. DELETE /agent: 200. Read status, start or stop the server. Active does not prove readiness. - POST /agent/tasks: {session_id, prompt, model_budget_micro_usd?}. 202. Requires sandboxes:write and ai_chat:use. The budget is an internal ceiling, not a price. - GET /agent/tasks: 200. GET /agent/tasks/output?task_id=ID&after=N: 200 NDJSON. Status for readers. Events for sandbox writers. - POST /agent/tasks/steer: {task_id, prompt}. POST /agent/tasks/pause or /agent/tasks/resume: {task_id}. Require sandboxes:write and ai_chat:use. Owner only. Controls are queued. Do not automatically retry a follow-up. - DELETE /agent/tasks?task_id=ID: 200. Any sandbox writer will be allowed to cancel the task and its server. ## Related pages [SSH](https://runzivo.dev/docs/sandboxes-devx-api-ssh/) [Repository token](https://runzivo.dev/docs/sandboxes-devx-api-repository-token/) [OpenHands server](https://runzivo.dev/docs/sandboxes-devx-api-agent-server/) [OpenHands tasks](https://runzivo.dev/docs/sandboxes-devx-api-agent-tasks/) [Controls and events](https://runzivo.dev/docs/sandboxes-devx-api-agent-controls/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-devx-api-ssh/ # SSH host, ticket and relay Coming soon. Planned API contract, subject to change. These features are not available yet in production. ## Authentication and path Paths follow /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}. Requests will use a bearer customer access token or a workspace API key. The sandbox and repository grants below are key permissions, not legacy scopes. A key with all:all will also work, within its creator’s current permissions. The SSH relay uses its ticket instead of a bearer token. ## Host trust /ssh-host GET /ssh-host will require sandboxes:read or sandboxes:write. A 200 response will return host_ca_public_key (the Ed25519 host CA) and host_key_alias (sbx_… .sandbox.runzivo.dev). It will work for a stopped sandbox and create no credentials. Keep StrictHostKeyChecking yes and use the returned CA and HostKeyAlias. ## Ticket /ssh-ticket POST /ssh-ticket will require sandboxes:write and a running sandbox. The JSON field public_key will be required. It will need to contain one Ed25519 or ECDSA P-256 OpenSSH public key without options, at most 4096 UTF-8 bytes. The request body will be limited to 8 KiB. A 201 response will return url, ticket, expires_at, certificate, certificate_expires_at, principal=user, host_ca_public_key and host_key_alias. Planned limits: the ticket will be single use and last 30 seconds. The user certificate will be valid for fifteen minutes. Never log either one. ## Relay /ssh GET /ssh?ticket=… will take the issued ticket instead of a bearer header. A 101 response will upgrade to a WebSocket. Binary frames will carry raw SSH bytes. A text frame {"type":"eof"} will half-close one direction. OpenSSH will need the CLI ProxyCommand. There will be no public SSH port. Planned limits: two sessions per sandbox, a 30-minute idle timeout and an 8 MiB unread-output cap. ## Errors The host route will return 401, 403, 404, 500 and 503. The ticket route will also return 400, 409 and 429 ticket_limit_reached. The relay will also return 400, 409, 426 websocket_required and 429 rate_limited. A 503 with sandbox_ssh_unavailable will mean SSH, its CAs or the run’s host certificate are unavailable. The message and message_fr_CA fields will sometimes suggest a restart. Other missing prerequisites will return sandboxes_unavailable or sandbox_exec_unavailable. ## Related pages [API overview](https://runzivo.dev/docs/sandboxes-devx-api/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-devx-api-repository-token/ # Repository token request Coming soon. Planned API contract, subject to change. These features are not available yet in production. ## Authentication and path Paths follow /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}. Requests will use a bearer customer access token or a workspace API key. The sandbox and repository grants below are key permissions, not legacy scopes. A key with all:all will also work, within its creator’s current permissions. The SSH relay uses its ticket instead of a bearer token. ## POST /repository-token The JSON field repository will be required. Use a GitHub owner/name with no URL or .git suffix, at most 140 characters. The optional push field will default to false. The sandbox will need to be running and unexpired. The repository will need authorization in the workspace’s GitHub App installation. Read access will require sandboxes:write plus repositories:read. Push access will require sandboxes:write plus repositories:write. An API key will need to grant both. ## 200 response The response will return repository, username=x-access-token, token, expires_at and permission (read or write), with Cache-Control: no-store. Keep the token in memory. It will normally expire in one hour, and GitHub will supply expires_at. It will also work outside the sandbox until it expires. Push will grant contents:write, including branch and tag deletion and releases. It will not grant workflow-file changes. Guest delivery will not be automatic. Never send the token through exec or a Git URL. ## Refusals Invalid requests will return 400. Authentication and permission failures will return 401 or 403. A 404 will mean sandbox_not_found or repository_not_authorized. A sandbox conflict will return 409. Too many attempts will return 429 sandbox_repository_token_rate_limited with Retry-After: 60. Internal errors will return 500. A GitHub failure will return 502 sandbox_repository_token_failed. A disabled feature or missing App configuration will return 503 sandbox_repository_tokens_unavailable. Missing sandbox prerequisites will return sandboxes_unavailable. Planned limits: ten admitted attempts per workspace and five per caller in each rolling minute. ## Related pages [API overview](https://runzivo.dev/docs/sandboxes-devx-api/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-devx-api-agent-server/ # OpenHands server lifecycle Coming soon. Planned API contract, subject to change. These features are not available yet in production. ## Authentication and path Paths follow /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}. Requests will use a bearer customer access token or a workspace API key. The sandbox and repository grants below are key permissions, not legacy scopes. A key with all:all will also work, within its creator’s current permissions. The SSH relay uses its ticket instead of a bearer token. ## GET, POST and DELETE /agent GET will require sandboxes:read or sandboxes:write and will return 200. POST will require sandboxes:write. Its only optional body will be {}. POST will return 202 for a queued or existing session. DELETE will require sandboxes:write and return 200 with stopped or idle. DELETE will be idempotent and stay allowed after the feature is turned off. An active status will not prove the server is ready. ## Response fields and availability SandboxAgent will contain enabled, status (idle, active, stopped or failed), nullable session_id and exit_code, reason, tasks_available, task_unavailable_reason (empty, model_proxy_required, model_limit or permission_required) and readiness=unverified. Starting will need the feature turned on, the OpenHands image and a running sandbox. Otherwise POST will return 503 with sandbox_agent_unavailable, sandbox_exec_unavailable or sandboxes_unavailable. Reads and saved output will stay available after the feature is turned off. Not every read will return 503 in that state. ## GET /agent/output This route will require read permission. The session_id parameter will be required (sxe\_ plus 24 hex characters). The after parameter will be an optional integer of 0 or more, default 0. A 200 response will use application/x-ndjson. Each stdout or stderr line will carry seq and base64 data, followed by exit fields when the stream closes. Planned limits: 8 MiB of server output, kept up to 24 hours after closure. Readers will rotate after 110 seconds. Reconnect with the last seq. Disconnecting will not cancel the server. A 404 with sandbox_agent_not_started will mean the server has not started. A 409 with sandbox_agent_session_changed will mean you need to refresh the status. Other statuses will be 400, 401, 403, 500 and 503. ## Related pages [API overview](https://runzivo.dev/docs/sandboxes-devx-api/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-devx-api-agent-tasks/ # OpenHands task requests Coming soon. Planned API contract, subject to change. These features are not available yet in production. ## Authentication and path Paths follow /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}. Requests will use a bearer customer access token or a workspace API key. The sandbox and repository grants below are key permissions, not legacy scopes. A key with all:all will also work, within its creator’s current permissions. The SSH relay uses its ticket instead of a bearer token. ## POST /agent/tasks Submitting a task will require sandboxes:write, ai_chat:use, the feature turned on and a supported workspace provider. The JSON body will require session_id (sxe\_ plus 24 hex characters) and a nonblank prompt of at most 8192 UTF-8 bytes. The optional model_budget_micro_usd will be a positive integer up to the configured maximum. It will be an internal cost ceiling, not a price. The design keeps provider keys outside the sandbox. Anyone with sandbox command access will also get the task’s AI access up to its budget. ## GET and DELETE /agent/tasks GET will read the latest task with sandboxes:read or sandboxes:write and return 200. DELETE will require sandboxes:write and the query parameter task_id (UUID). It will return 200 and cancel the named task and its server. POST will return 202. Each success will return id (UUID), session_id, stream_id (both sxe\_ identifiers) and status (active, stopped or failed). Active will mean queued or running, not completed. ## Errors and model limits While the feature is off, POST will return 503 sandbox_agent_unavailable. A caller without ai_chat:use will receive 403 permission_required. A DELETE whose task_id is not the current task will return 409 sandbox_agent_session_changed. Other responses will be 400 invalid_request, 401, 404, 409, 429 sandbox_model_limit and 503 sandboxes_unavailable. GET /agent will report task capability as tasks_available and task_unavailable_reason. A running server alone will not enable tasks. Do not retry a task submission automatically. The internal budget will not be a new charge. ## Related pages [API overview](https://runzivo.dev/docs/sandboxes-devx-api/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-devx-api-agent-controls/ # OpenHands task controls and events Coming soon. Planned API contract, subject to change. These features are not available yet in production. ## Authentication and path Paths follow /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}. Requests will use a bearer customer access token or a workspace API key. The sandbox and repository grants below are key permissions, not legacy scopes. A key with all:all will also work, within its creator’s current permissions. The SSH relay uses its ticket instead of a bearer token. ## POST task controls POST /agent/tasks/steer will require task_id (UUID) and a nonblank prompt of at most 8192 UTF-8 bytes. POST /agent/tasks/pause and POST /agent/tasks/resume will require task_id and no prompt. All three will require sandboxes:write, ai_chat:use and the task owner. A 202 response will return the task object (id, session_id, stream_id, status). Pause will wait for the current model call. Watch the events for the queued result. Never retry a follow-up automatically. ## GET /agent/tasks/output This route will require sandboxes:write and the query parameter task_id (UUID). The after parameter will be an optional integer of 0 or more, default 0. A 200 application/x-ndjson response will return retained exec stdout and stderr chunks with seq and base64 data, then an exit event. Decoded stdout will contain task_event, task_status or task_error NDJSON. Events above 16 KiB will become notices. Planned limits: 512 KiB of task output. Readers will rotate at 110 seconds. Reconnect with the last sequence number. Disconnecting will not cancel work. A task_id that is not the current task will return 409 sandbox_agent_session_changed. ## Refusals and feature availability While the feature is off, steer, pause and resume will return 503 sandbox_agent_unavailable. A caller without ai_chat:use will receive 403 permission_required. A task_id that does not match the current task will return 409 sandbox_agent_session_changed for output or DELETE. Other responses will be 400, 401, 404, 409, 429 sandbox_model_limit and 503 sandboxes_unavailable. Check GET /agent for task capability. Saved server reads and output will stay available after the feature is turned off. No single feature-off response will cover every OpenHands read. ## Related pages [API overview](https://runzivo.dev/docs/sandboxes-devx-api/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-devx-example-editor/ # Develop with an editor and agent Coming soon. Planned worked example, not available yet in production. ## Before you start Planned workflow: connect your editor over Remote SSH and open /workspace. These steps need a CLI release that supports SSH. No such release is available yet. Use a running sandbox, your own authorized agent login and a project that is safe to edit. ## Planned example Planned example · replace placeholders ``` rzv sandboxes ssh-config --workspace "" --write ssh .rzv true ``` ## Review and protect your work Planned workflow: after plain SSH works, install the Remote SSH extension for VS Code or Cursor and choose the generated alias. Copy your project with the rsync guide. The upload excludes .git. Before asking the agent for one small change, create the clean snapshot below in the sandbox. After the change, compare it with diff -ruN and run the project’s tests. The planned developer image will include agents that come signed out. Copy changes out before expiry. Editor operation has not been tested against a live sandbox. ## Compare the agent’s changes Inside the sandbox · run each step at the indicated time ``` # Before the agent edits. Use a new snapshot path for each session. cp -a /workspace/project /workspace/project-before-agent # After the agent edits. Exit status 1 means differences were found. diff -ruN /workspace/project-before-agent /workspace/project ``` ## Related pages [Feature guide](https://runzivo.dev/docs/sandboxes-ssh/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-devx-example-repository/ # Request private-repository access safely Coming soon. Planned worked example, not available yet in production. ## Before you start Once available, you will request a short-lived token for one repository selected in your workspace’s GitHub App installation. This local Python example requests read access and prints metadata only. Set TENANT_ID, SANDBOX_ID and RUNZIVO_TOKEN securely in your client environment. Replace OWNER/REPOSITORY. The sandbox will need to be running. Your key will need sandboxes:write and repositories:read. ## Planned example Planned example · replace placeholders ``` # Planned API example. Run it locally only after the feature is available. import json, os, urllib.request base = "https://api.runzivo.dev/v1/customer/tenants" url = f"{base}/{os.environ['TENANT_ID']}/sandboxes/{os.environ['SANDBOX_ID']}/repository-token" request = urllib.request.Request(url, method="POST", data=json.dumps({"repository": "OWNER/REPOSITORY", "push": False}).encode(), headers={"Authorization": "Bearer " + os.environ["RUNZIVO_TOKEN"], "Content-Type": "application/json"}) with urllib.request.urlopen(request) as response: credential = json.load(response) # Inspect metadata only. Never print or persist credential["token"]. print({key: credential[key] for key in ("repository", "permission", "expires_at")}) ``` ## Review and protect your work The token will stay in local process memory and normally expire after one hour. This example does not clone into the sandbox or sign in Codex or Claude Code automatically. Guest credential delivery is not available. Do not put the token in Git URLs, exec input, shell history or environment files. Until a secure guest workflow is available, use your own authorized Git or agent login. An agent workflow with this token will still need a secure way to deliver it to the sandbox. Push will require sandboxes:write and repositories:write, and will grant contents:write. ## Related pages [Feature guide](https://runzivo.dev/docs/sandboxes-repositories/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-devx-example-rsync/ # Transfer a project with rsync Coming soon. Planned worked example, not available yet in production. ## Before you start Planned workflow: generate the alias and check that a plain SSH command runs. Run the dry run locally first and review every file it lists. Exclude credentials and local state. The example does not delete destination files. ## Preview the upload Planned example · dry run only · replace placeholders ``` rzv sandboxes ssh-config --write ssh .rzv true rsync -av --dry-run --exclude .git --exclude .env --exclude node_modules -e ssh ./project/ .rzv:/workspace/project/ ``` ## Copy after review Planned example · copies files ``` rsync -av --exclude .git --exclude .env --exclude node_modules -e ssh ./project/ .rzv:/workspace/project/ ``` ## Review and protect your work The dry run below previews copying results back into a separate local directory. Review the destination before you remove --dry-run. No command here turns on SSH or extends the eight-hour sandbox lifetime. Copy work out before expiry and keep host verification on. Planned example · dry run only ``` rsync -av --dry-run -e ssh .rzv:/workspace/project/ ./reviewed-copy/ ``` ## Related pages [Feature guide](https://runzivo.dev/docs/sandboxes-ssh/) On this page and page tools --- Source: https://runzivo.dev/docs/docker-layer-cache-example/ # Plan a Buildx cache step Coming soon. Planned worked example, not available yet in production. ## Before you start Planned workflow: Docker cache is not available in production. This example needs a Dockerfile and future authorized cache delivery. Saving a preference does not turn caching on. Without RZV_DOCKER_CACHE_DIR the example builds cold. ## Planned example YAML · planned ```yaml steps: - name: Build with local layer cache shell: bash run: | set -euo pipefail cache="${RZV_DOCKER_CACHE_DIR:-}" builder="rzv-${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}" docker buildx create --name "$builder" --driver docker-container trap 'docker buildx rm --force "$builder"' EXIT args=() if [[ -n "$cache" ]]; then rm -rf -- "$cache/next" args+=(--cache-to "type=local,dest=$cache/next,mode=max") if [[ -f "$cache/current/index.json" ]]; then args+=(--cache-from "type=local,src=$cache/current") fi fi docker buildx build --builder "$builder" --progress=plain \ "${args[@]}" \ --load --tag example:ci . if [[ -n "$cache" ]]; then rm -rf -- "$cache/current" mv -- "$cache/next" "$cache/current" fi ``` ## Review and protect your work Once caching is available, repeat an unchanged build on the same trusted ref and host and inspect the CACHED output. Changed inputs rebuild. A different host or eviction sometimes produces a cold build. The design keeps fork pull requests and other untrusted jobs out of any cache that trusted builds read. Export only once per job. No speedup or cache reuse across hosts is promised. No price has been announced. ## Related pages [Feature guide](https://runzivo.dev/docs/docker-layer-cache/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-api/ # Sandbox API reference Create, list, read, start, stop and delete sandboxes through the customer API. ## Authentication Call https://api.runzivo.dev with a person's access token or a workspace API key as a bearer token. An API key reads sandboxes with the sandboxes:read or sandboxes:write permission, and creates, starts, stops, deletes, runs commands and opens terminals with sandboxes:write. These are key permissions, not scopes: grant them under Settings, API Keys in the portal, or with rzv api-keys create --permissions sandboxes:write. A key with the all:all scope can do all of this too. A key can never do more than its creator's current workspace role allows. While Agent Sandboxes are off, every route answers 503 sandboxes_unavailable. [Open the endpoint-by-endpoint API reference](https://runzivo.dev/docs/reference/) ## Endpoints - GET /v1/customer/tenants/{tenantId}/sandboxes lists sandboxes, newest first, with sizes (the sizes on offer) and max_running. - POST /v1/customer/tenants/{tenantId}/sandboxes creates a sandbox and starts it. Answers 201. - GET /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId} reads one sandbox. - POST /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}/start starts a stopped or failed sandbox. It keeps its original expiry. - POST /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}/stop stops a running sandbox. Its files stay. - DELETE /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId} stops the VM and removes the workspace disk. The files cannot be recovered. Deleting again changes nothing. ## Create request - name: 1 to 80 characters. Required. - size: 2vcpu-8gb, 4vcpu-16gb, 8vcpu-32gb or 16vcpu-64gb, billed at 1x, 2x, 4x or 8x. Required. Offered sizes depend on current capacity: use one that the list response's sizes field names. - disk_gib: 5 to 64, default 20. - client_operation_id: 8 to 200 characters. Repeating it returns the sandbox it first created. ## Sandbox object - id (sbx\_ and 24 hex characters), name, size, disk_gib, status, created_at. - error: null, or a code and message. Codes: no_capacity, insufficient_disk, start_timeout, stop_timeout, boot_failed, host_lost, credit_exhausted, workspace_blocked. - started_at: the first start, null until then. expires_at: the first start plus eight hours. - remaining_seconds: lifetime left, 28800 before the first start and 0 once expired. runtime_seconds: time the VM has been up. - credits_used: unit-minutes charged so far, at the size's multiplier. ## Refusals - 403: the token or its creator's role does not allow the route. 404 sandbox_not_found: no such sandbox in this workspace. - 409 sandbox_limit_reached, credit_exhausted, sandbox_name_taken, size_unavailable, workspace_blocked, sandbox_expired or sandbox_wrong_state. [Read about sandbox statuses](https://runzivo.dev/docs/sandboxes/) [See limits and billing](https://runzivo.dev/docs/sandboxes-limits/) On this page and page tools --- Source: https://runzivo.dev/docs/sandboxes-api-exec/ # Exec and terminal API reference Run a command with streamed output, or open the sandbox terminal as a WebSocket. Both need a running sandbox and a token that can change sandboxes. ## Run a command POST /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}/exec with cmd (required, run as bash -lc), cwd (default /workspace), env (up to 64 variables) and timeout_seconds. The body is at most 128 KiB, and cmd at most 64 KiB. The answer is application/x-ndjson: {"type":"stdout"|"stderr","data":"\"} lines as output arrives, then one exit line with exit_code, timed_out and truncated. When Runzivo ended the command, exit also has reason: sandbox_stopped, sandbox_expired or sandbox_deleted. [Open the command endpoint reference](https://runzivo.dev/docs/reference/sandboxes/exec/) [Open the terminal endpoint reference](https://runzivo.dev/docs/reference/sandboxes/terminal/) ## Open the terminal GET /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}/terminal upgrades to a WebSocket. API and CLI clients send Authorization. Terminal bytes travel as binary frames in both directions, never base64. The only text frame is the client's window size, {"type":"resize","cols":N,"rows":N} with 1 to 1000 each. Send it once after opening and on every change. Answer the server's ping, sent every 30 seconds, with a pong. ## Terminal ticket for browsers A browser cannot set Authorization on a WebSocket. POST /v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}/terminal-ticket returns url, ticket and expires_at. Open url with ?ticket=\ appended. A ticket works once, lasts 30 seconds and names one sandbox. A sandbox can have 10 unused tickets (429 ticket_limit_reached). The ticket is in the URL, so do not log the query string of this route in your own proxies. ## Close codes and refusals - 1000: sandbox_stopped, sandbox_expired, sandbox_deleted, shell_exited or idle_timeout. - 1003: an unknown or invalid text frame. 1008 input_rate: input above 256 KiB per second sustained, or a 1 MiB burst. 1009: a frame over 64 KiB. 1011: a server fault, output_overflow when output is read too slowly. - 401 ticket_invalid: a bad, used, expired or foreign ticket, before any upgrade. - 409 sandbox_wrong_state: the sandbox is not running. 409 session_limit_reached: too many commands or terminals. 503 sandbox_exec_unavailable: exec or the terminal is not set up. [See command and terminal limits](https://runzivo.dev/docs/sandboxes-limits/) On this page and page tools --- Source: https://runzivo.dev/docs/cli-commands/ # rzv command reference The commands in rzv 0.21.0, grouped by what they act on. Every command accepts --help, and every command except rzv sandboxes ssh accepts --json. ## Read these examples Install the CLI, sign in and select a workspace before using workspace-scoped commands. Replace values in angle brackets, such as \, with your own IDs before running an example. These are command examples, not captured output. Start with help to see every argument and option. Most commands accept --json. Sandbox exec streams JSON events rather than one object; sandbox ssh is interactive and does not accept --json. Terminal · command help ``` rzv help rzv help workspaces rzv help sandboxes ``` [Install the CLI and sign in](https://runzivo.dev/docs/cli/) ## Workspaces and access List the workspaces you belong to, select one, then inspect its settings, members, invitations and teams. The API enforces your role and permissions for every operation. rzv accounts is an older alias for workspaces. - Settings update changes a workspace's name or logo. Member and invitation commands manage roles and access; team commands manage team permissions and membership. - Closure requests ask staff to close a workspace, or withdraw a pending request. Nothing is deleted immediately. Terminal · select a workspace and inspect access ``` rzv workspaces list rzv workspaces select rzv workspaces settings show rzv workspaces members list rzv workspaces invitations list rzv teams list rzv permissions ``` ## Create a workspace Replace \ with the new workspace's slug and \ with its display name. Creation also selects the workspace. This changes your account; it is not required if you already belong to a workspace. Terminal · create and select a workspace ``` rzv workspaces create --slug --name "" ``` ## Jobs, runners and usage List jobs, then use a returned job ID to inspect its status and logs. Status is an alias for get. Use a repository ID to see the runner labels it can use. Terminal · job results and available runners ``` rzv jobs list rzv jobs get rzv jobs status rzv jobs logs rzv runner-profiles rzv runners rzv usage rzv concurrency ``` ## Insights Read job and recorded-minute totals, queue activity by UTC hour, and the slowest workflows. Use --days for a period from 1 to 90 UTC days. Terminal · the last seven UTC days ``` rzv insights summary --days 7 rzv insights heatmap --days 7 rzv insights slow-jobs --days 7 ``` [Insights guide](https://runzivo.dev/docs/insights/) ## Agent Sandboxes List sandboxes and available sizes, then create a sandbox for command execution or an interactive terminal. Start, stop and delete control its lifecycle. Exec runs commands; ssh opens a terminal; terminal-ticket supports your own terminal client. Terminal · inspect sandboxes and available commands ``` rzv sandboxes list rzv sandboxes get rzv help sandboxes ``` [Coming soon: standard SSH, editor and file-transfer examples](https://runzivo.dev/docs/sandboxes-ssh/) [Coming soon: worked rsync transfer](https://runzivo.dev/docs/sandboxes-devx-example-rsync/) [Create your first sandbox](https://runzivo.dev/docs/sandboxes-quickstart/) [Command and terminal examples](https://runzivo.dev/docs/sandboxes-terminal/) ## GitHub Inspect linked GitHub App installations and the repositories they cover. Use connect to begin linking an installation. Use the returned state and installation identifiers for authorize; do not invent or reuse expired link state. GitHub prompts for its own authorization when needed. Terminal · inspect and connect GitHub ``` rzv github status rzv github installations rzv repositories list rzv github connect ``` [GitHub App setup guide](https://runzivo.dev/docs/github-app/) ## Complete a GitHub connection Replace each placeholder with the value for your current connection. Ask an organization admin or owner to complete this step if you lack installation authority. Terminal · use the current connection's identifiers ``` rzv github authorize --state --installation-id --github-client-id ``` ## Billing Read the minute balance, credit packs and checkout availability, recent minute-pack purchases, receipts and invoices. Auto-recharge and country show their current settings. Card checkout is available only for workspaces billed in Canada or the United States. Checkout starts a purchase flow; use the pack ID from billing and reuse the same operation ID when retrying. The portal command prints a link to the payment provider's billing portal. Terminal · inspect billing ``` rzv billing rzv billing purchases rzv billing invoices rzv billing auto-recharge rzv billing country ``` [Usage, credits and payment options](https://runzivo.dev/docs/usage-limits/) ## Start checkout This starts card checkout for the selected workspace. Use your own pack and operation IDs. Terminal · checkout and payment portal ``` rzv billing checkout --pack --operation-id rzv billing portal ``` ## API keys Inspect existing workspace keys before creating one. A new key's secret appears once at creation. Keys expire after 365 days unless --expires-at is earlier. API-key management requires your own signed-in identity and cannot use RZV_API_KEY. Terminal · inspect API keys and permission options ``` rzv api-keys list rzv help api-keys ``` ## Create or revoke an API key Use --permissions \ for fine-grained permissions, or --scopes \ for scopes. Give the key only the access your script needs. Save its secret securely when it is returned; do not put it in source code or support messages. Terminal · replace permission, name and key placeholders ``` rzv api-keys create --name "" --permissions --idempotency-key rzv api-keys rename --name "" rzv api-keys revoke ``` ## Use an API key in a script Supply RZV_API_KEY through your script or CI secret store. Pass --workspace \ or set RZV_WORKSPACE to the workspace ID; a key cannot look up slugs. Never paste a key's secret into these examples. Commands requiring your own sign-in refuse RZV_API_KEY: whoami; workspace list, select and create; invitation acceptance; API-key management; notifications; personal tickets; GitHub linking; AI provider changes; and AI settings updates. Terminal · with RZV_API_KEY already set securely ``` rzv jobs list --workspace --json ``` ## Notifications, activity and support Notifications need your own sign-in. Read the inbox and its delivery settings, inspect workspace activity, or list support tickets. Add --personal for tickets outside a workspace. Notification commands also mark messages read and update in-app or email delivery. Activity supports CSV export and audit status. Ticket commands open, show, reply to and close tickets; use command help for their required arguments. AI providers, settings and usage commands manage workspace AI connections. Pipelines and AI Fix appear only when enabled for your workspace. Terminal · notifications, activity and support ``` rzv notifications list rzv notifications settings show rzv activity list rzv activity status rzv tickets list rzv help tickets rzv help ai ``` [Notification settings guide](https://runzivo.dev/docs/notifications/) [Redeem a promo code or voucher](https://runzivo.dev/docs/redeem-a-code/) On this page and page tools --- Source: https://runzivo.dev/docs/sign-in/ # Sign-in and sessions Sign in to the portal or CLI, choose a workspace, and understand the portal's session limits. ## 1. Sign in to the portal Open the customer portal and sign in with GitHub. Choose a workspace you belong to before opening its jobs, settings or sandboxes. The session limits below apply to the portal. [Open the customer portal](https://app.runzivo.dev/) ## 2. Sign in from the CLI The CLI uses a separate local sign-in. It opens your browser at id.runzivo.dev; complete sign-in with the same GitHub identity. Check the result with whoami. When the CLI's short-lived access token expires, run login again; the portal's 14-day and 30-day limits do not describe the CLI token. Terminal · sign in and check your identity ``` rzv login rzv whoami ``` [Install the rzv CLI first](https://runzivo.dev/docs/cli/) ## 3. Choose a CLI workspace List your workspaces, replace \ with an ID or slug from the list, and select it. whoami shows the selection saved for later commands. Use --workspace \ to choose a workspace for one command without changing that default. Terminal · replace \ before running ``` rzv workspaces list rzv workspaces select rzv whoami ``` ## How long you stay signed in After you sign in to the customer portal, you stay signed in for 14 days without activity, and for 30 days at most. After 30 days you sign in again, even if you have been active. Your sign-in survives browser restarts. Only your own activity, such as opening pages or taking actions, keeps the session alive. Background refreshes in an open tab do not. ## How the session is stored Your browser holds only an opaque session cookie. Sign-in tokens are not stored in your browser. The portal renews short-lived access tokens on the server. [Read the privacy notice](https://runzivo.dev/legal/privacy/) ## What ends a session - Signing out ends that session immediately. - If an account is suspended, all of its sessions end immediately. - If Runzivo staff sign an account out everywhere, all of its sessions end immediately. - A session also ends after 14 days without activity or 30 days after sign-in, whichever comes first. ## Confirm it's you If you have not signed in within the last 15 minutes, the portal asks you to confirm it's you before a sensitive action: - Billing changes, when paid billing is enabled: payment method, purchases, auto-recharge, and billing country. - Creating, rotating, or deleting an API key. - Account security settings: linked identities, sessions, account deletion, and owner role changes. ## Staff sessions Runzivo staff sessions use shorter limits than customer sessions. On this page and page tools --- Source: https://runzivo.dev/docs/workspace-permissions/ # Workspace permissions Choose workspace access that keeps billing data visible only to the right people. ## View billing Billing balances, credit minutes, purchases and other billing data require the View billing permission. The Member and Viewer presets do not include it. Without View billing, the portal hides billing data, including billing details in AI chat. This does not change a member's access to non-billing workspace information. ## Managing access Use Settings \> Members & Teams to review roles and permissions. A person can receive View billing through a workspace role or team that grants the permission. Billing changes need additional permissions. Giving View billing does not grant permission to change billing settings or make purchases. On this page and page tools --- Source: https://runzivo.dev/docs/demos/ # Demos Illustrative sandbox walkthroughs and copyable runner workflows. ## CI Runners [GitHub Actions runner templates Install the Runzivo GitHub App, select a private repository owned by a GitHub organization, then use the selected template's published runner label.](https://runzivo.dev/docs/runner-templates/) ## Agent Sandboxes [Sandbox lifecycle illustration](https://runzivo.dev/docs/demos/#sandbox-lifecycle) ## Sandbox lifecycle illustration Create a sandbox, run a command, inspect the result, then stop or delete it. This illustration shows the sequence; it is not a recording of a live sandbox. Run the commands one at a time. After create, copy the returned sandbox ID into each placeholder. Use list to wait until its status is running before exec. Inspect the command output and sandbox status, then stop or delete it. Your browser does not support embedded video. Read the copyable lifecycle commands below. Illustrative animation with placeholder IDs. Use the sandbox ID returned in your own workspace. Terminal · illustrative lifecycle ``` rzv sandboxes create --name docs-example --size 2vcpu-8gb rzv sandboxes list rzv sandboxes exec -- pwd rzv sandboxes get rzv sandboxes stop rzv sandboxes delete ``` [Follow the sandbox quickstart](https://runzivo.dev/docs/sandboxes-quickstart/) ## Runner workflow example Illustrative GitHub Actions workflow using a published Runzivo runner label. Install the GitHub App and authorize your repository before running it. 01-nodejs.yml ```yaml name: Node.js on: push: branches: [main] pull_request: workflow_dispatch: permissions: contents: read concurrency: group: nodejs-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: test: runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb timeout-minutes: 15 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0 with: node-version: 24 cache: npm cache-dependency-path: package-lock.json - run: npm ci - run: npm test - run: npm run build ``` [Browse all runner workflow templates](https://runzivo.dev/docs/runner-templates/) Page tools [View as Markdown](https://runzivo.dev/docs/demos.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Fdemos.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Fdemos.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Fdemos.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. --- Source: https://runzivo.dev/docs/guides/ # Guides Step-by-step setup for CI runners, sandboxes and your workspace. ## CI Runners [Getting started Sign in with GitHub, connect an organization, and run an eligible GitHub Actions job.](https://runzivo.dev/docs/getting-started/) [Set up Runzivo with your AI coding agent Copy a prompt that gives an AI coding agent the Runzivo instructions for a small workflow change.](https://runzivo.dev/docs/ai-coding-agent/) [Install the GitHub App Connect a GitHub organization and selected repository to Runzivo.](https://runzivo.dev/docs/github-app/) [Configuration, environments, and secrets Keep GitHub Actions workflow configuration in GitHub and make the smallest runner-label change first.](https://runzivo.dev/docs/configuration/) [Docker layer cache for CI Coming soon. Docker layer caching is in development and is not available yet.](https://runzivo.dev/docs/docker-layer-cache/) [Plan a Buildx cache step Coming soon. Planned worked example, not available yet in production.](https://runzivo.dev/docs/docker-layer-cache-example/) ## Agent Sandboxes [Create your first sandbox Create a Linux sandbox, write and inspect a file, then stop and delete it. Use the CLI walkthrough or the API and portal alternatives below.](https://runzivo.dev/docs/sandboxes-quickstart/) [Sandbox terminal and commands Run a command and inspect its result, pass arguments or a shell script, or open an interactive terminal in a running sandbox.](https://runzivo.dev/docs/sandboxes-terminal/) [Connect with SSH, scp, sftp and rsync Coming soon. Standard SSH access and editor connections are not available yet.](https://runzivo.dev/docs/sandboxes-ssh/) [The sandbox developer image Coming soon. The developer image is not available yet. Its planned tools will be signed out.](https://runzivo.dev/docs/sandboxes-developer-image/) [Persistent disks for sandboxes Coming soon. Host-local persistent disks are in development and are not available yet.](https://runzivo.dev/docs/sandboxes-persistent-disks/) [Repository access in a sandbox Coming soon. Repository tokens are not available in production yet. Automatic private-repository login is not available yet.](https://runzivo.dev/docs/sandboxes-repositories/) [OpenHands tasks in a sandbox Coming soon. OpenHands tasks are in development and not yet tested in a live sandbox. They are not available yet.](https://runzivo.dev/docs/sandboxes-openhands/) [Develop with an editor and agent Coming soon. Planned worked example, not available yet in production.](https://runzivo.dev/docs/sandboxes-devx-example-editor/) [Request private-repository access safely Coming soon. Planned worked example, not available yet in production.](https://runzivo.dev/docs/sandboxes-devx-example-repository/) [Transfer a project with rsync Coming soon. Planned worked example, not available yet in production.](https://runzivo.dev/docs/sandboxes-devx-example-rsync/) ## Workspace & CLI [Redeem a code Add credit to a workspace with a promo code or prepaid voucher.](https://runzivo.dev/docs/redeem-a-code/) [Install the rzv CLI Install the rzv command-line tool, sign in, and choose a workspace.](https://runzivo.dev/docs/cli/) [Sign-in and sessions Sign in to the portal or CLI, choose a workspace, and understand the portal's session limits.](https://runzivo.dev/docs/sign-in/) [Troubleshooting Check authorization and the runner label before changing workflow code.](https://runzivo.dev/docs/troubleshooting/) Page tools [View as Markdown](https://runzivo.dev/docs/guides.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Fguides.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Fguides.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Fguides.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. --- Source: https://runzivo.dev/docs/platform/ # Platform Understand compute, limits, billing and workspace controls. ## CI Runners [GitHub App permissions The permissions Runzivo requests, what they support, and the controls customers retain.](https://runzivo.dev/docs/github-app-permissions/) [Linux x64 runners Run eligible GitHub Actions jobs on available Linux x64 runners.](https://runzivo.dev/docs/runners/) [Insights See job counts, recorded minutes, duration, queue wait and the slowest workflows for a workspace.](https://runzivo.dev/docs/insights/) ## Agent Sandboxes [Agent Sandboxes Isolated Linux microVMs where a workspace runs commands and opens a terminal, for up to eight hours.](https://runzivo.dev/docs/sandboxes/) [Sandbox limits and billing Sizes, lifetime, running and session limits, and how sandbox compute is billed.](https://runzivo.dev/docs/sandboxes-limits/) ## Workspace & CLI [Usage and limits Early Access is controlled so Runzivo can validate reliability, isolation, and capacity with real workloads.](https://runzivo.dev/docs/usage-limits/) [Team and Business plans Subscribe to Team or Business, and what happens at renewal, after a failed payment and when a plan is cancelled.](https://runzivo.dev/docs/plans/) [Notifications Read workspace notifications in the portal and choose which categories also reach you by email.](https://runzivo.dev/docs/notifications/) [Workspace permissions Choose workspace access that keeps billing data visible only to the right people.](https://runzivo.dev/docs/workspace-permissions/) Page tools [View as Markdown](https://runzivo.dev/docs/platform.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Fplatform.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Fplatform.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Fplatform.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. --- Source: https://runzivo.dev/docs/reference/ # Reference Look up CLI commands and the Sandbox customer API. ## Customer API Base URL: `https://api.runzivo.dev`. The reference covers the nine published Agent Sandbox operations. CLI commands for runners, sandboxes and workspaces are documented separately. Send a customer access token or workspace API key in `Authorization: Bearer `. Sandbox key permissions are `sandboxes:read` and `sandboxes:write`, not legacy scopes. Keys remain limited by their creator's current workspace permissions. Set TENANT_ID to your workspace ID. Supply RUNZIVO_TOKEN securely in your own client environment: a customer access token or workspace API key. Examples contain placeholders, not credentials or live account data. Run requests in your own client; this website does not execute them. cURL · illustrative authenticated request ``` curl "https://api.runzivo.dev/v1/customer/tenants/${TENANT_ID}/sandboxes" \ --header "Authorization: Bearer ${RUNZIVO_TOKEN}" ``` ## Agent Sandboxes [Upcoming sandbox API endpoints Coming soon. Planned API contract, subject to change. These API features are not available yet.](https://runzivo.dev/docs/sandboxes-devx-api/) [SSH host, ticket and relay Coming soon. Planned API contract, subject to change. These features are not available yet in production.](https://runzivo.dev/docs/sandboxes-devx-api-ssh/) [Repository token request Coming soon. Planned API contract, subject to change. These features are not available yet in production.](https://runzivo.dev/docs/sandboxes-devx-api-repository-token/) [OpenHands server lifecycle Coming soon. Planned API contract, subject to change. These features are not available yet in production.](https://runzivo.dev/docs/sandboxes-devx-api-agent-server/) [OpenHands task requests Coming soon. Planned API contract, subject to change. These features are not available yet in production.](https://runzivo.dev/docs/sandboxes-devx-api-agent-tasks/) [OpenHands task controls and events Coming soon. Planned API contract, subject to change. These features are not available yet in production.](https://runzivo.dev/docs/sandboxes-devx-api-agent-controls/) [Sandbox API reference Create, list, read, start, stop and delete sandboxes through the customer API.](https://runzivo.dev/docs/sandboxes-api/) [Exec and terminal API reference Run a command with streamed output, or open the sandbox terminal as a WebSocket. Both need a running sandbox and a token that can change sandboxes.](https://runzivo.dev/docs/sandboxes-api-exec/) [GET List sandboxes List your workspace's sandboxes, newest first, with offered sizes and the running limit.](https://runzivo.dev/docs/reference/sandboxes/list/) [POST Create a sandbox Create a sandbox and request its first start.](https://runzivo.dev/docs/reference/sandboxes/create/) [GET Get a sandbox Read a sandbox's current status, lifetime and compute usage.](https://runzivo.dev/docs/reference/sandboxes/get/) [DELETE Delete a sandbox Stop the VM and permanently remove its workspace disk and files.](https://runzivo.dev/docs/reference/sandboxes/delete/) [POST Start a sandbox Start a stopped or failed sandbox without resetting its original expiry.](https://runzivo.dev/docs/reference/sandboxes/start/) [POST Stop a sandbox Stop a running sandbox while keeping its files.](https://runzivo.dev/docs/reference/sandboxes/stop/) [POST Run a command Run bash -lc in a running sandbox and stream stdout, stderr and the exit result.](https://runzivo.dev/docs/reference/sandboxes/exec/) [POST Create a terminal ticket Issue a single-use ticket so a browser can open the terminal without an Authorization header.](https://runzivo.dev/docs/reference/sandboxes/terminal-ticket/) [GET Open a terminal Upgrade to a WebSocket for a running sandbox's interactive terminal.](https://runzivo.dev/docs/reference/sandboxes/terminal/) ## Workspace & CLI [rzv command reference The commands in rzv 0.21.0, grouped by what they act on. Every command accepts --help, and every command except rzv sandboxes ssh accepts --json.](https://runzivo.dev/docs/cli-commands/) Page tools [View as Markdown](https://runzivo.dev/docs/reference.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. --- Source: https://runzivo.dev/docs/reference/sandboxes/create/ # Create a sandbox Create a sandbox and request its first start. POST `/v1/customer/tenants/{tenantId}/sandboxes` Base URL: `https://api.runzivo.dev` ## Authentication Send `Authorization: Bearer ` with a customer access token or workspace API key. API key permission: `sandboxes:write`. These are permissions, not legacy scopes. A key with the `all:all` scope also works, limited by its creator's current workspace permissions. ## Parameters | Field | Description | | --- | --- | | `tenantId` string · path Required | Your workspace's tenant ID. Replace the placeholder with an ID your token can access. | ## Request body Send `Content-Type: application/json`. | Field | Description | | --- | --- | | `name` string Required | 1–80 characters after trimming. A live sandbox name must be unique in the workspace. | | `size` string Required | 2vcpu-8gb, 4vcpu-16gb, 8vcpu-32gb or 16vcpu-64gb. Choose a size from the list response's sizes field. | | `disk_gib` integer Optional | 5–64 GiB; default 20. | | `client_operation_id` string Optional | 8–200 characters. Reusing this value returns the sandbox first created for it. | ## Behavior and limits - Send application/json. Request body limit: 4 KiB. Unknown JSON fields are rejected. - A successful request returns 201 and a bare Sandbox object. Poll its status; a response is not proof that the VM is ready. - Conflicts include sandbox_limit_reached, credit_exhausted, sandbox_name_taken, size_unavailable and workspace_blocked. The eight-hour lifetime runs from the first start, not from the browser or CLI opening. ## Responses | Status | Meaning | | --- | --- | | 201 Created | application/json | | 400 Invalid request | Malformed JSON, unknown fields or invalid values. Terminal upgrades also reject malformed handshakes. | | 401 Unauthorized | Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. | | 403 Forbidden | The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. | | 409 Conflict | Creation was refused by the workspace limit, credit, name, size or workspace controls. Codes include sandbox_limit_reached, credit_exhausted, sandbox_name_taken, size_unavailable and workspace_blocked. | | 500 Internal error | The server could not complete the request. | | 503 Unavailable | Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. | Examples use synthetic IDs, dates and values. Read the actual response and status in your workspace. ## Sandbox response fields Success returns a Sandbox object directly, with these fields. | Field | Description | | --- | --- | | `id` string Required | Sandbox ID: sbx\_ followed by 24 lowercase hexadecimal characters. | | `name` string Required | Workspace sandbox name. | | `size` string Required | The selected size identifier. | | `disk_gib` integer Required | Workspace disk size in GiB. | | `status` string Required | pending, starting, running, stopping, stopped, deleting, deleted, expired or failed. | | `error` object \| null Required | null, or {code, message} explaining a failed sandbox. | | `created_at` date-time Required | When the sandbox was created. | | `started_at` date-time \| null Required | First start; null until it starts. | | `expires_at` date-time \| null Required | First start plus eight hours. Stopping does not pause the lifetime. | | `remaining_seconds` integer Required | Lifetime left; 28800 before first start, 0 once expired or deleted. | | `runtime_seconds` integer Required | Seconds the VM has been up; excludes stopped time. | | `credits_used` number Required | Unit-minutes charged at the size's multiplier. | [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) Page tools [View as Markdown](https://runzivo.dev/docs/reference/sandboxes/create.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fcreate.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fcreate.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fcreate.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. ## Request example Illustrative request. Set RUNZIVO_TOKEN and TENANT_ID in your shell. Replace placeholders with your own values. This page does not send requests. cURL ``` curl --request POST \ "https://api.runzivo.dev/v1/customer/tenants/${TENANT_ID}/sandboxes" \ --header "Authorization: Bearer ${RUNZIVO_TOKEN}" \ --header "Content-Type: application/json" \ --data '{ "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "client_operation_id": "docs-create-example-01" }' ``` ## Response example application/json · Illustrative response; values and timing vary in your workspace. 201 · application/json ``` { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "pending", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": null, "expires_at": null, "remaining_seconds": 28800, "runtime_seconds": 0, "credits_used": 0 } ``` All response examples (also available without JavaScript) ### 201 Created Illustrative response; values and timing vary in your workspace. application/json ``` { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "pending", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": null, "expires_at": null, "remaining_seconds": 28800, "runtime_seconds": 0, "credits_used": 0 } ``` ### 400 Invalid request Malformed JSON, unknown fields or invalid values. Terminal upgrades also reject malformed handshakes. application/json ``` { "error": { "code": "invalid_request" } } ``` ### 401 Unauthorized Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. application/json ``` { "error": { "code": "unauthorized" } } ``` ### 403 Forbidden The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. application/json ``` { "error": { "code": "permission_required" } } ``` ### 409 Conflict Creation was refused by the workspace limit, credit, name, size or workspace controls. Codes include sandbox_limit_reached, credit_exhausted, sandbox_name_taken, size_unavailable and workspace_blocked. application/json ``` { "error": { "code": "sandbox_limit_reached" } } ``` ### 500 Internal error The server could not complete the request. application/json ``` { "error": { "code": "internal_error" } } ``` ### 503 Unavailable Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. application/json ``` { "error": { "code": "sandboxes_unavailable" } } ``` --- Source: https://runzivo.dev/docs/reference/sandboxes/delete/ # Delete a sandbox Stop the VM and permanently remove its workspace disk and files. DELETE `/v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}` Base URL: `https://api.runzivo.dev` ## Authentication Send `Authorization: Bearer ` with a customer access token or workspace API key. API key permission: `sandboxes:write`. These are permissions, not legacy scopes. A key with the `all:all` scope also works, limited by its creator's current workspace permissions. ## Parameters | Field | Description | | --- | --- | | `tenantId` string · path Required | Your workspace's tenant ID. Replace the placeholder with an ID your token can access. | | `sandboxId` string · path Required | The id returned when the sandbox was created: sbx\_ followed by 24 lowercase hexadecimal characters. | ## Request body No request body is required. ## Behavior and limits - Files cannot be recovered. Compute stops being charged when the VM stops. - Returns 200 with a Sandbox object, not 204. Repeating a delete is a no-op; the returned status can already be deleted. ## Responses | Status | Meaning | | --- | --- | | 200 OK | application/json | | 401 Unauthorized | Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. | | 403 Forbidden | The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. | | 404 Not found | No sandbox with this ID exists in the authorized workspace. | | 500 Internal error | The server could not complete the request. | | 503 Unavailable | Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. | Examples use synthetic IDs, dates and values. Read the actual response and status in your workspace. ## Sandbox response fields Success returns a Sandbox object directly, with these fields. | Field | Description | | --- | --- | | `id` string Required | Sandbox ID: sbx\_ followed by 24 lowercase hexadecimal characters. | | `name` string Required | Workspace sandbox name. | | `size` string Required | The selected size identifier. | | `disk_gib` integer Required | Workspace disk size in GiB. | | `status` string Required | pending, starting, running, stopping, stopped, deleting, deleted, expired or failed. | | `error` object \| null Required | null, or {code, message} explaining a failed sandbox. | | `created_at` date-time Required | When the sandbox was created. | | `started_at` date-time \| null Required | First start; null until it starts. | | `expires_at` date-time \| null Required | First start plus eight hours. Stopping does not pause the lifetime. | | `remaining_seconds` integer Required | Lifetime left; 28800 before first start, 0 once expired or deleted. | | `runtime_seconds` integer Required | Seconds the VM has been up; excludes stopped time. | | `credits_used` number Required | Unit-minutes charged at the size's multiplier. | [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) Page tools [View as Markdown](https://runzivo.dev/docs/reference/sandboxes/delete.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fdelete.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fdelete.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fdelete.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. ## Request example Illustrative request. Set RUNZIVO_TOKEN and TENANT_ID, and SANDBOX_ID in your shell. Replace placeholders with your own values. This page does not send requests. cURL ``` curl --request DELETE \ "https://api.runzivo.dev/v1/customer/tenants/${TENANT_ID}/sandboxes/${SANDBOX_ID}" \ --header "Authorization: Bearer ${RUNZIVO_TOKEN}" ``` ## Response example application/json · Illustrative response; values and timing vary in your workspace. 200 · application/json ``` { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "deleting", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": "2026-10-31T12:00:00Z", "expires_at": "2026-10-31T20:00:00Z", "remaining_seconds": 28740, "runtime_seconds": 60, "credits_used": 1 } ``` All response examples (also available without JavaScript) ### 200 OK Illustrative response; values and timing vary in your workspace. application/json ``` { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "deleting", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": "2026-10-31T12:00:00Z", "expires_at": "2026-10-31T20:00:00Z", "remaining_seconds": 28740, "runtime_seconds": 60, "credits_used": 1 } ``` ### 401 Unauthorized Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. application/json ``` { "error": { "code": "unauthorized" } } ``` ### 403 Forbidden The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. application/json ``` { "error": { "code": "permission_required" } } ``` ### 404 Not found No sandbox with this ID exists in the authorized workspace. application/json ``` { "error": { "code": "sandbox_not_found" } } ``` ### 500 Internal error The server could not complete the request. application/json ``` { "error": { "code": "internal_error" } } ``` ### 503 Unavailable Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. application/json ``` { "error": { "code": "sandboxes_unavailable" } } ``` --- Source: https://runzivo.dev/docs/reference/sandboxes/exec/ # Run a command Run bash -lc in a running sandbox and stream stdout, stderr and the exit result. POST `/v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}/exec` Base URL: `https://api.runzivo.dev` ## Authentication Send `Authorization: Bearer ` with a customer access token or workspace API key. API key permission: `sandboxes:write`. These are permissions, not legacy scopes. A key with the `all:all` scope also works, limited by its creator's current workspace permissions. ## Parameters | Field | Description | | --- | --- | | `tenantId` string · path Required | Your workspace's tenant ID. Replace the placeholder with an ID your token can access. | | `sandboxId` string · path Required | The id returned when the sandbox was created: sbx\_ followed by 24 lowercase hexadecimal characters. | ## Request body Send `Content-Type: application/json`. | Field | Description | | --- | --- | | `cmd` string Required | Nonblank shell command, at most 64 KiB; no NUL bytes. Runs as bash -lc. | | `cwd` string Optional | Absolute working directory; default /workspace. Published schema maximum: 1024 characters. | | `env` object Optional | Up to 64 environment variables. Names match ^\[A-Za-z_\]\[A-Za-z0-9_\]{0,127}$; values at most 8192 bytes, without NUL. | | `timeout_seconds` integer Optional | 1–3600 seconds; default 300 when omitted. | ## Behavior and limits - Send application/json; request body limit 128 KiB. Up to four concurrent commands per sandbox; otherwise 409 session_limit_reached. - Each stdout/stderr line has base64 data. The final exit line has exit_code, timed_out and truncated; reason appears when the sandbox stopped, expired or was deleted. - Disconnecting cancels the command. Output is capped at 8 MiB. A timed-out command still running 30 seconds past its timeout is cancelled with exit code 124; truncation ends with code 137. ## Responses | Status | Meaning | | --- | --- | | 200 Stream opened | application/x-ndjson | | 400 Invalid request | Malformed JSON, unknown fields or invalid values. Terminal upgrades also reject malformed handshakes. | | 401 Unauthorized | Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. | | 403 Forbidden | The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. | | 404 Not found | No sandbox with this ID exists in the authorized workspace. | | 409 Conflict | The operation is not allowed in the current sandbox state. See the operation notes for other possible conflict codes. | | 500 Internal error | The server could not complete the request. | | 503 Unavailable | Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. | Examples use synthetic IDs, dates and values. Read the actual response and status in your workspace. [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) Page tools [View as Markdown](https://runzivo.dev/docs/reference/sandboxes/exec.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fexec.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fexec.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fexec.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. ## Request example Illustrative request. Set RUNZIVO_TOKEN and TENANT_ID, and SANDBOX_ID in your shell. Replace placeholders with your own values. This page does not send requests. cURL ``` curl --no-buffer --request POST \ "https://api.runzivo.dev/v1/customer/tenants/${TENANT_ID}/sandboxes/${SANDBOX_ID}/exec" \ --header "Authorization: Bearer ${RUNZIVO_TOKEN}" \ --header "Content-Type: application/json" \ --data '{ "cmd": "printf '"'"'hello\\n'"'"'", "cwd": "/workspace", "timeout_seconds": 300 }' ``` ## Response example application/x-ndjson · Illustrative stream. Decode each output chunk's data from base64. These are separate lines, not a JSON array. 200 · application/x-ndjson ``` {"type":"stdout","data":"aGVsbG8K"} {"type":"exit","exit_code":0,"timed_out":false,"truncated":false} ``` All response examples (also available without JavaScript) ### 200 Stream opened Illustrative stream. Decode each output chunk's data from base64. These are separate lines, not a JSON array. application/x-ndjson ``` {"type":"stdout","data":"aGVsbG8K"} {"type":"exit","exit_code":0,"timed_out":false,"truncated":false} ``` ### 400 Invalid request Malformed JSON, unknown fields or invalid values. Terminal upgrades also reject malformed handshakes. application/json ``` { "error": { "code": "invalid_request" } } ``` ### 401 Unauthorized Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. application/json ``` { "error": { "code": "unauthorized" } } ``` ### 403 Forbidden The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. application/json ``` { "error": { "code": "permission_required" } } ``` ### 404 Not found No sandbox with this ID exists in the authorized workspace. application/json ``` { "error": { "code": "sandbox_not_found" } } ``` ### 409 Conflict The operation is not allowed in the current sandbox state. See the operation notes for other possible conflict codes. application/json ``` { "error": { "code": "sandbox_wrong_state" } } ``` ### 500 Internal error The server could not complete the request. application/json ``` { "error": { "code": "internal_error" } } ``` ### 503 Unavailable Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. application/json ``` { "error": { "code": "sandboxes_unavailable" } } ``` --- Source: https://runzivo.dev/docs/reference/sandboxes/get/ # Get a sandbox Read a sandbox's current status, lifetime and compute usage. GET `/v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}` Base URL: `https://api.runzivo.dev` ## Authentication Send `Authorization: Bearer ` with a customer access token or workspace API key. API key permission: `sandboxes:read` or `sandboxes:write`. These are permissions, not legacy scopes. A key with the `all:all` scope also works, limited by its creator's current workspace permissions. ## Parameters | Field | Description | | --- | --- | | `tenantId` string · path Required | Your workspace's tenant ID. Replace the placeholder with an ID your token can access. | | `sandboxId` string · path Required | The id returned when the sandbox was created: sbx\_ followed by 24 lowercase hexadecimal characters. | ## Request body No request body is required. ## Responses | Status | Meaning | | --- | --- | | 200 OK | application/json | | 401 Unauthorized | Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. | | 403 Forbidden | The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. | | 404 Not found | No sandbox with this ID exists in the authorized workspace. | | 500 Internal error | The server could not complete the request. | | 503 Unavailable | Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. | Examples use synthetic IDs, dates and values. Read the actual response and status in your workspace. ## Sandbox response fields Success returns a Sandbox object directly, with these fields. | Field | Description | | --- | --- | | `id` string Required | Sandbox ID: sbx\_ followed by 24 lowercase hexadecimal characters. | | `name` string Required | Workspace sandbox name. | | `size` string Required | The selected size identifier. | | `disk_gib` integer Required | Workspace disk size in GiB. | | `status` string Required | pending, starting, running, stopping, stopped, deleting, deleted, expired or failed. | | `error` object \| null Required | null, or {code, message} explaining a failed sandbox. | | `created_at` date-time Required | When the sandbox was created. | | `started_at` date-time \| null Required | First start; null until it starts. | | `expires_at` date-time \| null Required | First start plus eight hours. Stopping does not pause the lifetime. | | `remaining_seconds` integer Required | Lifetime left; 28800 before first start, 0 once expired or deleted. | | `runtime_seconds` integer Required | Seconds the VM has been up; excludes stopped time. | | `credits_used` number Required | Unit-minutes charged at the size's multiplier. | [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) Page tools [View as Markdown](https://runzivo.dev/docs/reference/sandboxes/get.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fget.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fget.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fget.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. ## Request example Illustrative request. Set RUNZIVO_TOKEN and TENANT_ID, and SANDBOX_ID in your shell. Replace placeholders with your own values. This page does not send requests. cURL ``` curl --request GET \ "https://api.runzivo.dev/v1/customer/tenants/${TENANT_ID}/sandboxes/${SANDBOX_ID}" \ --header "Authorization: Bearer ${RUNZIVO_TOKEN}" ``` ## Response example application/json · Illustrative response; values and timing vary in your workspace. 200 · application/json ``` { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "running", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": "2026-10-31T12:00:00Z", "expires_at": "2026-10-31T20:00:00Z", "remaining_seconds": 28740, "runtime_seconds": 60, "credits_used": 1 } ``` All response examples (also available without JavaScript) ### 200 OK Illustrative response; values and timing vary in your workspace. application/json ``` { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "running", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": "2026-10-31T12:00:00Z", "expires_at": "2026-10-31T20:00:00Z", "remaining_seconds": 28740, "runtime_seconds": 60, "credits_used": 1 } ``` ### 401 Unauthorized Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. application/json ``` { "error": { "code": "unauthorized" } } ``` ### 403 Forbidden The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. application/json ``` { "error": { "code": "permission_required" } } ``` ### 404 Not found No sandbox with this ID exists in the authorized workspace. application/json ``` { "error": { "code": "sandbox_not_found" } } ``` ### 500 Internal error The server could not complete the request. application/json ``` { "error": { "code": "internal_error" } } ``` ### 503 Unavailable Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. application/json ``` { "error": { "code": "sandboxes_unavailable" } } ``` --- Source: https://runzivo.dev/docs/reference/sandboxes/list/ # List sandboxes List your workspace's sandboxes, newest first, with offered sizes and the running limit. GET `/v1/customer/tenants/{tenantId}/sandboxes` Base URL: `https://api.runzivo.dev` ## Authentication Send `Authorization: Bearer ` with a customer access token or workspace API key. API key permission: `sandboxes:read` or `sandboxes:write`. These are permissions, not legacy scopes. A key with the `all:all` scope also works, limited by its creator's current workspace permissions. ## Parameters | Field | Description | | --- | --- | | `tenantId` string · path Required | Your workspace's tenant ID. Replace the placeholder with an ID your token can access. | ## Request body No request body is required. ## Behavior and limits - No pagination or query parameters. The response contains sandboxes, sizes and max_running as siblings, not a nested data or items envelope. - Use the sizes returned for this environment when creating a sandbox. A size being offered does not guarantee immediate free capacity. ## Responses | Status | Meaning | | --- | --- | | 200 OK | application/json | | 401 Unauthorized | Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. | | 403 Forbidden | The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. | | 500 Internal error | The server could not complete the request. | | 503 Unavailable | Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. | Examples use synthetic IDs, dates and values. Read the actual response and status in your workspace. ## Sandbox response fields The list response has `sandboxes` (an array of the objects below), `sizes` (offered size IDs) and `max_running` (the workspace running limit). | Field | Description | | --- | --- | | `id` string Required | Sandbox ID: sbx\_ followed by 24 lowercase hexadecimal characters. | | `name` string Required | Workspace sandbox name. | | `size` string Required | The selected size identifier. | | `disk_gib` integer Required | Workspace disk size in GiB. | | `status` string Required | pending, starting, running, stopping, stopped, deleting, deleted, expired or failed. | | `error` object \| null Required | null, or {code, message} explaining a failed sandbox. | | `created_at` date-time Required | When the sandbox was created. | | `started_at` date-time \| null Required | First start; null until it starts. | | `expires_at` date-time \| null Required | First start plus eight hours. Stopping does not pause the lifetime. | | `remaining_seconds` integer Required | Lifetime left; 28800 before first start, 0 once expired or deleted. | | `runtime_seconds` integer Required | Seconds the VM has been up; excludes stopped time. | | `credits_used` number Required | Unit-minutes charged at the size's multiplier. | [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) Page tools [View as Markdown](https://runzivo.dev/docs/reference/sandboxes/list.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Flist.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Flist.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Flist.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. ## Request example Illustrative request. Set RUNZIVO_TOKEN and TENANT_ID in your shell. Replace placeholders with your own values. This page does not send requests. cURL ``` curl --request GET \ "https://api.runzivo.dev/v1/customer/tenants/${TENANT_ID}/sandboxes" \ --header "Authorization: Bearer ${RUNZIVO_TOKEN}" ``` ## Response example application/json · Illustrative response; values and timing vary in your workspace. 200 · application/json ``` { "sandboxes": [ { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "running", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": "2026-10-31T12:00:00Z", "expires_at": "2026-10-31T20:00:00Z", "remaining_seconds": 28740, "runtime_seconds": 60, "credits_used": 1 } ], "max_running": 2, "sizes": [ "2vcpu-8gb", "4vcpu-16gb" ] } ``` All response examples (also available without JavaScript) ### 200 OK Illustrative response; values and timing vary in your workspace. application/json ``` { "sandboxes": [ { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "running", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": "2026-10-31T12:00:00Z", "expires_at": "2026-10-31T20:00:00Z", "remaining_seconds": 28740, "runtime_seconds": 60, "credits_used": 1 } ], "max_running": 2, "sizes": [ "2vcpu-8gb", "4vcpu-16gb" ] } ``` ### 401 Unauthorized Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. application/json ``` { "error": { "code": "unauthorized" } } ``` ### 403 Forbidden The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. application/json ``` { "error": { "code": "permission_required" } } ``` ### 500 Internal error The server could not complete the request. application/json ``` { "error": { "code": "internal_error" } } ``` ### 503 Unavailable Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. application/json ``` { "error": { "code": "sandboxes_unavailable" } } ``` --- Source: https://runzivo.dev/docs/reference/sandboxes/start/ # Start a sandbox Start a stopped or failed sandbox without resetting its original expiry. POST `/v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}/start` Base URL: `https://api.runzivo.dev` ## Authentication Send `Authorization: Bearer ` with a customer access token or workspace API key. API key permission: `sandboxes:write`. These are permissions, not legacy scopes. A key with the `all:all` scope also works, limited by its creator's current workspace permissions. ## Parameters | Field | Description | | --- | --- | | `tenantId` string · path Required | Your workspace's tenant ID. Replace the placeholder with an ID your token can access. | | `sandboxId` string · path Required | The id returned when the sandbox was created: sbx\_ followed by 24 lowercase hexadecimal characters. | ## Request body No request body is required. ## Behavior and limits - Conflicts include sandbox_expired, sandbox_wrong_state, sandbox_limit_reached, credit_exhausted, size_unavailable and workspace_blocked. A start returns a status transition, not a ready terminal. ## Responses | Status | Meaning | | --- | --- | | 200 OK | application/json | | 401 Unauthorized | Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. | | 403 Forbidden | The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. | | 404 Not found | No sandbox with this ID exists in the authorized workspace. | | 409 Conflict | The operation is not allowed in the current sandbox state. See the operation notes for other possible conflict codes. | | 500 Internal error | The server could not complete the request. | | 503 Unavailable | Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. | Examples use synthetic IDs, dates and values. Read the actual response and status in your workspace. ## Sandbox response fields Success returns a Sandbox object directly, with these fields. | Field | Description | | --- | --- | | `id` string Required | Sandbox ID: sbx\_ followed by 24 lowercase hexadecimal characters. | | `name` string Required | Workspace sandbox name. | | `size` string Required | The selected size identifier. | | `disk_gib` integer Required | Workspace disk size in GiB. | | `status` string Required | pending, starting, running, stopping, stopped, deleting, deleted, expired or failed. | | `error` object \| null Required | null, or {code, message} explaining a failed sandbox. | | `created_at` date-time Required | When the sandbox was created. | | `started_at` date-time \| null Required | First start; null until it starts. | | `expires_at` date-time \| null Required | First start plus eight hours. Stopping does not pause the lifetime. | | `remaining_seconds` integer Required | Lifetime left; 28800 before first start, 0 once expired or deleted. | | `runtime_seconds` integer Required | Seconds the VM has been up; excludes stopped time. | | `credits_used` number Required | Unit-minutes charged at the size's multiplier. | [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) Page tools [View as Markdown](https://runzivo.dev/docs/reference/sandboxes/start.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fstart.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fstart.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fstart.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. ## Request example Illustrative request. Set RUNZIVO_TOKEN and TENANT_ID, and SANDBOX_ID in your shell. Replace placeholders with your own values. This page does not send requests. cURL ``` curl --request POST \ "https://api.runzivo.dev/v1/customer/tenants/${TENANT_ID}/sandboxes/${SANDBOX_ID}/start" \ --header "Authorization: Bearer ${RUNZIVO_TOKEN}" ``` ## Response example application/json · Illustrative response; values and timing vary in your workspace. 200 · application/json ``` { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "starting", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": "2026-10-31T12:00:00Z", "expires_at": "2026-10-31T20:00:00Z", "remaining_seconds": 28740, "runtime_seconds": 60, "credits_used": 1 } ``` All response examples (also available without JavaScript) ### 200 OK Illustrative response; values and timing vary in your workspace. application/json ``` { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "starting", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": "2026-10-31T12:00:00Z", "expires_at": "2026-10-31T20:00:00Z", "remaining_seconds": 28740, "runtime_seconds": 60, "credits_used": 1 } ``` ### 401 Unauthorized Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. application/json ``` { "error": { "code": "unauthorized" } } ``` ### 403 Forbidden The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. application/json ``` { "error": { "code": "permission_required" } } ``` ### 404 Not found No sandbox with this ID exists in the authorized workspace. application/json ``` { "error": { "code": "sandbox_not_found" } } ``` ### 409 Conflict The operation is not allowed in the current sandbox state. See the operation notes for other possible conflict codes. application/json ``` { "error": { "code": "sandbox_wrong_state" } } ``` ### 500 Internal error The server could not complete the request. application/json ``` { "error": { "code": "internal_error" } } ``` ### 503 Unavailable Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. application/json ``` { "error": { "code": "sandboxes_unavailable" } } ``` --- Source: https://runzivo.dev/docs/reference/sandboxes/stop/ # Stop a sandbox Stop a running sandbox while keeping its files. POST `/v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}/stop` Base URL: `https://api.runzivo.dev` ## Authentication Send `Authorization: Bearer ` with a customer access token or workspace API key. API key permission: `sandboxes:write`. These are permissions, not legacy scopes. A key with the `all:all` scope also works, limited by its creator's current workspace permissions. ## Parameters | Field | Description | | --- | --- | | `tenantId` string · path Required | Your workspace's tenant ID. Replace the placeholder with an ID your token can access. | | `sandboxId` string · path Required | The id returned when the sandbox was created: sbx\_ followed by 24 lowercase hexadecimal characters. | ## Request body No request body is required. ## Behavior and limits - Compute stops being charged when the VM stops. Its eight-hour wall-clock lifetime continues while stopped. ## Responses | Status | Meaning | | --- | --- | | 200 OK | application/json | | 401 Unauthorized | Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. | | 403 Forbidden | The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. | | 404 Not found | No sandbox with this ID exists in the authorized workspace. | | 409 Conflict | The operation is not allowed in the current sandbox state. See the operation notes for other possible conflict codes. | | 500 Internal error | The server could not complete the request. | | 503 Unavailable | Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. | Examples use synthetic IDs, dates and values. Read the actual response and status in your workspace. ## Sandbox response fields Success returns a Sandbox object directly, with these fields. | Field | Description | | --- | --- | | `id` string Required | Sandbox ID: sbx\_ followed by 24 lowercase hexadecimal characters. | | `name` string Required | Workspace sandbox name. | | `size` string Required | The selected size identifier. | | `disk_gib` integer Required | Workspace disk size in GiB. | | `status` string Required | pending, starting, running, stopping, stopped, deleting, deleted, expired or failed. | | `error` object \| null Required | null, or {code, message} explaining a failed sandbox. | | `created_at` date-time Required | When the sandbox was created. | | `started_at` date-time \| null Required | First start; null until it starts. | | `expires_at` date-time \| null Required | First start plus eight hours. Stopping does not pause the lifetime. | | `remaining_seconds` integer Required | Lifetime left; 28800 before first start, 0 once expired or deleted. | | `runtime_seconds` integer Required | Seconds the VM has been up; excludes stopped time. | | `credits_used` number Required | Unit-minutes charged at the size's multiplier. | [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) Page tools [View as Markdown](https://runzivo.dev/docs/reference/sandboxes/stop.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fstop.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fstop.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fstop.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. ## Request example Illustrative request. Set RUNZIVO_TOKEN and TENANT_ID, and SANDBOX_ID in your shell. Replace placeholders with your own values. This page does not send requests. cURL ``` curl --request POST \ "https://api.runzivo.dev/v1/customer/tenants/${TENANT_ID}/sandboxes/${SANDBOX_ID}/stop" \ --header "Authorization: Bearer ${RUNZIVO_TOKEN}" ``` ## Response example application/json · Illustrative response; values and timing vary in your workspace. 200 · application/json ``` { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "stopping", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": "2026-10-31T12:00:00Z", "expires_at": "2026-10-31T20:00:00Z", "remaining_seconds": 28740, "runtime_seconds": 60, "credits_used": 1 } ``` All response examples (also available without JavaScript) ### 200 OK Illustrative response; values and timing vary in your workspace. application/json ``` { "id": "sbx_000000000000000000000001", "name": "docs-example", "size": "2vcpu-8gb", "disk_gib": 20, "status": "stopping", "error": null, "created_at": "2026-10-31T12:00:00Z", "started_at": "2026-10-31T12:00:00Z", "expires_at": "2026-10-31T20:00:00Z", "remaining_seconds": 28740, "runtime_seconds": 60, "credits_used": 1 } ``` ### 401 Unauthorized Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. application/json ``` { "error": { "code": "unauthorized" } } ``` ### 403 Forbidden The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. application/json ``` { "error": { "code": "permission_required" } } ``` ### 404 Not found No sandbox with this ID exists in the authorized workspace. application/json ``` { "error": { "code": "sandbox_not_found" } } ``` ### 409 Conflict The operation is not allowed in the current sandbox state. See the operation notes for other possible conflict codes. application/json ``` { "error": { "code": "sandbox_wrong_state" } } ``` ### 500 Internal error The server could not complete the request. application/json ``` { "error": { "code": "internal_error" } } ``` ### 503 Unavailable Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. application/json ``` { "error": { "code": "sandboxes_unavailable" } } ``` --- Source: https://runzivo.dev/docs/reference/sandboxes/terminal-ticket/ # Create a terminal ticket Issue a single-use ticket so a browser can open the terminal without an Authorization header. POST `/v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}/terminal-ticket` Base URL: `https://api.runzivo.dev` ## Authentication Send `Authorization: Bearer ` with a customer access token or workspace API key. API key permission: `sandboxes:write`. These are permissions, not legacy scopes. A key with the `all:all` scope also works, limited by its creator's current workspace permissions. ## Parameters | Field | Description | | --- | --- | | `tenantId` string · path Required | Your workspace's tenant ID. Replace the placeholder with an ID your token can access. | | `sandboxId` string · path Required | The id returned when the sandbox was created: sbx\_ followed by 24 lowercase hexadecimal characters. | ## Request body No request body is required. ## Behavior and limits - Requires a running sandbox. A ticket lasts about 30 seconds and is bound to one sandbox and workspace. - Append the URL-encoded ticket as ?ticket= to the returned terminal URL. Do not log the query string. A sandbox can have at most ten unused tickets (429 ticket_limit_reached). - Browser WebSocket connections cannot supply Authorization. Use the ticket without an Authorization header; API and CLI clients can instead authenticate the terminal directly. ## Responses | Status | Meaning | | --- | --- | | 201 Created | application/json | | 401 Unauthorized | Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. | | 403 Forbidden | The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. | | 404 Not found | No sandbox with this ID exists in the authorized workspace. | | 409 Conflict | The operation is not allowed in the current sandbox state. See the operation notes for other possible conflict codes. | | 429 Too many tickets | Ten unused tickets already exist for this sandbox. | | 500 Internal error | The server could not complete the request. | | 503 Unavailable | Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. | Examples use synthetic IDs, dates and values. Read the actual response and status in your workspace. ## Ticket response fields | Field | Description | | --- | --- | | `url` string Required | Absolute wss URL of this sandbox's terminal. | | `ticket` string Required | Single-use ticket, valid for about 30 seconds. Append as a URL-encoded query parameter. | | `expires_at` date-time Required | When the ticket expires. | [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) Page tools [View as Markdown](https://runzivo.dev/docs/reference/sandboxes/terminal-ticket.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fterminal-ticket.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fterminal-ticket.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fterminal-ticket.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. ## Request example Illustrative request. Set RUNZIVO_TOKEN and TENANT_ID, and SANDBOX_ID in your shell. Replace placeholders with your own values. This page does not send requests. cURL ``` curl --request POST \ "https://api.runzivo.dev/v1/customer/tenants/${TENANT_ID}/sandboxes/${SANDBOX_ID}/terminal-ticket" \ --header "Authorization: Bearer ${RUNZIVO_TOKEN}" ``` ## Response example application/json · Illustrative response; values and timing vary in your workspace. 201 · application/json ``` { "url": "wss://api.runzivo.dev/v1/customer/tenants//sandboxes/sbx_000000000000000000000001/terminal", "ticket": "", "expires_at": "2026-10-31T12:00:30Z" } ``` All response examples (also available without JavaScript) ### 201 Created Illustrative response; values and timing vary in your workspace. application/json ``` { "url": "wss://api.runzivo.dev/v1/customer/tenants//sandboxes/sbx_000000000000000000000001/terminal", "ticket": "", "expires_at": "2026-10-31T12:00:30Z" } ``` ### 401 Unauthorized Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. application/json ``` { "error": { "code": "unauthorized" } } ``` ### 403 Forbidden The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. application/json ``` { "error": { "code": "permission_required" } } ``` ### 404 Not found No sandbox with this ID exists in the authorized workspace. application/json ``` { "error": { "code": "sandbox_not_found" } } ``` ### 409 Conflict The operation is not allowed in the current sandbox state. See the operation notes for other possible conflict codes. application/json ``` { "error": { "code": "sandbox_wrong_state" } } ``` ### 429 Too many tickets Ten unused tickets already exist for this sandbox. application/json ``` { "error": { "code": "ticket_limit_reached" } } ``` ### 500 Internal error The server could not complete the request. application/json ``` { "error": { "code": "internal_error" } } ``` ### 503 Unavailable Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. application/json ``` { "error": { "code": "sandboxes_unavailable" } } ``` --- Source: https://runzivo.dev/docs/reference/sandboxes/terminal/ # Open a terminal Upgrade to a WebSocket for a running sandbox's interactive terminal. GET `/v1/customer/tenants/{tenantId}/sandboxes/{sandboxId}/terminal` Base URL: `https://api.runzivo.dev` ## Authentication Send `Authorization: Bearer ` with a customer access token or workspace API key. API key permission: `sandboxes:write`. These are permissions, not legacy scopes. A key with the `all:all` scope also works, limited by its creator's current workspace permissions. A browser can instead use a [single-use terminal ticket](https://runzivo.dev/docs/reference/sandboxes/terminal-ticket/), without an Authorization header. ## Parameters | Field | Description | | --- | --- | | `tenantId` string · path Required | Your workspace's tenant ID. Replace the placeholder with an ID your token can access. | | `sandboxId` string · path Required | The id returned when the sandbox was created: sbx\_ followed by 24 lowercase hexadecimal characters. | | `ticket` string · query Optional | Single-use browser terminal ticket. Supply this without Authorization; API and CLI clients send a bearer token instead. | ## Request body No request body is required. ## Behavior and limits - Requires a WebSocket client. The cURL example shows the HTTP upgrade request only; it is not an interactive terminal client. - Terminal bytes travel as binary frames in both directions, never base64. The only text frame is a resize object: {"type":"resize","cols":80,"rows":24}; each dimension must be 1–1000. - Answer server pings (every 30 seconds) with pong. Up to two terminals per sandbox. A new connection creates a new shell; a disconnected session does not resume. - Close codes: 1000 for normal/lifecycle closure or 30-minute idle timeout; 1003 invalid text frame; 1008 input_rate; 1009 frame over 64 KiB; 1011 server fault or output_overflow. ## Responses | Status | Meaning | | --- | --- | | 101 Switching Protocols | WebSocket | | 400 Invalid request | Malformed JSON, unknown fields or invalid values. Terminal upgrades also reject malformed handshakes. | | 401 Unauthorized | Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. | | 403 Forbidden | The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. | | 404 Not found | No sandbox with this ID exists in the authorized workspace. | | 409 Conflict | The operation is not allowed in the current sandbox state. See the operation notes for other possible conflict codes. | | 426 Upgrade required | The request did not contain a WebSocket upgrade. | | 500 Internal error | The server could not complete the request. | | 503 Unavailable | Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. | Examples use synthetic IDs, dates and values. Read the actual response and status in your workspace. [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) Page tools [View as Markdown](https://runzivo.dev/docs/reference/sandboxes/terminal.md) Ask AI about this page [Open in ChatGPT](https://chatgpt.com/?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fterminal.md) [Open in Claude](https://claude.ai/new?q=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fterminal.md) [Open in Cursor](https://cursor.com/link/prompt?text=Read%20this%20Runzivo%20documentation%20page%2C%20then%20help%20me%20with%20it%3A%0A%0Ahttps%3A%2F%2Frunzivo.dev%2Fdocs%2Freference%2Fsandboxes%2Fterminal.md) Claude shows a caution banner on any prefilled prompt. That is expected: review the prompt, then send it. ## Request example Illustrative request. Set RUNZIVO_TOKEN and TENANT_ID, and SANDBOX_ID in your shell. Replace placeholders with your own values. This page does not send requests. Set WEBSOCKET_KEY to a fresh base64-encoded 16-byte nonce. This cURL request shows the HTTP upgrade only; use a WebSocket client for terminal frames. cURL ``` curl --http1.1 --request GET \ "https://api.runzivo.dev/v1/customer/tenants/${TENANT_ID}/sandboxes/${SANDBOX_ID}/terminal" \ --header "Authorization: Bearer ${RUNZIVO_TOKEN}" \ --header "Connection: Upgrade" \ --header "Upgrade: websocket" \ --header "Sec-WebSocket-Version: 13" \ --header "Sec-WebSocket-Key: ${WEBSOCKET_KEY}" ``` ## Response example WebSocket · An upgraded socket has no JSON response body. Illustrative protocol exchange: 101 · WebSocket ``` Client → server: binary terminal input bytes Client → server: text {"type":"resize","cols":80,"rows":24} Server → client: binary terminal output bytes Server → client: ping (client replies pong) ``` ### Browser connection with a ticket Illustrative JavaScript after obtaining a ticket. Use its returned URL, do not log it, and send terminal input as binary frames. JavaScript ``` // ticketResponse is the terminal-ticket response. const url = new URL(ticketResponse.url); url.searchParams.set("ticket", ticketResponse.ticket); const socket = new WebSocket(url); socket.binaryType = "arraybuffer"; socket.addEventListener("open", () => { socket.send(JSON.stringify({ type: "resize", cols: 80, rows: 24 })); }); ``` All response examples (also available without JavaScript) ### 101 Switching Protocols An upgraded socket has no JSON response body. Illustrative protocol exchange: WebSocket ``` Client → server: binary terminal input bytes Client → server: text {"type":"resize","cols":80,"rows":24} Server → client: binary terminal output bytes Server → client: ping (client replies pong) ``` ### 400 Invalid request Malformed JSON, unknown fields or invalid values. Terminal upgrades also reject malformed handshakes. application/json ``` { "error": { "code": "invalid_request" } } ``` ### 401 Unauthorized Missing or invalid bearer token. A ticketed terminal request can instead return ticket_invalid. application/json ``` { "error": { "code": "unauthorized" } } ``` ### 403 Forbidden The caller lacks workspace membership or permission, or the API key is not allowed. Codes include tenant_membership_required, permission_required and api_key_scope_required. application/json ``` { "error": { "code": "permission_required" } } ``` ### 404 Not found No sandbox with this ID exists in the authorized workspace. application/json ``` { "error": { "code": "sandbox_not_found" } } ``` ### 409 Conflict The operation is not allowed in the current sandbox state. See the operation notes for other possible conflict codes. application/json ``` { "error": { "code": "sandbox_wrong_state" } } ``` ### 426 Upgrade required The request did not contain a WebSocket upgrade. application/json ``` { "error": { "code": "websocket_required" } } ``` ### 500 Internal error The server could not complete the request. application/json ``` { "error": { "code": "internal_error" } } ``` ### 503 Unavailable Sandbox service is unavailable. Exec and terminal operations can also return sandbox_exec_unavailable. application/json ``` { "error": { "code": "sandboxes_unavailable" } } ``` --- Source: https://runzivo.dev/docs/troubleshooting/ # Troubleshooting Check authorization and the runner label before changing workflow code. ## Job stays queued - Confirm the GitHub App selected in the installation guide is installed and active for the repository running the workflow. - Confirm the workflow uses the eligible Linux x64 label shown in the portal. - Confirm the workspace has available allowance and that no other job is running. - Check the GitHub Actions run page for the job's queue message. If Runzivo stops waiting, Runzivo records no execution charge for that local attempt. GitHub may still show the job as queued. Independently, GitHub fails a self-hosted job that remains queued for more than 24 hours. Rerun the job from GitHub only if its current state permits a rerun. Runzivo does not cancel or complete the GitHub job or its sibling jobs. [Read the GitHub App installation guide](https://runzivo.dev/docs/github-app/) [Review GitHub's self-hosted runner queue rules](https://docs.github.com/en/actions/reference/runners/self-hosted-runners#routing-precedence-for-self-hosted-runners) ## Runner is not eligible A Runzivo label does not authorize a repository by itself. Check the GitHub App's selected-repository configuration in the portal, then reconnect the installation if it was recently changed. ## A job fails after it starts Read the GitHub Actions logs first. Compare the failing command with a known run and verify any environment secret, permission, or external dependency the workflow requires. Do not include secrets in support information. ## Logs are unavailable after renaming a GitHub organization or repository Runzivo stores the GitHub organization and repository names it receives from the GitHub App. After a rename, the job log view can show that GitHub did not return the logs, and the workspace switcher can show the old organization name. Runzivo picks up renames from GitHub. If job logs still do not load after a rename, refresh the stored repository name with the steps below. Renaming the workspace in portal Settings changes only its label in Runzivo. - In GitHub, open the organization, then Settings, GitHub Apps, Runzivo, and Repository access. - Remove the affected repository and save. Runzivo does not accept new jobs for that repository until you add it back. - Add the repository back and save. - Open the job in the portal again. ## Why was I signed out? The customer portal ends a session after 14 days without activity, or 30 days after sign-in even if you have been active. Background refreshes in an open tab do not count as activity. A session also ends when you sign out, when the account is suspended, or when Runzivo staff sign the account out everywhere. Sign in again to continue. When the session update shipped, every customer was signed out of the portal once. Signing in again starts a new session with the current limits. If the portal asks you to confirm it's you, you are still signed in. It asks before sensitive actions when you have not signed in within the last 15 minutes. [Read the sign-in and sessions guide](https://runzivo.dev/docs/sign-in/) ## CLI commands fail See the CLI guide's own troubleshooting section for CLI-specific error messages. [Read the rzv CLI guide](https://runzivo.dev/docs/cli/) ## Need help Open a support ticket in the portal. Include the repository name, workflow run URL, job name, UTC time, and a redacted error excerpt. Do not send credentials or secret values. [Open Support in the portal](https://app.runzivo.dev/support) On this page and page tools --- Source: https://runzivo.dev/ # Build your product. Not your runner fleet. Runzivo builds fast, secure CI runners for modern software teams. [Open portal](https://app.runzivo.dev/) [Read the docs](https://runzivo.dev/docs/) One workflow label. Your existing steps stay put. workflow.yml your workflow Workflow file: jobs, test, runs-on rzv-ubuntu-24.04-x64-2vcpu-8gb. The steps are unchanged. 1. 2. 3. 4. GitHub Actions on Linux x64 today. GitLab CI is a roadmap direction, not available in V1. ## From workspace to first job. Sign in with GitHub, then connect your organization and repository for an eligible Linux x64 workflow. ### Your first job - - - ### Sign in with GitHub Sign in with the GitHub identity you use for the customer portal. [Open the portal](https://app.runzivo.dev/) ## Performance claims come after repeatable measurements. Runzivo plans to publish comparisons after measuring the same workloads with documented capacity and methods. Comparable baselines ## Compare the same workflow before publishing a result. A useful comparison needs the same workflow, a clear baseline, and a documented method for both runs. Real-job evidence ## Early Access will test the service with real CI jobs. We will measure queue time, start time, runtime, reliability, and teardown before making claims about the service. ## Explore the customer portal Sample workspace data. Screens illustrate the portal; plan details depend on your workspace. **Workspaces.** Choose the workspace for your team. ## CI you can start, isolate, and follow. 01 ### Queue-to-start visibility Short queue-to-start time is a design goal. Every job boots a fresh microVM today, with no pre-booted warm pool yet. Warm capacity to cut setup time is planned. 02 ### Per-job isolation Each eligible job runs in a single-use Firecracker microVM that is destroyed when the job ends. 03 ### Follow the lifecycle See each job's status and logs in the portal and with rzv jobs. Insights shows duration, queue wait and minutes by runner size. 04 ### No lock-in Start with one line: change runs-on. Leave with one line: change runs-on back, then uninstall the App. ## AI that writes and fixes your pipelines. Built on the same isolated runners. These features are not available to customers yet: each one is switched off and will be turned on per workspace during early access. AI ### AI chat Ask about your jobs, runners, usage and the docs across every workspace you belong to, in one full-screen chat. AI ### Pipeline builder Describe the pipeline you need. Runzivo writes the GitHub Actions workflow and opens a pull request for you to review. Its jobs run on Runzivo only after you approve them. AI ### CI fix agent When a workflow fails, Fix with AI reads the failure and proposes a change to CI files in a pull request from a new branch. It never pushes to your branch and never merges. [Where Runzivo is heading](https://runzivo.dev/ai/) ## One layer of your CI stack. GitHub Actions stays yours. Runzivo runs the three middle layers: admission, one isolated runner per job, and the hosts they run on. This describes the V1 design. Early Access offers Linux x64 runners from 2 to 32 vCPU today. macOS and Windows are provisioned on request; the security page and runner docs state what is available. ## Linux x64 runners from 2 to 32 vCPU. Runzivo currently offers these labels for GitHub Actions, running in Ottawa (YOW) and Montreal (YUL), Canada. Run up to your plan's concurrent job limit. Jobs may queue when runner capacity is unavailable. - `rzv-ubuntu-24.04-x64-2vcpu-8gb` - `rzv-ubuntu-24.04-x64-4vcpu-16gb` - `rzv-ubuntu-24.04-x64-6vcpu-24gb` - `rzv-ubuntu-24.04-x64-8vcpu-32gb` - `rzv-ubuntu-24.04-x64-16vcpu-64gb` - `rzv-ubuntu-24.04-x64-32vcpu-128gb` Runzivo Linux x64 Managed, single-use execution for connected GitHub Actions repositories. [Read runner details](https://runzivo.dev/docs/runners/) ## One job. One isolated environment. Torn down by design. Runzivo runs each eligible job in a fresh Firecracker microVM and destroys it when the job ends. Each job gets a single-use runner registered with GitHub for that job only. - Ephemeral runners - MicroVM isolation - Single-use environments - Short-lived credentials [Read security approach](https://runzivo.dev/security/) ## 3,000 free equivalent minutes per workspace. The free allowance resets monthly in UTC. After it, buy prepaid credit packs by card in Canada and the United States, or by bank transfer. ### Monthly allowance Early Access 0 of 3,000 equivalent minutes 0% 3,000 equivalent minutes left - Run up to your plan's concurrent job limit. Jobs may queue when runner capacity is unavailable. - See CAD, USD, EUR and GBP prices and future programs [Explore pricing](https://runzivo.dev/pricing/) ## Built on proven infrastructure, with a sponsor. ZSoftly Cloud Platform is a proud sponsor and partner of Runzivo. For partnership inquiries, email [partners@runzivo.dev](mailto:partners@runzivo.dev). - GitHub Actions - Firecracker microVMs - Ubuntu 24.04 - Linux x64 - Go - OpenHands - OpenSSH - Docker BuildKit - PostgreSQL - OpenTelemetry - [ZSoftly Cloud Platform](https://zcp.zsoftly.ca/) - GitHub Actions - Firecracker microVMs - Ubuntu 24.04 - Linux x64 - Go - OpenHands - OpenSSH - Docker BuildKit - PostgreSQL - OpenTelemetry - [ZSoftly Cloud Platform](https://zcp.zsoftly.ca/) ## Your workflow already works. Change one label to run it on Runzivo. Our research: teams already pay for faster GitHub Actions runners. That is why services such as Blacksmith, Depot and WarpBuild exist. Runzivo runs each job in a fresh, isolated microVM and will publish speed numbers only after measuring them. [See how Runzivo compares](https://runzivo.dev/compare/) [Read installation guide](https://runzivo.dev/docs/github-app/) --- Source: https://runzivo.dev/about/ # The story behind Runzivo. CI runners should be a service you use, not a fleet you look after. This is why Runzivo exists. Read the story Meet the founder ## Why I built Runzivo I spent years building delivery platforms for other companies, and then a cloud of our own. Runzivo is what came next. 1. 2022 ### ZSoftly - I founded ZSoftly, a Canadian public and private cloud company. 2. Jun 2026 ### The idea - With ZCP built, I decided to build a service that people and their AI agents can use. 3. 13 Sep 2026 ### First commit - CAD 25,000 pre-seed: CAD 15,000 from me and CAD 10,000 in ZSoftly cloud credits. - Building started. 4. 1 Oct 2026 ### Incorporated - Runzivo Technologies Inc. was incorporated in Ontario. 5. 3 Oct 2026 ### rzv CLI - The rzv command-line tool shipped. [CLI docs](https://runzivo.dev/docs/cli/) 6. 18 Oct 2026 ### AI features - AI features entered Early Access. [AI](https://runzivo.dev/ai/) 7. 20 Oct 2026 ### GitHub Actions runners - Managed Linux runners opened for Early Access testing. [Runners](https://runzivo.dev/docs/runners/) - Each job runs in a fresh microVM. 8. 31 Oct 2026 ### Agent Sandboxes and plans - Agent Sandboxes became available. [Agent Sandboxes](https://runzivo.dev/sandboxes/) - Team and Business plans became available. [Pricing](https://runzivo.dev/pricing/) 9. 1 Nov 2026 ### Sandbox access and Audit - Sandboxes gained SSH, file transfer and editor access. [SSH guide](https://runzivo.dev/docs/sandboxes-ssh/) - A developer image with common tools, and short-lived access to private repositories. - Audit & Status got three views and clearer evidence. [Audit & Status](https://runzivo.dev/blog/audit-status-redesign/) 10. Next ### More compute, more choice - More kinds of compute as teams need them, starting with OpenHands agent tasks in sandboxes. What I care about are the core things every business needs: a clear problem, a clear path to revenue, and one service you reach through a single API. Solve it well, and let people and their agents use it. No team should have to babysit a runner fleet next to its source code. I also believe in redundancy. When one runner provider has a bad day, your pipelines should have another place to go. No single company should do it all. OpenAI and Anthropic push each other to be better, and CI deserves the same. Ditah Kumbong, founder ### One job, done well Runzivo runs GitHub Actions jobs on managed Linux runners. Change one runner label; each job gets a fresh microVM that is destroyed when it ends. Live in Early Access. ### Made to be used, by people and agents The portal, the rzv command-line tool and API keys give people and their tools the same way in. No fleet to install, patch or scale. ### Another place to run Runzivo can sit beside the runners you already use. When one provider has an outage, your pipelines still have somewhere to go. ## The founder ### Ditah Kumbong Founder, Runzivo · DevOps Architect Ditah Kumbong is a DevOps architect who builds the delivery platforms software teams ship through: CI/CD pipelines, cloud infrastructure, and the automation that makes releases safe and repeatable. Over the last five years that work has covered data visualization at Plotly, mortgage insurance at Sagen, internet infrastructure at CIRA and secure data rooms at Firmex. Along the way he has consulted for many more companies across healthcare, fintech, security and AI. Different industries, the same problem every time: CI that waits in queues, shares runners between jobs, and needs someone to keep a fleet alive. Runzivo is his answer to it. In 2022 Ditah founded ZSoftly, a Canadian public and private cloud company with a professional services team, and has led it since. He designs, builds, deploys and operates Runzivo end to end, from the runners to the platform to this website. Outside work, Ditah is the father of a daughter, named after his mother, whom he cherishes with all his heart. - ZSoftly Public and private cloud, customer experience - Plotly Data visualization - Sagen Mortgage insurance - CIRA Internet infrastructure - Firmex Secure data rooms - Consulting Healthcare, fintech, security, AI [GitHub](https://github.com/ditahkk) [LinkedIn](https://www.linkedin.com/in/ditahck/) ## What Runzivo is built on. These are the technologies we use today, and what each one does for you. - **GitHub Actions** The CI system your workflows already run on. Change runs-on to a Runzivo label and your jobs run on our runners. - **Firecracker microVMs** Runners and sandboxes run inside Firecracker microVMs. - **Ubuntu 24.04** The operating system image on our hosted Linux runners. - **Linux x64** The runner platform available today. Arm64 is not part of V1. - **Go** The language of our control plane and of the agents that run on hosts and inside guests. - **OpenHands Coming soon** Runs agent tasks inside Agent Sandboxes. - **OpenSSH** Secure shell access to sandboxes, using host certificates that Runzivo signs. - **Docker BuildKit** Builds Docker images on Runzivo runners. A shared Docker layer cache is coming soon. - **PostgreSQL** Stores Runzivo's product data in the control plane. - **OpenTelemetry** Distributed tracing for the control plane. - **ZSoftly Cloud Platform** The cloud platform Runzivo runs on. ZSoftly is also a sponsor and partner of Runzivo. ## Try Runzivo on your next workflow. [Request Early Access](https://runzivo.dev/early-access/) [Book a call](https://calendar.app.google/MHx9yPmWJmw3Gcbc8) --- Source: https://runzivo.dev/ai/ # AI that writes and fixes your pipelines. AI chat, a pipeline builder and a CI fix agent, built on the same isolated runners. All three are built and switched off for customers. We turn each one on per workspace during early access. [Request Early Access](https://runzivo.dev/early-access/) [Read the docs](https://runzivo.dev/docs/) ## Ask about your CI in plain words. Ask about your jobs, runners, usage and the docs across every workspace you belong to, in one full-screen chat. Answers link the pages they used. Example ### Why did my last job wait? [Usage and limits 1 Usage and limits · Runzivo docs](https://runzivo.dev/docs/usage-limits) [Linux x64 runners 2 Linux x64 runners · Runzivo docs](https://runzivo.dev/docs/runners) Reading 2 sources ## Describe the pipeline you need. Runzivo writes the GitHub Actions workflow and opens a pull request for you to review. Its jobs run on Runzivo only after you approve them. Example ### Run this workflow on Runzivo runners? The pipeline builder opened a pull request with this workflow. Medium risk Repository your-org/your-repo Workflow .github/workflows/ci.yml Delivered as Pull request ## Fix with AI when a workflow fails. Fix with AI reads the failure and proposes a change to CI files in a pull request from a new branch. It never pushes to your branch and never merges. Example 1. failure.read finished No arguments or result. 2. ci_change.propose finished No arguments or result. 3. pull_request.open finished No arguments or result. ## Nothing changes without you. ### Changes arrive as pull requests The pipeline builder and the CI fix agent deliver their work as pull requests you review. A workspace owner can opt the builder in to commit a workflow file directly. ### Runs need your approval A workflow the builder writes runs on Runzivo only after you approve it. ### Fixes touch CI files only The CI fix agent proposes changes to CI files. It never pushes to your branch and never merges. ### Off until enabled Every AI feature is switched off and stays off until it is enabled for your workspace during early access. ## From product conversation to verified feature. The three features above are the first pieces of a broader delivery loop. The rest is direction, not a product today. Plan · 7 steps ### From product conversation to verified feature Press Enter to rename, Alt plus arrow keys to move, Delete to remove. 1. Product Team Slack, Google Meet, tickets, docs, and product decisions., Pending 2. Runzivo Context Agent Reads project material, extracts decisions, and builds project context., Pending 3. Runzivo Planner Turns requirements into tasks, implementation plans, and acceptance criteria., Pending 4. Runzivo Build Uses a coding agent to create a branch, write code, and prepare commits for review., Pending 5. Runzivo CI Runners Runs builds, tests, scans, lint, and policy checks inside Firecracker isolation., Pending 6. Pull Request Packages the code, test results, and change summary for human approval., Pending 7. Verification Runs smoke tests and feature validation before calling the work complete., Pending Direction, not a running plan. Only the early-access pieces above are built. ## Bring a workflow and try the AI features first. [Request Early Access](https://runzivo.dev/early-access/) --- Source: https://runzivo.dev/compare/ # Firecracker isolation. None of the servers. Runzivo is designed to run every GitHub Actions job in a fresh Firecracker microVM on dedicated hosts we operate, then destroy it when the job ends. You change one runs-on label. We handle the rest. ## Pick by who you want running servers. ### Choose actuated if You want jobs on servers you own or rent, and you have a team to buy, patch, and run them. ### Choose Blacksmith if You want a managed service available today, with runners in the United States or Europe and built-in caching. ### Choose Runzivo if You want a managed service with jobs in Canada and no servers to run, and you can join Early Access. ## How the three services differ. Runzivo entries describe the current V1 scope. Competitor entries come from their public pages, checked on September 27, 2026. | Topic | Runzivo | actuated | Blacksmith | | --- | --- | --- | --- | | Who runs the servers | Runzivo. You install nothing on your own hardware. | You. You bring the servers and install the actuated agent. actuated runs the control plane. | Blacksmith. | | Hardware | Hosts in Canada that Runzivo operates, including dedicated bare-metal servers. | Your own bare-metal or cloud servers. | Bare-metal servers with high single-core gaming CPUs. | | Job isolation | Designed for one ephemeral Firecracker microVM per job, destroyed when the job ends. | One Firecracker microVM per job. | Ephemeral Firecracker microVMs. | | CI systems | GitHub Actions. GitLab is not part of V1. | GitHub Actions and GitLab CI. | GitHub Actions. | | Operating systems and CPUs | Ubuntu on x64. Arm64 is not part of V1. Windows and macOS runners are provisioned on request. | Linux on x86-64 and Arm64. | Linux on x64 and Arm64, Windows, and Apple Silicon macOS. | | Where jobs run | Canada, on dedicated bare-metal hosts. No hyperscaler. | Any country you choose, on your own hardware, a bare-metal provider, or a hyperscaler such as AWS, Google Cloud, or Azure. | United States, the Netherlands, and Germany, on its own bare-metal fleet. No hyperscaler. | | Pricing model | Free allowance of 3,000 2-vCPU equivalent minutes per workspace, per month, then prepaid credit packs or a Team or Business plan. | Flat monthly subscription by concurrent builds. You also pay for your servers. | Per-minute usage with a monthly free allowance. | | Setup | Install the GitHub App on selected repositories and change runs-on. | Provision servers, install the agent, connect GitHub, and change runs-on. | Install the GitHub App and change runs-on. | | Beyond the runner | The portal shows job results, logs, usage and Insights: duration, queue wait and the slowest workflows. Cache acceleration is not available. | Build insights and server status in a dashboard. | Co-located caching, Docker layer caching, and a CI console. | | Availability | Early Access, with self-service sign-up through GitHub. | Available now. | Available now. | ## No performance or savings claims yet. actuated and Blacksmith publish their own speed and cost figures. Runzivo does not compare performance or savings until repeatable benchmarks on its own hosts support a number. We will publish the method with the results. Sources: [actuated](https://actuated.com/), [actuated server options](https://docs.actuated.com/provision-server/), [Blacksmith](https://www.blacksmith.sh/), [Blacksmith runner types and regions](https://docs.blacksmith.sh/blacksmith-runners/overview), [Blacksmith hardware](https://www.blacksmith.sh/blog/blacksmith-seed-announcement). actuated is a product of OpenFaaS Ltd. Product names belong to their owners. Tell us at [hello@runzivo.dev](mailto:hello@runzivo.dev) if an entry is out of date. ## Try Runzivo on one repository. [Request Early Access](https://runzivo.dev/early-access/) [Review the security model](https://runzivo.dev/security/) --- Source: https://runzivo.dev/customers/ # Customer stories Customer stories are not published yet. Explore proposed pilots for teams with CI runner needs, or request Early Access to discuss your workflow. [Explore use cases](https://runzivo.dev/use-cases/) [Request Early Access](https://runzivo.dev/early-access/) --- Source: https://runzivo.dev/early-access/ # Bring your GitHub Actions workload. We are onboarding a small group of teams to test Runzivo with real CI workloads and report what works and what does not. ## Teams running GitHub Actions. Early Access is for software teams with Linux x64 jobs that want to evaluate managed CI compute with one small workflow change. ## Linux x64. GitHub Actions. V1 supports approved GitHub Actions repositories and controlled Linux x64 capacity. GitLab is not available in V1. Windows and macOS runners are provisioned on request. ## We review the fit together. Include your GitHub organization and repository, workflow type, expected concurrency, typical job duration, and contact details. We will confirm eligibility, limits, and the GitHub App setup. - GitHub organization and repository - Workflow type and typical job duration - Expected concurrent jobs - Best contact for the evaluation Early Access is controlled and has no service-level agreement. Do not include credentials, secrets, or sensitive workflow data in your first message. Read the [privacy notice](https://runzivo.dev/legal/privacy/). ## Tell us what you want to run. Answer five short steps and we draft the email for you: your organization, repository, workflow type, expected concurrency, and typical job duration. Book a call if you prefer to review your CI setup live. [Email Runzivo](mailto:run@runzivo.dev?subject=Request%20Early%20Access&body=GitHub%20organization%20and%20repository%3A%0AWorkflow%20type%3A%0ATypical%20job%20duration%3A%0AExpected%20concurrency%3A%0ABest%20contact%3A%0A) [Book a product call](https://calendar.app.google/MHx9yPmWJmw3Gcbc8) 1. 1\. Repository (current) 2. 2\. Workflow 3. 3\. Capacity 4. 4\. Contact 5. 5\. Review ## Repository Do not include credentials, secrets, or sensitive workflow data. GitHub organization and repository Or email [run@runzivo.dev](mailto:run@runzivo.dev) directly if your browser has no mail app configured. --- Source: https://runzivo.dev/newsletter/ # Stay close to the build. Get product, engineering and Early Access updates as Runzivo builds secure CI runners. ## Useful updates. No runner noise. We will share product progress, practical CI infrastructure notes, and opportunities to help shape Early Access with real workloads. Already subscribed? Browse the [newsletter archive](https://buttondown.com/runzivo/archive/). ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). --- Source: https://runzivo.dev/pricing/ # 3,000 free unit-minutes. Fixed prices in CAD One workspace balance for CI runners and Agent Sandboxes. ## Choose a workspace plan. Developer CA$0 /month For individual developers [Sign Up](https://app.runzivo.dev/) - 3,000 unit-minutes/month (included) - Public & private repos (included) Team CA$140 /month For growing teams [Subscribe](https://app.runzivo.dev/billing) - 100,000 unit-minutes/month (included) - Shared workspace usage (included) Business CA$350 /month For larger workloads [Subscribe](https://app.runzivo.dev/billing) - 250,000 unit-minutes/month (included) - Shared workspace usage (included) - Optional dedicated capacity, priced separately on request (not included) No credit card required to create a Developer workspace. Paid allowances replace the Developer allowance. CI runners and Agent Sandboxes draw from the same balance. Compare workspace plans | | Developer | Team | Business | | --- | --- | --- | --- | | Price | CA$0/month | CA$140/month | CA$350/month | | Included unit-minutes per month | 3,000 | 100,000 | 250,000 | | Allowance | 3,000 for every new workspace | Replaces the 3,000, not added to it | Replaces the 3,000, not added to it | | Plan overage | n/a | CA$0.0021 per unit-minute | CA$0.0021 per unit-minute | | Repositories | Public and private | Public and private | Public and private | | Usage | Shared across the workspace | Shared across the workspace | Shared across the workspace | | Credit card to sign up | Not required | Required | Required | | Plan becomes active | When you sign up | When you subscribe | When you subscribe | | When credits run out | New jobs pause until you add credits or the allowance renews | Overage is billed monthly, up to the overage cap. An unpaid overage invoice stops new overage immediately. A failed renewal stops new overage when renewal grace ends | Overage is billed monthly, up to the overage cap. An unpaid overage invoice stops new overage immediately. A failed renewal stops new overage when renewal grace ends | Plan prices in every currency | Plan | Included unit-minutes | CAD | USD | EUR | GBP | | --- | --- | --- | --- | --- | --- | | Developer | 3,000 | CA$0 | US$0 | €0 | £0 | | Team | 100,000 | CA$140 | US$100 | €90 | £75 | | Business | 250,000 | CA$350 | US$250 | €225 | £190 | | Plan | CAD | USD | EUR | GBP | | --- | --- | --- | --- | --- | | Team | CA$1,428/year (CA$119/month) | US$1,020/year (US$85/month) | €918/year (€76.50/month) | £765/year (£63.75/month) | | Business | CA$3,570/year (CA$297.50/month) | US$2,550/year (US$212.50/month) | €2,295/year (€191.25/month) | £1,938/year (£161.50/month) | A unit-minute is one minute on a 2 vCPU runner. Larger runners use more unit-minutes per minute: 4 vCPU uses 2, 6 vCPU uses 3, 8 vCPU uses 4, 16 vCPU uses 8 and 32 vCPU uses 16. Run up to your plan's concurrent job limit. Jobs may queue when runner capacity is unavailable. Business: Higher concurrency limits, with optional dedicated, pre-warmed runner pools for guaranteed reserved capacity. Available on request; contact sales. On Developer, new jobs pause when credits run out until you add credits or your allowance renews. On Team and Business, overage continues up to the overage cap. The allowance resets at the start of each UTC month. No current service-level agreement applies. ### Monthly free allowance Free · resets each UTC month 0 of 3,000 unit-minutes 0% 3,000 unit-minutes left [Book a product call](https://calendar.app.google/MHx9yPmWJmw3Gcbc8) ## GitHub Actions runners Ubuntu x64 runners from 2 to 32 vCPU are available now in Ottawa (YOW) and Montreal (YUL), Canada; Windows and macOS are provisioned on request. Available now Hosted Ubuntu 24.04 x64 runners for GitHub Actions in Canada. Change runs-on to a Runzivo label. **Pricing:** Unit-minutes from your plan allowance or prepaid credit. [Read about GitHub Actions runners](https://runzivo.dev/docs/runners/) ## Plan overage Choose a runner size. Team includes 100,000 and Business includes 250,000 unit-minutes each month, replacing the Developer allowance. Usage draws on the plan allowance first, then prepaid credit, then overage up to the monthly cap. CA$ 0.0021 Plan overage per runner minute for 2 vCPU **3,000** minutes on a 2-vCPU runner from the Developer monthly allowance Runner rates and requested platforms ### Plan overage Overage rates apply to Team and Business subscriptions. | CAD | USD | EUR | GBP | | --- | --- | --- | --- | | CA$0.0021 | US$0.0015 | €0.0013 | £0.0011 | | Runner | Availability | CAD | USD | EUR | GBP | | --- | --- | --- | --- | --- | --- | | 2 vCPU | Available now | CA$0.0021 | US$0.0015 | €0.0013 | £0.0011 | | 4 vCPU | Available now | CA$0.0042 | US$0.003 | €0.0026 | £0.0022 | | 6 vCPU | Available now | CA$0.0063 | US$0.0045 | €0.0039 | £0.0033 | | 8 vCPU | Available now | CA$0.0084 | US$0.006 | €0.0052 | £0.0044 | | 16 vCPU | Available now | CA$0.0168 | US$0.012 | €0.0104 | £0.0088 | | 32 vCPU | Available now | CA$0.0336 | US$0.024 | €0.0208 | £0.0176 | | Windows | Custom / Provisioned on Request | Contact us for pricing | | | | | macOS | Custom / Provisioned on Request | Contact us for pricing | | | | Windows and macOS runners run on dedicated capacity we provision for you on request. Request capacity and we'll confirm a start date before your jobs use it. Windows and macOS are subject to hardware and licensing. [Request capacity](mailto:run@runzivo.dev?subject=Runzivo%20capacity%20request) ## Agent Sandboxes Available now Isolated Linux microVMs for coding agents, driven from the rzv CLI, a command API or a terminal. Each sandbox lasts eight hours from its first start. **Pricing:** Unit-minutes while the VM runs: 1x for 2 vCPU, 2x for 4, 4x for 8 and 8x for 16, as capacity allows. A stopped sandbox is not billed. [Read about Agent Sandboxes](https://runzivo.dev/docs/sandboxes/) Sandbox compute draws from the same workspace allowance or prepaid credit as CI runners, at the runner rate for its size. There is no separate sandbox subscription. Stopping a sandbox does not extend its eight-hour lifetime. [Sandbox limits and billing](https://runzivo.dev/docs/sandboxes-limits/) ## CLI, AI tools and Devboxes Available now ### rzv CLI Sign in, connect GitHub and inspect your workspace, jobs and usage from a terminal. **Pricing:** Free. [Read about rzv CLI](https://runzivo.dev/docs/cli/) Early access ### AI CI tools AI chat, a pipeline builder and a CI fix agent. Switched off until enabled for your workspace. **Pricing:** No separate price yet. [Read about AI CI tools](https://runzivo.dev/ai/) Coming soon ### Devboxes Cloud development environments. **Pricing:** Not set yet. ## For specialized workloads and eligible teams. Enterprise: Custom concurrency, reserved infrastructure, and capacity commitments tailored to your workloads. [Contact Sales](mailto:run@runzivo.dev?subject=Runzivo%20Enterprise%20interest) ### Programs - Startup program For organizations under five years old, with fewer than 100 employees and under US$50 million raised. Contact us to discuss a discount. [Email us about Startup](mailto:partners@runzivo.dev?subject=Runzivo%20Startup%20program&body=Full%20name%3A%0AWork%20email%3A%0AGitHub%20organization%3A%0AOrganization%3A%0AEmployee%20count%3A%0AOrganization%20age%3A%0AFunding%20raised%3A) - Open source program For maintained public repositories under a permissive license and used by a community. Contact us to discuss a discount. [Email us about Open source](mailto:partners@runzivo.dev?subject=Runzivo%20Open%20Source%20program&body=Full%20name%3A%0AWork%20email%3A%0ARepository%20URL%3A%0ALicense%3A%0AHow%20the%20community%20uses%20it%3A%0AWhy%20CI%20matters%3A) ## Storage and networking add-ons. Approved for the roadmap, not built yet. Prices are not set. - Docker layer caching - Persistent disks - Static egress IPs Compute improvements, cache acceleration, and GitHub Actions observability are upcoming roadmap items. ## Prices in CAD, USD, EUR and GBP. Runzivo is a Canadian company. Canadian dollars are the base price. US dollars, euros and pounds sterling have their own fixed prices, set from the Canadian price at Bank of Canada rates of 26 October 2026. Prices are not recalculated at checkout. Subscription prices and prepaid credit packs are listed in all four currencies. ### Pay by card Card checkout is available only for workspaces billed in Canada and the United States. Buy prepaid credit packs in Billing & Credits. Stripe handles checkout. ### Pay by bank transfer Choose CAD or USD in Billing & Credits. Credit is added after the deposit is matched. Transfer instructions and fallback start it in the portal under Billing & Credits. Choose CAD or USD, then get payment instructions. The portal gives you a payment reference and our bank details. Put the reference in the transfer memo. If Pay by bank transfer isn't available in your workspace, email [run@runzivo.dev](mailto:run@runzivo.dev?subject=Runzivo%20bank%20transfer). Credit is added after we match the deposit, and you get a receipt by email. ### Prepaid credit packs | Pack | Unit-minutes | CAD | USD | EUR | GBP | | --- | --- | --- | --- | --- | --- | | Starter pack | 5,000 | CA$28 | US$20 | €18 | £15 | | Team pack | 25,000 | CA$130 | US$93 | €83 | £70 | | Scale pack | 100,000 | CA$495 | US$353 | €316 | £265 | Pack prices are one-time and exclude tax. Runzivo does not collect sales tax yet, so no tax is added to these prices at checkout. --- Source: https://runzivo.dev/sandboxes/ # A Linux workspace for your next command. Create an isolated Firecracker microVM. Run commands, inspect results and open a terminal from the rzv CLI, API or portal. Delete it when the work is done. [Open portal](https://app.runzivo.dev/) [Create your first sandbox](https://runzivo.dev/docs/sandboxes-quickstart/) **Isolated Linux** A Firecracker microVM per sandbox **CLI · API · Portal** Commands and interactive terminals **Up to 8 hours** From first start, running or stopped ## Create. Run. Inspect. Clean up. A short illustration of the command sequence, followed by copyable examples. Your browser does not support embedded video. The complete walkthrough is below. Illustrative animation, not a recording of a live sandbox. Commands use a placeholder sandbox ID. Follow the steps below with the ID returned in your workspace. 1. 01 ### Create Create and start a Linux microVM in your workspace. Wait until its status is running. Terminal · command example ``` rzv sandboxes create --name code-check --size 2vcpu-8gb rzv sandboxes list ``` 2. 02 ### Run commands Stream stdout and stderr. The CLI exits with the command’s status. Commands run in /workspace by default. Terminal · command example ``` rzv sandboxes exec -- "printf 'hello sandbox\n' > result.txt" ``` 3. 03 ### Inspect results Read the result or open an interactive terminal to investigate. Use exec on Windows and in scripts. Terminal · command example ``` rzv sandboxes exec -- cat result.txt rzv sandboxes ssh ``` 4. 04 ### Stop or delete Stop to keep files within the lifetime, without a running charge. Delete when finished to remove the VM and its files. Terminal · command example ``` rzv sandboxes stop rzv sandboxes delete ``` Sign in and select a workspace first. Owners and admins can create and change sandboxes. Availability, sizes and the running limit come from your environment. [Install and sign in with the CLI](https://runzivo.dev/docs/cli/) ## From a single command to an investigation. ### Give an agent a place to run commands Call exec from your own agent workflow, read output and check the exit status before deciding what to do next. Your integration controls the commands and credentials. [Read the exec API](https://runzivo.dev/docs/sandboxes-api-exec/) ### Validate a code change Put the code and tools your checks need in the sandbox, then run Linux CPU checks. Inspect failures before carrying the change back to your repository. [Start with the CLI](https://runzivo.dev/docs/sandboxes-quickstart/) ### Investigate interactively Open a shell, inspect files and rerun a command in the same workspace. Stop and start within the eight-hour lifetime to return to those files. [Explore the terminal](https://runzivo.dev/docs/sandboxes-terminal/) ## Choose the space. Know the boundary. Choose 2 vCPU / 8 GB, 4 vCPU / 16 GB, 8 vCPU / 32 GB or 16 vCPU / 64 GB. Available sizes depend on current host capacity; the list response shows what you can create now. Workspace disks range from 5 to 64 GiB, with 20 GiB by default. Create any offered size with the rzv CLI, API or portal. Run `rzv sandboxes list` to check current availability. Files in /workspace survive a stop and a start. Eight hours after the first start, the sandbox expires and its VM and files are deleted. Stopping does not pause the clock, and starting does not reset it. [All sizes and limits](https://runzivo.dev/docs/sandboxes-limits/) ## Pay for the time it runs. Running sandboxes use your workspace allowance or prepaid credit at the runner rate for their size. 2 vCPU counts 1×; 4 vCPU counts 2×; 8 vCPU counts 4×; 16 vCPU counts 8×. A stopped sandbox is not billed. Each start reserves 15 minutes ahead. When a run ends, only the seconds it ran are charged. Without credit, create and start are refused. [See unit-minute pricing](https://runzivo.dev/pricing/) ## Take the next step. [Sandbox overview](https://runzivo.dev/docs/sandboxes/) [Quickstart](https://runzivo.dev/docs/sandboxes-quickstart/) [Commands and terminals](https://runzivo.dev/docs/sandboxes-terminal/) [Lifecycle API](https://runzivo.dev/docs/sandboxes-api/) [Exec and terminal API](https://runzivo.dev/docs/sandboxes-api-exec/) [Limits and billing](https://runzivo.dev/docs/sandboxes-limits/) ## Coming soon ### Connect with SSH, scp, sftp and rsync Coming soon. Standard SSH access and editor connections are not available yet. [Read the guide: Connect with SSH, scp, sftp and rsync](https://runzivo.dev/docs/sandboxes-ssh/) ### The sandbox developer image Coming soon. The developer image is not available yet. Its planned tools will be signed out. [Read the guide: The sandbox developer image](https://runzivo.dev/docs/sandboxes-developer-image/) ### Persistent disks for sandboxes Coming soon. Host-local persistent disks are in development and are not available yet. [Read the guide: Persistent disks for sandboxes](https://runzivo.dev/docs/sandboxes-persistent-disks/) ### Repository access in a sandbox Coming soon. Repository tokens are not available in production yet. Automatic private-repository login is not available yet. [Read the guide: Repository access in a sandbox](https://runzivo.dev/docs/sandboxes-repositories/) ### OpenHands tasks in a sandbox Coming soon. OpenHands tasks are in development and not yet tested in a live sandbox. They are not available yet. [Read the guide: OpenHands tasks in a sandbox](https://runzivo.dev/docs/sandboxes-openhands/) --- Source: https://runzivo.dev/security/ # One job. One isolated environment. Torn down by design. Runzivo runs each eligible GitHub Actions job in a fresh Firecracker microVM. The runner and its environment are single-use. 01 ## Single-use environments Runzivo assigns each eligible job a fresh Firecracker microVM and destroys it after the job finishes, is cancelled, or cannot continue. 02 ## Repository-scoped authorization Runzivo runs jobs only for repositories you select in the GitHub App installation. Labels select a supported runner configuration but do not grant repository access. 03 ## Bounded credentials The V1 design uses short-lived GitHub App installation and JIT runner credentials. Platform and control-plane credentials stay out of customer workers. 04 ## Required host baseline Before external workloads, V1 requires restrictive process isolation, resource limits, immutable runner images, and host-enforced network controls. Runzivo will name a specific host region here once it is committed to customers. ## A fresh boundary for each job. Every eligible job runs this way today. Broader security claims wait until launch validation is complete. - A new Firecracker microVM for every job, never reused - Its own host-enforced network interface - A single-use GitHub runner registration token - Teardown requested after the job completes ## Sign-in tokens stay on the server. The customer portal keeps only an opaque session cookie in your browser and renews short-lived access tokens on the server. A session lasts 14 days without activity and 30 days at most. Signing out ends it immediately. API key changes, account security settings, and billing changes (when paid billing is enabled) ask you to confirm it's you if you have not signed in recently. [Read the sign-in and sessions guide](https://runzivo.dev/docs/sign-in/). ## Security claims stay tied to tested V1 behavior. Runzivo publishes compliance, service, and platform claims only after validation. Before accepting external workloads, Runzivo tests lifecycle, isolation, network egress, image integrity, patching, and teardown. ## Review the runner model and App permissions before installation. For a security report, contact [security@runzivo.dev](mailto:security@runzivo.dev). [Read runner documentation](https://runzivo.dev/docs/runners/) [Review App permissions](https://runzivo.dev/docs/github-app-permissions/) --- Source: https://runzivo.dev/use-cases/ # CI for developers and AI coding agents. Runzivo runs your GitHub Actions jobs, including the pull requests AI coding agents open, each in a fresh, isolated microVM. Here is what teams use it for today, what is in early access, and what is still planned. Runzivo’s current V1 scope covers approved GitHub Actions workflows on Linux x64. Runzivo proposes build-partner pilots as co-development work. Future integrations and capabilities require separate decisions. [Build with Runzivo](https://tally.so/r/lbpllN) [Discuss strategic investment](mailto:investors@runzivo.dev?subject=Strategic%20investment%20discussion) Use cases 10 use cases ## What teams use Runzivo for What teams run on Runzivo, with a status for each. ### All 10 - Test AI-generated pull requests Available today Claude, Codex, Cursor or another agent writes the code. Your GitHub Actions checks run on Runzivo, for organization repositories, and report failures before a person merges it. Best for: AI coding agents and development teams. [Learn more](https://runzivo.dev/docs/getting-started) - Run AI coding agents in GitHub Actions Not verified yet Run agent workflows such as Claude Code or Codex actions on Runzivo runners instead of building a separate runner system. Compatibility has not been verified yet. Best for: Agent developers and AI automation platforms. [Learn more](https://runzivo.dev/docs/runners) - Create CI pipelines with AI Early access · off by default Describe what to build and test. The pipeline builder drafts the GitHub Actions workflow and opens a pull request for your approval. Best for: Startups and developers new to CI. [Learn more](https://runzivo.dev/ai) - Fix failed builds with AI Early access · off by default When CI fails, the fix agent reads the logs, proposes a change to CI files and opens a reviewable pull request from a new branch. Best for: Small teams maintaining many repositories. [Learn more](https://runzivo.dev/ai) - Run each job in an isolated virtual machine Available today Every eligible job in an organization repository gets a fresh Firecracker microVM that is destroyed when it ends, instead of a shared, long-lived runner machine. Best for: Security-conscious teams and AI-generated code. [Learn more](https://runzivo.dev/security) - Test many AI changes in parallel Available today Run independent builds as agents open pull requests, with workspace limits and a visible queue. Run up to your plan's concurrent job limit. Jobs may queue when runner capacity is unavailable. Best for: Teams with many AI-assisted commits. [Learn more](https://runzivo.dev/docs/usage-limits) - Build and validate container images Available today Compile applications, build images and run checks in GitHub Actions before release. The runner image includes Docker Engine, Docker Buildx and Docker Compose v2. Best for: SaaS and backend teams. [Learn more](https://runzivo.dev/docs/runners) - Run full application test suites Available today Run unit, API and integration tests for web apps and services through your existing workflows in organization repositories, with the tools your workflow installs. Best for: Next.js, Go, Python and other application teams. [Learn more](https://runzivo.dev/docs/runners) - Control what AI-written workflows can run Early access · off by default Workflows written by the pipeline builder only run on Runzivo after a person approves them, and the approval is recorded. Best for: Organizations adopting coding agents. [Learn more](https://runzivo.dev/ai) - Automate recurring repository tasks Available today Run scheduled dependency checks, security scans and maintenance jobs from your existing GitHub Actions workflows in organization repositories. Best for: Founders, DevOps teams and maintainers. [Learn more](https://runzivo.dev/docs/configuration) Slow builds. Runner upkeep. Growing test queues. Bring one real workflow, co-fund a pilot, and shape what we build together. Use cases 6 pilots ## One real workflow. One focused pilot. These six pages describe proposed workload-fit pilots, not live vertical products. Start with the workflow that creates the clearest runner problem. ### All pilots 6 - SaaS Proposed first cohort Bring your busiest build pipeline. Co-fund a Runzivo pilot and help us tackle queue time, repeat setup, and runner maintenance, with results measured against your current setup. [Explore pilot](https://runzivo.dev/use-cases/saas) - AI teams Proposed first cohort Bring your agent-created pull requests or evaluation suite. Let’s co-build the runner setup that tests them before release, without turning your product team into a runner team. [Explore pilot](https://runzivo.dev/use-cases/ai-teams) - Agencies Proposed first cohort Bring two client pipelines. Co-build a pilot to evaluate access separation and usage tracking, so your engineers can focus on client delivery. [Explore pilot](https://runzivo.dev/use-cases/agencies) - Fintech and insurance Controlled pilot Bring a payment, policy, or reporting test suite. Co-design a pilot using synthetic data, agreed access rules, and evidence your team can review. [Explore pilot](https://runzivo.dev/use-cases/fintech) - E-commerce Focused pilot Bring your theme, storefront, or checkout tests. Let’s build and measure a repeatable runner workflow together before the next release reaches shoppers. [Explore pilot](https://runzivo.dev/use-cases/ecommerce) - Edtech Specialist partnership Bring your grading workflow. Co-build bounded execution for student submissions while your platform keeps control of assignments, scoring, and feedback. [Explore pilot](https://runzivo.dev/use-cases/edtech) ## Bring the workflow that is holding you up. If runner upkeep is taking time from your product, bring us one workflow and the runner problem behind it. Co-fund a pilot, shape the build, and judge the result. [Build with Runzivo](https://tally.so/r/lbpllN) ## Help shape Runzivo’s next build. Back Runzivo’s next stage: building CI runners with the teams that need them. Bring capital, customer access, or a workload. [Discuss strategic investment](mailto:investors@runzivo.dev?subject=Strategic%20investment%20discussion) Or email [investors@runzivo.dev](mailto:investors@runzivo.dev) directly if your browser has no mail app configured. ## A pilot is not a product claim. Each proposed pilot begins with a baseline, a named engineer on each side, an agreed budget, and written pass/fail criteria. Runzivo will treat CI integration, job disposal, cache and artifact separation, credential scope, network controls, limits, logs, host hardening, incident handling, and capacity as items to verify, not assumptions. Runzivo proposes paid or co-funded build-partner pilots with an agreed budget. These pilots are separate from the free Early Access allowance. ## Bring one workflow. We measure what changes. [Build with Runzivo](https://tally.so/r/lbpllN) Or email [partners@runzivo.dev](mailto:partners@runzivo.dev) directly if your browser has no mail app configured. --- Source: https://runzivo.dev/use-cases/agencies/ # More clients shouldn’t mean more runner maintenance. Bring two client pipelines. Co-build a pilot to evaluate access separation and usage tracking, so your engineers can focus on client delivery. Runzivo’s current V1 scope covers approved GitHub Actions workflows on Linux x64. Runzivo proposes build-partner pilots as co-development work. Future integrations and capabilities require separate decisions. [Build with Runzivo](https://tally.so/r/lbpllN) Runzivo proposes paid or co-funded build-partner pilots with an agreed budget. These pilots are separate from the free Early Access allowance. ## One pain. One workload. A focused way to evaluate the workflow. Each client repository can add another build environment and another layer of runner administration. Reusable build environments across client repositories with scoped credentials, caches, and usage tracking. Bring two real client pipelines and work with Runzivo on a proposed setup that gives each client a clearly defined scope. ## Who should bring this workflow to Runzivo? Buyer Agency owner or delivery lead. Qualification The partner needs two real client pipelines and authority to use the associated code in a pilot. ## Use the workflow evidence, not a promise. Each measure starts from your current baseline. Runzivo publishes no result before the pilot measures it. Pilot measures Per pilot Setup time per client Compared with your baseline Maintenance hours Compared with your baseline Usage attribution Compared with your baseline Cross-client access tests Compared with your baseline ## Agree the terms. Then measure. Bring two real client pipelines and work with Runzivo on a proposed setup that gives each client a clearly defined scope. ### Pilot checklist - - - - - - ## Bring the workflow. Set the baseline. Judge the result. [Build with Runzivo](https://tally.so/r/lbpllN) Or email [partners@runzivo.dev](mailto:partners@runzivo.dev) directly if your browser has no mail app configured. --- Source: https://runzivo.dev/use-cases/ai-teams/ # More generated code. The same testing bottleneck. Bring your agent-created pull requests or evaluation suite. Let’s co-build the runner setup that tests them before release, without turning your product team into a runner team. Runzivo’s current V1 scope covers approved GitHub Actions workflows on Linux x64. Runzivo proposes build-partner pilots as co-development work. Future integrations and capabilities require separate decisions. [Build with Runzivo](https://tally.so/r/lbpllN) Runzivo proposes paid or co-funded build-partner pilots with an agreed budget. These pilots are separate from the free Early Access allowance. ## One pain. One workload. A focused way to evaluate the workflow. More generated changes still need dependable validation before they reach a release branch. Test agent-created pull requests, run CPU-compatible evaluation suites, and validate SDK or package changes. Start with one CPU-compatible validation workflow and agree how the current setup will be measured before changing the runner path. ## Who should bring this workflow to Runzivo? Buyer AI platform lead or developer-tools founder. Qualification Identify CPU-only workloads and any calls to external model APIs. GPU execution sits outside this initial pilot, is not part of V1, and is a separate product decision. ## Use the workflow evidence, not a promise. Each measure starts from your current baseline. Runzivo publishes no result before the pilot measures it. Pilot measures Per pilot Time to validated change Compared with your baseline Evaluation turnaround Compared with your baseline Repeat-run consistency Compared with your baseline Cost per completed suite Compared with your baseline ## Agree the terms. Then measure. Start with one CPU-compatible validation workflow and agree how the current setup will be measured before changing the runner path. ### Pilot checklist - - - - - - ## Bring the workflow. Set the baseline. Judge the result. [Build with Runzivo](https://tally.so/r/lbpllN) Or email [partners@runzivo.dev](mailto:partners@runzivo.dev) directly if your browser has no mail app configured. --- Source: https://runzivo.dev/use-cases/ecommerce/ # Find storefront problems before customers do. Bring your theme, storefront, or checkout tests. Let’s build and measure a repeatable runner workflow together before the next release reaches shoppers. Runzivo’s current V1 scope covers approved GitHub Actions workflows on Linux x64. Runzivo proposes build-partner pilots as co-development work. Future integrations and capabilities require separate decisions. [Build with Runzivo](https://tally.so/r/lbpllN) Runzivo proposes paid or co-funded build-partner pilots with an agreed budget. These pilots are separate from the free Early Access allowance. ## One pain. One workload. A focused way to evaluate the workflow. Storefront checks are easy to defer when feedback is slow or runner cost makes them hard to run consistently. Theme performance checks, frontend builds, and customer-supplied checkout regression tests against test environments. Bring the checks you already run, then co-design a repeatable workflow and compare feedback time against the current process. ## Who should bring this workflow to Runzivo? Buyer Commerce engineering lead or agency technical director. Qualification Identify which checks already run and which are skipped because of time or runner cost. ## Use the workflow evidence, not a promise. Each measure starts from your current baseline. Runzivo publishes no result before the pilot measures it. Pilot measures Per pilot Feedback time Compared with your baseline Completed test coverage Compared with your baseline Test-environment failures Compared with your baseline Cost per run Compared with your baseline ## Agree the terms. Then measure. Bring the checks you already run, then co-design a repeatable workflow and compare feedback time against the current process. ### Pilot checklist - - - - - - ## Bring the workflow. Set the baseline. Judge the result. [Build with Runzivo](https://tally.so/r/lbpllN) Or email [partners@runzivo.dev](mailto:partners@runzivo.dev) directly if your browser has no mail app configured. --- Source: https://runzivo.dev/use-cases/edtech/ # Teach the course. Don’t run the runner fleet. Bring your grading workflow. Co-build bounded execution for student submissions while your platform keeps control of assignments, scoring, and feedback. Runzivo’s current V1 scope covers approved GitHub Actions workflows on Linux x64. Runzivo proposes build-partner pilots as co-development work. Future integrations and capabilities require separate decisions. [Build with Runzivo](https://tally.so/r/lbpllN) Runzivo proposes paid or co-funded build-partner pilots with an agreed budget. These pilots are separate from the free Early Access allowance. ## One pain. One workload. A focused way to evaluate the workflow. Running grading workflows at peak submission time can turn execution infrastructure into a separate operational concern. Run existing grading tests against student or candidate submissions with scoped access and execution limits. Work with the platform owner on a bounded proof of concept for one existing grading workflow and define pass/fail conditions before scale. ## Who should bring this workflow to Runzivo? Buyer Assessment-platform founder or engineering lead, or a course technical owner. Qualification Establish who owns grading, identity, repositories, and the interface, then map peak submission loads. ## Use the workflow evidence, not a promise. Each measure starts from your current baseline. Runzivo publishes no result before the pilot measures it. Pilot measures Per pilot Time to feedback Compared with your baseline Cost per submission Compared with your baseline Peak queue time Compared with your baseline Timeout enforcement Compared with your baseline Separation tests Compared with your baseline ## Agree the terms. Then measure. Work with the platform owner on a bounded proof of concept for one existing grading workflow and define pass/fail conditions before scale. ### Pilot checklist - - - - - - ## Bring the workflow. Set the baseline. Judge the result. [Build with Runzivo](https://tally.so/r/lbpllN) Or email [partners@runzivo.dev](mailto:partners@runzivo.dev) directly if your browser has no mail app configured. --- Source: https://runzivo.dev/use-cases/fintech/ # Move releases forward. Keep the controls in view. Bring a payment, policy, or reporting test suite. Co-design a pilot using synthetic data, agreed access rules, and evidence your team can review. Runzivo’s current V1 scope covers approved GitHub Actions workflows on Linux x64. Runzivo proposes build-partner pilots as co-development work. Future integrations and capabilities require separate decisions. [Build with Runzivo](https://tally.so/r/lbpllN) Runzivo proposes paid or co-funded build-partner pilots with an agreed budget. These pilots are separate from the free Early Access allowance. ## One pain. One workload. A focused way to evaluate the workflow. Security owners need a controlled review of workflow scope, access rules, and evidence before any broader rollout. Payment API, policy-rule, reconciliation, and reporting-code regression tests using synthetic data. Co-design a controlled workflow with synthetic data, agreed access rules, and written evidence requirements before any broader rollout. ## Who should bring this workflow to Runzivo? Buyer Engineering or platform lead together with the security owner. Qualification Confirm which code, secrets, integrations, and vendor checks the proposed pilot may use. ## Use the workflow evidence, not a promise. Each measure starts from your current baseline. Runzivo publishes no result before the pilot measures it. Pilot measures Per pilot Test turnaround Compared with your baseline Access-control results Compared with your baseline Cleanup evidence Compared with your baseline Agreed log completeness Compared with your baseline ## Agree the terms. Then measure. Co-design a controlled workflow with synthetic data, agreed access rules, and written evidence requirements before any broader rollout. ### Pilot checklist - - - - - - ## Bring the workflow. Set the baseline. Judge the result. [Build with Runzivo](https://tally.so/r/lbpllN) Or email [partners@runzivo.dev](mailto:partners@runzivo.dev) directly if your browser has no mail app configured. --- Source: https://runzivo.dev/use-cases/saas/ # Your next release shouldn’t wait on runner upkeep. Bring your busiest build pipeline. Co-fund a Runzivo pilot and help us tackle queue time, repeat setup, and runner maintenance, with results measured against your current setup. Runzivo’s current V1 scope covers approved GitHub Actions workflows on Linux x64. Runzivo proposes build-partner pilots as co-development work. Future integrations and capabilities require separate decisions. [Build with Runzivo](https://tally.so/r/lbpllN) Runzivo proposes paid or co-funded build-partner pilots with an agreed budget. These pilots are separate from the free Early Access allowance. ## One pain. One workload. A focused way to evaluate the workflow. Runner queues, repeat setup, and fleet maintenance can pull engineering attention away from shipping the product. Linux builds, unit and integration tests, package creation, and pull-request checks. Bring one real workflow, an agreed pilot budget, a named engineer on each side, a baseline, and written pass/fail criteria. ## Who should bring this workflow to Runzivo? Buyer Head of engineering or platform lead. Qualification Confirm that delay comes from runner queues, provisioning, or maintenance, rather than slow tests or human review. ## Use the workflow evidence, not a promise. Each measure starts from your current baseline. Runzivo publishes no result before the pilot measures it. Pilot measures Per pilot p95 queue time Compared with your baseline End-to-end job time Compared with your baseline Infrastructure failures Compared with your baseline Operator hours Compared with your baseline Cost per successful build Compared with your baseline ## Agree the terms. Then measure. Bring one real workflow, an agreed pilot budget, a named engineer on each side, a baseline, and written pass/fail criteria. ### Pilot checklist - - - - - - ## Bring the workflow. Set the baseline. Judge the result. [Build with Runzivo](https://tally.so/r/lbpllN) Or email [partners@runzivo.dev](mailto:partners@runzivo.dev) directly if your browser has no mail app configured. --- Source: https://runzivo.dev/blog/ # Notes from the build. Engineering notes and product lessons from building fast, secure CI runners. Announcements Published November 1, 2026 ## Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published November 1, 2026 ## Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ## Team and Business plans are available Monthly or yearly plans with included unit-minutes, bought from Billing & Credits in the portal. [Read the post](https://runzivo.dev/blog/team-and-business-plans/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ## Agent Sandboxes are available An isolated Linux microVM per sandbox, run from the rzv CLI or the API, and billed only for the seconds it runs. [Read the post](https://runzivo.dev/blog/agent-sandboxes/) Ditah Kumbong 2 min read Tutorials Published October 27, 2026 ## Stop writing complex Bash inside GitHub Actions YAML Move loops, retries and cleanup out of run: blocks into scripts you can lint, test and run locally. [Read the post](https://runzivo.dev/blog/stop-writing-complex-bash-in-github-actions-yaml/) Ditah Kumbong 4 min read Engineering Published October 22, 2026 ## How to build with AI in 2026 One team of seven Codex agents, how it is split, and what it costs. [Read the post](https://runzivo.dev/blog/how-to-build-with-ai-in-2026/) Ditah Kumbong 4 min read Announcements Published October 21, 2026 Last updated October 22, 2026 ## Clearer setup guidance and CLI 0.9.0 docs CLI 0.9.0 documentation is available now. The portal updates below have shipped in Core. [Read the post](https://runzivo.dev/blog/tonight-release-cli-docs-and-pending-portal-updates/) Ditah Kumbong 2 min read Announcements Published October 21, 2026 ## Why Runzivo does not ask for repository administration Runzivo withdraws the earlier plan to support personal-account repositories through GitHub's Administration permission. [Read the post](https://runzivo.dev/blog/why-runzivo-does-not-ask-for-repository-administration/) Ditah Kumbong 2 min read Announcements Published October 20, 2026 ## Onboard your AI coding agent to Runzivo Copy a setup prompt that helps an AI coding agent prepare a GitHub Actions workflow for Runzivo. [Read the post](https://runzivo.dev/blog/onboard-your-ai-coding-agent-to-runzivo/) Ditah Kumbong 2 min read Announcements Published October 20, 2026 ## Runzivo is live for Early Access testing 10 places for Early Access testing, with a monthly runner-minutes allowance per workspace. [Read the post](https://runzivo.dev/blog/runzivo-early-access-testers/) Ditah Kumbong 3 min read Tutorials Published October 20, 2026 ## 10 GitHub Actions best practices for reliable CI Small YAML, real scripts, clear failures, cleanup and least privilege, each linked to tested code. [Read the post](https://runzivo.dev/blog/ten-github-actions-best-practices/) Ditah Kumbong 5 min read Engineering Published October 19, 2026 ## Faster GitHub Actions: how I cut CI for a small change from 85 min to 9 Five fixes for slow GitHub Actions pipelines, with run data from cutting my own CI from 85 min to 9. [Read the post](https://runzivo.dev/blog/faster-github-actions-ci/) Ditah Kumbong 5 min read Engineering Published October 19, 2026 ## Moving my Headscale access rules into the database How I moved my VPN access rules from a file into Headscale's database, and the one step that needs care. [Read the post](https://runzivo.dev/blog/moving-headscale-access-rules-to-the-database/) Ditah Kumbong 3 min read Company Published September 13, 2026 Last updated October 18, 2026 ## Why I Built Runzivo: Faster CI. Less Waiting. Why CI compute should fade into the background, starting with managed runners for GitHub Actions. [Read the post](https://runzivo.dev/blog/why-runzivo/) Ditah Kumbong 5 min read --- Source: https://runzivo.dev/blog/agent-sandboxes/ # Agent Sandboxes are available Give a coding agent its own Linux machine for a working session, then throw it away. Ditah Kumbong Founder October 31, 2026 2 min read Reading time 2 min left Share Agent Sandboxes are available in every workspace. A sandbox is an isolated Linux machine for a coding agent, or for you, to work in for a session. Install rzv 0.20.0 and run `rzv sandboxes create` to start one. ## What a sandbox is Each sandbox is a Firecracker microVM with its own disk. Files in `/workspace` survive a stop and a start. A sandbox lasts eight hours from its first start. Stopping it does not pause that time, and when it ends the machine and its files are deleted. ## How to use it Start with the `rzv` CLI. It creates a sandbox, runs commands with streamed output and opens a terminal with `rzv sandboxes ssh`: sh ``` rzv sandboxes create --name agent-1 rzv sandboxes exec -- npm test rzv sandboxes ssh rzv sandboxes delete ``` Agents can call the customer API directly: create a sandbox, run a command and read its output as a stream, or open the terminal as a WebSocket. Runzivo does not log the commands or their output. Start with the [quickstart](https://runzivo.dev/docs/sandboxes-quickstart/). In the portal, open Build & Deploy, then Sandboxes, and select New Sandbox. The sandbox page has a terminal while it runs. ## Billing A running sandbox uses unit-minutes from your allowance or prepaid credit, at the same rate as a runner of its size. A stopped sandbox is not billed. See [limits and billing](https://runzivo.dev/docs/sandboxes-limits/) for how runs are charged and what happens when credit runs out. ## Limits A workspace can run two sandboxes at once by default, and the lifetime cannot be extended. The [Agent Sandboxes guide](https://runzivo.dev/docs/sandboxes/) links the sizes, limits and API reference. ## More from the blog Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published November 1, 2026 ### Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ### Team and Business plans are available Monthly or yearly plans with included unit-minutes, bought from Billing & Credits in the portal. [Read the post](https://runzivo.dev/blog/team-and-business-plans/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/audit-status-redesign/ # Audit & Status: clearer evidence for your investigations Read the current state, inspect the exceptions and follow the evidence without losing your time range. Ditah Kumbong Founder November 1, 2026 9 min read Reading time 9 min left Share ## Three views, one time range The redesigned Audit & Status page is available in the customer portal. Overview brings current component state, execution summaries and recent workspace changes together. Execution assurances opens the records behind the job and microVM counts. Audit log focuses on workspace activity: who acted, what happened, which resource was involved and when it happened. Choose the last 24 hours, 7, 30 or 60 days, or a custom range. The same range applies to all three views, and the tab and range stay in the URL, so a saved link opens the same view. Custom dates are limited by the 180-day activity retention. Unavailable days show the reason. Displayed times follow your time-zone preference. ## Read the exceptions, not a blanket claim A clean summary should not hide a forced stop or an unfinished teardown. Execution assurances now separates clean teardowns, forced stops, records awaiting teardown and leases still held by a host agent. Each exception has its own count. Forced stops show the recorded end-reason codes, and the summary only makes claims supported by the counts for the selected window. The interactive donut works with a pointer or keyboard. Select an outcome to filter the evidence table. Remove its filter chip to see the wider list again. Counts still describe the whole time window rather than only the current page of evidence. Expand a row to inspect its lease generation, issue and end times, status, recorded end reason and available GitHub execution evidence. ## A practical investigation Suppose a job did not finish as expected. Open Execution assurances, select the time range around the run and choose the forced-stop outcome. Expand the matching evidence row and compare its recorded end reason with the workflow run in GitHub. Then open Audit log with the same range to inspect relevant workspace changes. This keeps the operational evidence and administrative activity separate while letting you examine both in context. Expand an audit entry to inspect the actor, action, target, time and origin information available for that event. Credential-looking text is scrubbed from activity descriptions, targets and user agents before display, including activity reads and CSV export. Redaction is a precaution, not permission to put secrets in names, logs or support material. ## Know when the data was refreshed Automatic refresh depends on the range. 30 and 60 days: every 60 seconds. 7 days: every 15 seconds. 24 hours: every 3 seconds while the running count is above zero, otherwise every 15 seconds. While automatic refresh is on, returning to the tab also refreshes the page. The update indicator shows the age of the data. Pause stops automatic refresh. Resume refreshes the view and starts it again. Hidden tabs do not keep making refresh requests. A custom range is a fixed historical window, so automatic updates are off and a manual refresh remains available. This is periodic refresh, not a job-event stream. A running count or an active lease is not a claim that the job finished successfully. Keep the time range, last update and underlying evidence in view when interpreting an exception. ## What these records do not prove The page states the limits of the available data. A host claim is recorded, not the microVM’s boot time. Some Runzivo-revoked leases have no recorded reason. Audit entries do not provide before-and-after values. Current component state is shown without an invented uptime percentage or historical incident timeline, because component history is not recorded here. The redesign makes existing evidence easier to read. It is not a new service-level agreement, a guarantee that every teardown was clean, or an independent certification. [Open Audit & Status in your workspace](https://app.runzivo.dev/audit) ## More from the blog Announcements Published November 1, 2026 ### Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ### Team and Business plans are available Monthly or yearly plans with included unit-minutes, bought from Billing & Credits in the portal. [Read the post](https://runzivo.dev/blog/team-and-business-plans/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ### Agent Sandboxes are available An isolated Linux microVM per sandbox, run from the rzv CLI or the API, and billed only for the seconds it runs. [Read the post](https://runzivo.dev/blog/agent-sandboxes/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/ # Coming soon: Sandbox developer workflows Guides to workflows that are not available yet. Ditah Kumbong Founder November 1, 2026 2 min read Reading time 2 min left Share ## What’s coming SSH, editor connections, the developer image, repository tokens and OpenHands tasks are Coming soon for Agent Sandboxes. They are not available in production yet. SSH needs a CLI release that supports it. No such release is available yet. The guides describe planned workflows, not public access or a live customer demonstration. - [Coming soon: SSH, file transfer and Remote SSH](https://runzivo.dev/docs/sandboxes-ssh/) - [Coming soon: the signed-out developer image](https://runzivo.dev/docs/sandboxes-developer-image/) - [Coming soon: scoped repository tokens](https://runzivo.dev/docs/sandboxes-repositories/) - [Coming soon: bounded OpenHands tasks](https://runzivo.dev/docs/sandboxes-openhands/) - [Coming soon: Docker layer cache](https://runzivo.dev/docs/docker-layer-cache/) - [Coming soon: persistent disks](https://runzivo.dev/docs/sandboxes-persistent-disks/) Check this page for status. We have not set a launch date. No price has been announced. The live [Audit & Status redesign](https://runzivo.dev/blog/audit-status-redesign/) is a separate release. ## More from the blog Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published October 31, 2026 ### Team and Business plans are available Monthly or yearly plans with included unit-minutes, bought from Billing & Credits in the portal. [Read the post](https://runzivo.dev/blog/team-and-business-plans/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ### Agent Sandboxes are available An isolated Linux microVM per sandbox, run from the rzv CLI or the API, and billed only for the seconds it runs. [Read the post](https://runzivo.dev/blog/agent-sandboxes/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/faster-github-actions-ci/ # Faster GitHub Actions: how I cut CI for a small change from 85 min to 9 Run only what changed, test once, keep caches on the runner, let tool caches work, and measure. Ditah Kumbong Founder October 19, 2026 5 min read Reading time 5 min left Share In October I merged a small fix to the customer portal. It touched two files in the portal and no Go code. Before it could ship, CI ran three times: 1. Push to `main`: every job, 35m 35s. 2. A manual dispatch for the race and PostgreSQL integration tests: 32m 59s, including a 20-minute timeout and a re-run. 3. Push to the release branch: every job again, 16m 57s. That is 85.5 min of CI for a change the Go jobs had nothing to check. CI for one portal fix Before and after Total CI time, one portal-only change Down 89%: 85m 31s to 9m 23s Set up Go, per job Down from 8 to 11 min to 1 to 13 s Go, race and PostgreSQL jobs Skipped for a portal-only change Time jobs spent waiting to start About 1.7 min of the 9 min run The slowest step in the first run was `Set up Go`, which took 8 to 11 min in the Go, Node and Linux client jobs. Here are the five fixes. Each works on GitHub-hosted and self-hosted runners. Tick them off as you go. ### The five fixes - - - - - ## 1. Run only what changed I keep one map from paths to components. CI and the release script both read it. Simplified: json ``` { "components": { "portal": { "paths": ["apps/portal/**", "packages/**", "pnpm-lock.yaml"] }, "core": { "paths": ["internal/**", "go.mod", "migrations/**"] }, "ci": { "forceAll": true, "paths": [".github/**", "scripts/ci/**"] } }, "ignored": ["docs/**", "**/*.md"] } ``` A first `changes` job diffs the push against the previous commit and writes one output per component. A file that matches no component runs everything, and so does a change to CI itself. Each job then checks its output: yaml ``` go-fast: needs: changes if: needs.changes.outputs.core == 'true' ``` Why not the built-in `paths` filter? If a workflow is skipped by path filtering, its checks stay "Pending", and a pull request that requires them can't merge ([GitHub docs](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax)). Job-level `if:` avoids that, but a skipped job reports "Success" ([GitHub docs](https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-jobs-with-conditions)). So if the `changes` job itself fails, every job after it skips and looks green. The fix is one gate job that always runs, needs every other job, and fails on anything other than success or skipped. Make it the only required check. Simplified: yaml ``` ci-gate: name: CI gate if: always() needs: [changes, format, go-fast, node-fast] steps: - env: NEEDS_JSON: ${{ toJSON(needs) }} run: ./scripts/ci/02-ci-gate.sh ``` The script loops over `NEEDS_JSON` with `jq` and exits non-zero on `failure` or `cancelled`. Logic like this belongs in a script you can run locally, not in YAML ([rule 1 of the CI playbook](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/docs/best-practices.md)). ## 2. Test once The race and PostgreSQL tests used to wait for a manual dispatch, so every change needed a second run. Then the release branch ran everything again on the same commit. Now the expensive suites run automatically on every push to `main` that changes a Go component. The next step is to promote the commit that already passed on `main` instead of testing it again on a release branch. ## 3. Keep caches on the runner A self-hosted runner's disk survives between jobs. That is a cache you already have. I had `actions/setup-go` with caching on. Each job downloaded a 4.6 GB archive and unpacked it into a home directory that many runner processes on the same machine shared. In each of those jobs, `tar` printed "Cannot open: File exists" 22,585 times. In the trusted run, the PostgreSQL job hit its 20-minute timeout inside `Set up Go`. I turned the action caches off, so jobs use the Go and pnpm caches already on the runner's data disk: yaml ``` - uses: actions/setup-go@ # v7.0.0 with: go-version-file: go.mod cache: false ``` The Node and client jobs also dropped `cache: pnpm` from `actions/setup-node`. `Set up Go` now takes 1 to 13 s. I have since given each runner its own cache directories too, so parallel jobs never unpack into the same place. On GitHub-hosted runners every job starts clean, so `actions/cache` or the `cache` input of `setup-*` actions is the right tool. Key it on the lockfile. GitHub removes entries not used for 7 days ([dependency caching reference](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching)). ## 4. Let tool caches do their job Go caches passing test results. A result is reused when the test binary, the flags, and the files and environment variables the test reads are unchanged. The output then says `(cached)` ([go test docs](https://pkg.go.dev/cmd/go#hdr-Test_packages)). My first run after the change touched no Go code. All 35 race-test packages with tests came from the cache, and the job took 8 s. `-count=1` turns this off. Use it only where a test depends on something Go can't see, like the PostgreSQL tests. ## 5. Measure before and after This lists the slowest steps of a run: bash ``` gh run view --json jobs --jq '[.jobs[] | .name as $job | .steps[] | {job: $job, step: .name, s: ((.completedAt | fromdate) - (.startedAt | fromdate))}] | sort_by(-.s) | .[:3][] | [.s, .job, .step] | @tsv' ``` On my first run it printed `Set up Go` at 642, 537 and 485 seconds. That pointed at the cache, not the tests. ## My numbers | Run | What | Elapsed | | --- | --- | --- | | 39186521120 | push to `main`, every job | 35m 35s | | 39189753000 | manual race and PostgreSQL run | 32m 59s | | 39192328603 | release branch, every job again | 16m 57s | | **Before** | | **85m 31s** | | 39194529504 | push to `main`, race and PostgreSQL included | **9m 23s** | The run after the change edited CI files, so it ran every job. A portal-only change now skips the Go, race and PostgreSQL jobs. About 1.7 min of the 9 were jobs waiting to start. One piece is left: releases still re-run CI on the release branch. I will retire that run and build only changed images. ## If you'd rather not run runners at all [Runzivo](https://runzivo.dev/) runs managed Linux x64 runners for GitHub Actions. Each job gets a fresh Firecracker microVM that is destroyed when the job ends. To try it, change one label: yaml ```yaml runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb ``` Runzivo is in Early Access, with a free monthly allowance per workspace ([getting started](https://runzivo.dev/docs/getting-started/)). Because each job starts clean, use fix 3's advice for hosted runners there. The numbers above came from my CI changes, not from switching runners. ## More from the blog Tutorials Published October 27, 2026 ### Stop writing complex Bash inside GitHub Actions YAML Move loops, retries and cleanup out of run: blocks into scripts you can lint, test and run locally. [Read the post](https://runzivo.dev/blog/stop-writing-complex-bash-in-github-actions-yaml/) Ditah Kumbong 4 min read Tutorials Published October 20, 2026 ### 10 GitHub Actions best practices for reliable CI Small YAML, real scripts, clear failures, cleanup and least privilege, each linked to tested code. [Read the post](https://runzivo.dev/blog/ten-github-actions-best-practices/) Ditah Kumbong 5 min read Engineering Published October 19, 2026 ### Moving my Headscale access rules into the database How I moved my VPN access rules from a file into Headscale's database, and the one step that needs care. [Read the post](https://runzivo.dev/blog/moving-headscale-access-rules-to-the-database/) Ditah Kumbong 3 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/how-to-build-with-ai-in-2026/ # How to build with AI in 2026 You do not need a different AI tool for every job. You need one team, clear rules and the right model for each task. Ditah Kumbong Founder October 22, 2026 4 min read Reading time 4 min left Share You do not need a different AI tool for every job. One team of seven Codex agents covers planning, building, testing and review for the work I do. The same names and the same setup work in every repository. ## One team is enough Each task gets its own worktree, so agents never share a half-finished branch. The team is the same in every repository. Only the task changes. ## The seven agents | Agent | Owns | Model and reasoning | | --- | --- | --- | | codex-lead | Architecture, planning, assigning work, coordination | GPT-6 Astra, extra-high reasoning | | codex-feature | Full-stack features, APIs, databases, billing | GPT-6.1 Sol, high reasoning | | codex-ui | Front-end code, component library, responsive layout, accessibility | GPT-6.1 Sol, medium reasoning | | codex-infra | Infrastructure as code, containers, CI/CD pipelines | GPT-6.1 Sol, high reasoning | | codex-integrations | Source hosts, payments, identity, external APIs | GPT-6.1 Sol, high reasoning | | codex-qa | Automated, browser, integration, failure and performance tests | GPT-6.1 Sol, high reasoning | | codex-review | Independent review: security, concurrency, billing, architecture | GPT-6 Astra, extra-high reasoning | The lead plans the work and hands each piece to one builder. The four builders write the code. QA proves it works. Review checks it without having written any of it. One task, one team 1 agent 1 running $0.00 C codex-lead GPT-6 Astra · extra-high Running Ship a usage export for customers $0.00 · 0s **codex-lead** Plans the work, splits it into pieces and assigns each piece to one builder. It does not write the code it hands out. Click a card to see what that agent owns. Times run 40× faster; costs are example values. ## The rules - **The lead assigns and coordinates.** It does not write the feature code it hands out. - **Builders own their branches and pull requests.** When two changes touch the same files, the builders talk before either merges. - **Review stays independent.** Review never reviews code it wrote, and it does not edit the code it reviews. - **Billing and security need real tests.** A passing run is not enough. The tests must fail when the rule breaks. - **Trivial work goes to a small model.** A rename or a typo fix does not need an eighth agent. The small model is the fallback. ## What it costs The team runs two GPT-6 Astra agents and five GPT-6.1 Sol agents. GPT-6 Astra is used only where judgement matters most: the lead plans the work and review checks it. The four builders and QA run on GPT-6.1 Sol, four at high reasoning and the UI agent at medium. Three habits keep the bill down: - Match the model to the task. Most of the work does not need GPT-6 Astra. - Set reasoning effort per task. Medium is enough for UI polish. High is for logic, billing and infrastructure. - Share one team across repositories. Do not build a separate team for each project. ## When to add another harness Codex alone is enough for this work. Add another agent tool only when a task needs something Codex cannot do. Until then, one harness with one team is simpler to run, review and pay for. The coordination skill this team runs on is published as [zs-orchestrate](https://github.com/zsoftly/ai-craft/blob/main/skills/zs-orchestrate/SKILL.md). ## Try it Start with the lead on a small, real task. Let it split the work, review what comes back, and measure the cost after a week. Then decide whether the team needs more agents. ## More from the blog Engineering Published October 19, 2026 ### Faster GitHub Actions: how I cut CI for a small change from 85 min to 9 Five fixes for slow GitHub Actions pipelines, with run data from cutting my own CI from 85 min to 9. [Read the post](https://runzivo.dev/blog/faster-github-actions-ci/) Ditah Kumbong 5 min read Engineering Published October 19, 2026 ### Moving my Headscale access rules into the database How I moved my VPN access rules from a file into Headscale's database, and the one step that needs care. [Read the post](https://runzivo.dev/blog/moving-headscale-access-rules-to-the-database/) Ditah Kumbong 3 min read Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/moving-headscale-access-rules-to-the-database/ # Moving my Headscale access rules into the database From a file in git to the database, edited through the API. Ditah Kumbong Founder October 19, 2026 3 min read Reading time 3 min left Share I reach my private hosts over a mesh network. I run that network myself, with [Headscale](https://github.com/juanfont/headscale) as the control server and [Headplane](https://github.com/tale/headplane) as the web interface. This post explains why, and how I now manage access without editing files on the server. ## Why a self-hosted control server Tailscale clients need a control server to enrol devices and distribute access rules. Headscale is an open-source, self-hosted implementation of that control server, licensed under BSD-3-Clause. The control plane runs on a machine I operate, under my own access rules. ## Managing it in a browser Headplane is a web UI for Headscale. It shows machines, users, DNS, and the access control list. I upgraded it from 0.7.1 to 0.8.1 with a single version pin in my infrastructure repository, and the health check stayed green. ## Access rules in the database, not a file My access rules started as a JSON file reviewed in git. Headscale can also store the policy in its database. Once the policy lives there, you can edit it through the API, using `GET` and `PUT` on `/api/v1/policy`. Headscale validates the policy before it saves, so a broken policy is refused rather than loaded. The switch has one step that needs care. In file mode, Headscale rejects policy writes, so the policy cannot be imported first. Headscale's default with no policy loaded is to allow all traffic, so the live policy has to be stored straight after the switch. I did this on my shared VPN and confirmed that the stored policy matched the live one. ## What I am thankful for Thank you to the maintainers and contributors of Headscale and Headplane. A control server that works with standard Tailscale clients is hard to build, and keeping it working across releases takes steady effort. Their releases, issues, and changelogs made it possible for me to run my own network. ## Try it Start with the Headscale documentation and the Headplane install guide. Test access-rule changes on a non-production network first, and use API keys with short expiries for automation. Runzivo runs managed GitHub Actions runners, with every job in a fresh, single-use microVM. Sign up at [app.runzivo.dev](https://app.runzivo.dev/). ## More from the blog Engineering Published October 22, 2026 ### How to build with AI in 2026 One team of seven Codex agents, how it is split, and what it costs. [Read the post](https://runzivo.dev/blog/how-to-build-with-ai-in-2026/) Ditah Kumbong 4 min read Engineering Published October 19, 2026 ### Faster GitHub Actions: how I cut CI for a small change from 85 min to 9 Five fixes for slow GitHub Actions pipelines, with run data from cutting my own CI from 85 min to 9. [Read the post](https://runzivo.dev/blog/faster-github-actions-ci/) Ditah Kumbong 5 min read Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/onboard-your-ai-coding-agent-to-runzivo/ # Onboard your AI coding agent to Runzivo A short prompt asks your coding agent to prepare a pull request with an available Runzivo runner label. Ditah Kumbong Founder October 20, 2026 2 min read Reading time 2 min left Share The workspace home now has an **Onboard your agent to Runzivo** button. It copies a prompt for Claude, ChatGPT, Gemini, Grok, or Cursor. The same button appears on sign-in and in the public preview. ## Copy the prompt Open your workspace home and select the button. It adds your workspace context to the prompt. Paste it into your coding agent from the repository you want to configure. text ``` Set up this repository to run GitHub Actions on Runzivo. First read https://app.runzivo.dev/agents.md and this repository's instructions. They take priority over the instructions below. Check that the Runzivo GitHub App is installed for this repository. You cannot install it. If it is missing, tell the user to use https://app.runzivo.dev/setup. This is a public guide; confirm the workspace's available labels in Setup before editing. Inspect .github/workflows. Change only runs-on for Linux x64 jobs to an available Runzivo label. Keep everything else unchanged. Never read or write secrets. Leave jobs for other platforms unchanged. Open a pull request for the change; only make a standalone/direct commit if the user asks. Follow this repository's publishing permissions. ``` ## What it changes The agent checks your workspace's available Linux x64 runner labels before it edits a workflow. It changes only `runs-on` for eligible jobs and leaves other jobs unchanged. The prompt instructs it to propose the change in a pull request for your review. Review the pull request, then run a job and check its logs in Runzivo. The built-in pipeline builder and CI fix agent remain early access features and are not available to customers yet. ## Read the instructions Read the public [agent setup page](https://app.runzivo.dev/agents), the [Markdown instructions](https://app.runzivo.dev/agents.md), or [llms.txt](https://app.runzivo.dev/llms.txt). Start with the [getting started guide](https://runzivo.dev/docs/getting-started/) if you have not connected a repository yet. ## More from the blog Announcements Published October 20, 2026 ### Runzivo is live for Early Access testing 10 places for Early Access testing, with a monthly runner-minutes allowance per workspace. [Read the post](https://runzivo.dev/blog/runzivo-early-access-testers/) Ditah Kumbong 3 min read Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published November 1, 2026 ### Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/runzivo-early-access-testers/ # Runzivo is live for Early Access testing Connect a repository, run a job, and tell me what breaks. Ditah Kumbong Founder October 20, 2026 3 min read Reading time 3 min left Share Runzivo is live for Early Access testing. I am opening 10 places for this round, so I can learn from real repositories before I make the product bigger. ## What Runzivo is Runzivo runs managed Linux x64 runners for GitHub Actions. Each job gets a fresh microVM, and it is destroyed when the job ends. To use it, you install the GitHub App, choose your repositories, and change one line in a workflow: yaml ```yaml runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb ``` ## What testers get Each workspace includes a monthly allowance of runner minutes. You do not need to use all of it. The goal is to run real jobs and tell me what happened. See [pricing](https://runzivo.dev/pricing/) for the details. ## What to try 1. Sign up at app.runzivo.dev. 2. Create your workspace and check the settings. 3. Connect your GitHub account or organization. 4. Add one repository. A small test project is fine. 5. Run a job and check that it passes. 6. Open the job logs and check what happened. 7. Make a small change and run another job. 8. Tell me what worked, what failed, and what was confusing. ## Ground rules - Use real repositories or small test projects. - Run actual jobs and check their results. - Report errors you hit. - No spam, automated abuse, or repeated jobs that add nothing. ## How to join Sign up at [app.runzivo.dev](https://app.runzivo.dev/), or request a place on the [Early Access page](https://runzivo.dev/early-access/). Tell me which workflow hurts the most. That is the test I want to run first. ## More from the blog Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published November 1, 2026 ### Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ### Team and Business plans are available Monthly or yearly plans with included unit-minutes, bought from Billing & Credits in the portal. [Read the post](https://runzivo.dev/blog/team-and-business-plans/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/stop-writing-complex-bash-in-github-actions-yaml/ # Stop writing complex Bash inside GitHub Actions YAML A three-line rule for run: blocks, and scripts you can lint, test and run locally. Ditah Kumbong Founder October 27, 2026 4 min read Reading time 4 min left Share A `run:` block starts as one line. Then someone adds a retry. Then a check. Six months later it is 50 lines of Bash inside YAML, and nobody can run it outside CI. This post shows how to move that logic into scripts, using the Docker example from [rzv-ci-plb, the Runzivo CI playbook](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0). ## The common mistake **Don't do this.** A smoke test written inline: yaml ``` - name: Smoke test image run: | docker run -d --name app -p 8080:8080 "app:${{ github.sha }}" for attempt in 1 2 3 4 5; do if curl -fsS http://127.0.0.1:8080/healthz; then break fi sleep 1 done docker rm -f app ``` It looks fine. It has four problems: - **It passes when the app is broken.** If every `curl` fails, the loop ends quietly and `docker rm` succeeds, so the step exits 0. I ran it with a failing `curl` to confirm. - **Cleanup is skipped on failure.** If `docker run` fails, the step stops before `docker rm`. - **You can't run it locally** without copying it out of the YAML. - **`${{ github.sha }}` is pasted into the script text** before the shell starts. That is safe for a SHA. The same habit with a pull request title is a [script injection](https://docs.github.com/en/actions/concepts/security/script-injections). One more detail: without `shell: bash`, GitHub runs this with `bash -e {0}`, which has no `pipefail`. With `shell: bash`, it runs `bash --noprofile --norc -eo pipefail {0}`. The [workflow syntax reference](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax) lists both. The playbook sets `defaults.run.shell: bash` in every workflow. ## The three-line rule My rule: a `run:` block of three lines or fewer can stay inline. Move it to a script when it has: - conditions or loops - retries - cleanup - error handling - more than three lines This is a Runzivo convention, not a GitHub requirement. It is stricter than the [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html), which suggests a structured language once a script passes 100 lines or has non-straightforward control flow. The point is the same: keep shell small and easy to read. ## The recommended approach The workflow steps become single calls. Values come in through `env:`. From [`example-docker.yml`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/.github/workflows/example-docker.yml#L34-L40): yaml ``` - name: Build image run: bash "${GITHUB_WORKSPACE}/examples/docker/ci/01-build.sh" - name: Smoke test image env: REPORT_DIR: ${{ runner.temp }}/reports run: bash "${GITHUB_WORKSPACE}/examples/docker/ci/02-test.sh" ``` The image name comes from a job-level `env:` block (`IMAGE`), so no expression lands inside a script. The smoke test script holds the logic. This excerpt is from [`examples/docker/ci/02-test.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/examples/docker/ci/02-test.sh#L27-L49): bash ``` container_id="" save_logs_and_remove() { if [[ -n "$container_id" ]]; then # Logs are best effort: a container that failed to start may have none. docker logs "$container_id" >"${REPORT_DIR}/docker-container.log" 2>&1 || log_warn "could not save container logs" docker rm -f "$container_id" >/dev/null fi } cleanup_register save_logs_and_remove log_group_start "Start container" container_id="$(docker run --detach --publish 127.0.0.1::8080 \ --label "ci.example=docker" --read-only --cap-drop ALL "$IMAGE")" host_port="$(docker port "$container_id" 8080/tcp)" host_port="${host_port##*:}" log_info "container ${container_id:0:12} listening on 127.0.0.1:${host_port}" log_group_end log_group_start "Check /healthz" body="$(retry 10 1 curl --fail --silent --show-error "http://127.0.0.1:${host_port}/healthz")" [[ "$body" == "ok" ]] || die "unexpected /healthz body: ${body}" log_group_end ``` Each problem from the inline version is fixed: - `retry` returns the last exit code when every attempt fails, so a broken app fails the step. See [`retry` in `scripts/lib/03-errors.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/lib/03-errors.sh#L54-L79). - `cleanup_register` removes the container on success, failure or cancellation. See [`scripts/lib/04-cleanup.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/lib/04-cleanup.sh#L19-L52). - The script runs the same way on a laptop: bash ``` bash scripts/ci/02-test.sh docker ``` That builds the image with `01-build.sh`, then runs `02-test.sh`. ## Number scripts in run order Every script in the playbook starts with a two-digit number: `01-build.sh` runs before `02-test.sh`, and `00` is for setup. Directory listings then show the order, and an unused script stands out. See [numbered scripts](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/docs/best-practices.md#numbered-scripts). ## What you get **Local runs.** A developer reproduces a CI failure with one command. **Real linting.** ShellCheck reads a `.sh` file directly. [actionlint](https://github.com/rhysd/actionlint/blob/main/docs/checks.md) also runs ShellCheck on `run:` blocks, but a script file is easier to check, format and review. **Tests.** [Bats](https://github.com/bats-core/bats-core) tests the shared helpers, including the failure paths. See [`tests/bats/03-errors.bats`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/tests/bats/03-errors.bats#L60-L82) for `retry`. **Portable workflows.** The YAML only coordinates, so moving it to another compatible runner means changing `runs-on`, not rewriting steps. ## Commands to check your scripts From the repository [README](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/README.md#run-the-checks): bash ``` brew install actionlint shellcheck shfmt bats-core zizmor # on a Mac bash scripts/ci/01-validate.sh # actionlint, shellcheck, shfmt, zizmor bash scripts/ci/02-test.sh # Bats tests and every example bash scripts/ci/02-test.sh golang # one suite ``` ## When inline is fine Short, single-purpose commands can stay in YAML. A simplified example: yaml ``` - name: Install dependencies run: npm ci ``` If you are unsure, ask: "Would I want to run this on my laptop when it fails?" If yes, make it a script. ## Running on Runzivo Runzivo is in Early Access. It runs each eligible GitHub Actions job in a fresh, single-use microVM. Because the logic lives in scripts, moving a job means changing one line: yaml ```yaml runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb ``` See [`examples/runzivo-runners`](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0/examples/runzivo-runners) and the [Runzivo docs](https://runzivo.dev/docs/). ## In the repo - [`examples/docker/ci/01-build.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/examples/docker/ci/01-build.sh) and [`02-test.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/examples/docker/ci/02-test.sh) - [`.github/workflows/example-docker.yml`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/.github/workflows/example-docker.yml) - [`scripts/lib/03-errors.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/lib/03-errors.sh) (`retry`, `die`) and [`scripts/lib/04-cleanup.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/lib/04-cleanup.sh) - [`scripts/ci/02-test.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/ci/02-test.sh): runs one suite or all of them - [`AGENTS.md` script rules](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/AGENTS.md#script-rules): the three-line rule and numbering, written for coding agents Next: error handling with traps, cleanup, logging and exit codes. Every example in this series is tested in [rzv-ci-plb, the Runzivo CI playbook](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0), pinned to tag `v0.1.0`. ## More from the blog Tutorials Published October 20, 2026 ### 10 GitHub Actions best practices for reliable CI Small YAML, real scripts, clear failures, cleanup and least privilege, each linked to tested code. [Read the post](https://runzivo.dev/blog/ten-github-actions-best-practices/) Ditah Kumbong 5 min read Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published November 1, 2026 ### Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/team-and-business-plans/ # Team and Business plans are available Subscribe from the portal, monthly or yearly, and keep prepaid credit as a backup. Ditah Kumbong Founder October 31, 2026 2 min read Reading time 2 min left Share Team and Business plans are available. A workspace can subscribe from the portal, billed monthly or yearly. ## What you get Each plan includes unit-minutes every month in place of the free allowance. Usage draws on included unit-minutes first, then prepaid credit, then overage up to a monthly cap. A yearly plan costs 15% less than twelve monthly payments and still grants its unit-minutes each month. Prices in CAD, USD, EUR and GBP are on the [pricing page](https://runzivo.dev/pricing/). ## How to subscribe Owners and admins open Settings, then Billing & Credits, choose Team or Business and Monthly or Yearly, agree to overage charges, and pay in the Stripe checkout. The plan starts when Stripe confirms the payment. ## Renewal and cancellation A plan renews at the end of each paid term. If a renewal payment fails, a grace period of 7 days starts by default. Included unit-minutes and prepaid credit stay usable; new overage stops when grace ends. To cancel or change a plan, contact support. A cancellation takes effect at the end of the paid term, and paid terms are not refunded. The [plans guide](https://runzivo.dev/docs/plans/) has the details. ## More from the blog Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published November 1, 2026 ### Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ### Agent Sandboxes are available An isolated Linux microVM per sandbox, run from the rzv CLI or the API, and billed only for the seconds it runs. [Read the post](https://runzivo.dev/blog/agent-sandboxes/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/ten-github-actions-best-practices/ # 10 GitHub Actions best practices for reliable CI Ten rules I use to keep pipelines reliable, each linked to working, tested code. Ditah Kumbong Founder October 20, 2026 5 min read Reading time 5 min left Share Most broken pipelines fail for the same few reasons. Logic hides in YAML. A failure gets swallowed. A temporary file outlives the job. A token can write more than it needs to. This post lists ten rules I use to avoid those failures. Each rule links to working, tested code in [rzv-ci-plb, the Runzivo CI playbook](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0), my open-source companion repository. The next three posts go deeper on scripts, error handling and security. ## 1. Keep YAML small and put logic in scripts **Mistake:** a 40-line `run:` block with loops, retries and `if` checks. You can't run it locally, lint it well or test it. **Do this:** keep commands of three lines or fewer inline. Move anything with conditions, loops, retries or cleanup into a script. Every script should also run outside GitHub Actions. The three-line limit is my convention, not a GitHub rule. It follows the [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html), which says to move scripts over 100 lines, or with non-straightforward control flow, to a more structured language. Example: [`examples/nodejs/ci/01-test.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/examples/nodejs/ci/01-test.sh). ## 2. Fail clearly and keep the exit code **Mistake:** `|| true` or `continue-on-error: true` with no comment. The job turns green and the bug ships. **Do this:** start Bash scripts with `set -Eeuo pipefail`. Install an `ERR` trap that names the file, line and command. Fail with a specific exit code. If you must ignore a failure, write down why next to the line. Example: [`die` and `errors_install_traps` in `scripts/lib/03-errors.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/lib/03-errors.sh#L14-L34). ## 3. Always clean up **Mistake:** temporary directories, containers and test resources left behind when a step fails halfway. **Do this:** register cleanup as you create each resource. Run it from an `EXIT` trap that keeps the original exit status, and handle `INT` and `TERM` too. A trap can't run after `SIGKILL` or a lost runner, so keep resources disposable. Examples: [`scripts/lib/04-cleanup.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/lib/04-cleanup.sh#L19-L52) and the container cleanup in [`examples/docker/ci/02-test.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/examples/docker/ci/02-test.sh#L27-L36). ## 4. Use absolute paths **Mistake:** `cd ../..` and relative paths that only work from one directory. **Do this:** use `$GITHUB_WORKSPACE` in workflows. Inside scripts, resolve paths from `${BASH_SOURCE[0]}`. Quote every path. Validate paths that come from input. These two lines open [`scripts/ci/01-validate.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/ci/01-validate.sh#L8-L9): bash ``` SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd -P)" REPO_ROOT="$(cd -- "${SCRIPT_DIR}/../.." && pwd -P)" ``` Input paths: [`path_within` in `scripts/lib/02-paths.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/lib/02-paths.sh#L44-L55). ## 5. Log the same way everywhere **Mistake:** a wall of output with no step names and an error message that says only "failed". **Do this:** use `[INFO]`, `[WARN]` and `[ERROR]` with UTC timestamps. Use GitHub's `::group::` and `::error::` [workflow commands](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-commands), and write a short result to `$GITHUB_STEP_SUMMARY`. Never print a credential. Example: [`scripts/lib/01-logging.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/lib/01-logging.sh). ## 6. Grant least privilege **Mistake:** no `permissions:` key, third-party actions pinned to a moving tag, and event text pasted straight into shell code. **Do this:** set `permissions: contents: read` at the top of the workflow. Pin third-party actions to a full commit SHA. Pass untrusted values through environment variables. Post 4 covers this in detail. See [`docs/security.md`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/docs/security.md#security). ## 7. Make jobs repeatable and safe to retry **Mistake:** unpinned tool versions, no timeout, and two deploys racing each other. **Do this:** pin tool versions and their checksums, and commit lockfiles. Set `timeout-minutes`. The job default is six hours, per the [workflow syntax reference](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax). Add a `concurrency` group. Retry only failures you know are temporary. Example: the pinned versions and SHA-256 digests in [`scripts/ci/00-install-tools.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/ci/00-install-tools.sh#L19-L29). ## 8. Separate test, build and deploy **Mistake:** one job that tests a pull request and also holds production credentials. **Do this:** pull request checks run with no deploy secrets. Deploys run after checks pass, from `main`, through a GitHub [environment](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments) with protection rules where your plan supports them. I name environments by stage, such as `04-prd-01` for the first production environment. See the [deploy gate in `docs/environments.md`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/docs/environments.md#deploy-gate). ## 9. Validate every workflow automatically **Mistake:** finding a YAML typo after the merge. **Do this:** run linters and tests on every pull request. In the repository, two scripts do it, and they run the same way locally: bash ``` bash scripts/ci/01-validate.sh # actionlint, shellcheck, shfmt, zizmor bash scripts/ci/02-test.sh # Bats tests and every example ``` [actionlint](https://github.com/rhysd/actionlint) checks workflow files and runs ShellCheck on `run:` blocks. [ShellCheck](https://github.com/koalaman/shellcheck) and [shfmt](https://github.com/mvdan/sh) cover scripts. [zizmor](https://docs.zizmor.sh/) looks for security problems. [Bats](https://github.com/bats-core/bats-core) tests scripts, including the failure paths. Examples: [`run_lint` in `scripts/ci/01-validate.sh`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/scripts/ci/01-validate.sh#L21-L41) and the tests in [`tests/bats/`](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0/tests/bats). ## 10. Build for reuse and debugging **Mistake:** the same 30 steps copied into every repository. **Do this:** use [reusable workflows](https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows) for whole jobs and [composite actions](https://docs.github.com/en/actions/tutorials/create-actions/create-a-composite-action) for repeated steps. Upload test reports as artifacts when a job fails. Examples: [`ci.yml` calling reusable workflows](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/.github/workflows/ci.yml#L39-L53), the [`setup-ci` composite action](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/.github/actions/setup-ci/action.yml) and the [failure artifact upload](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/.github/workflows/example-nodejs.yml#L44-L51). ## Two naming rules Neither is a GitHub rule. Both make a pipeline easier to read. - **Numbered scripts.** Every script and Bats file starts with a two-digit number in run order: `01-build.sh` before `02-test.sh`. `00` is for setup. See [numbered scripts](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/docs/best-practices.md#numbered-scripts). - **Numbered environments.** Ids follow `--`: `01-dev-01`, `02-qat-01`, `03-stg-01`, `04-prd-01`, with the codes `dev`, `qat`, `stg` and `prd`. Lists then sort from development to production. See [`docs/environments.md`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/docs/environments.md#environment-naming). ## A workflow that follows all ten The workflow only coordinates. The script does the work. This is the repository's [`lint.yml`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/.github/workflows/lint.yml), unchanged: yaml ```yaml name: Lint on: push: branches: [main] pull_request: permissions: contents: read concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} defaults: run: shell: bash jobs: lint: name: actionlint, shellcheck, shfmt runs-on: ubuntu-latest timeout-minutes: 10 steps: - name: Check out uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: persist-credentials: false - name: Install tools uses: ./.github/actions/setup-ci with: tools: actionlint shellcheck shfmt - name: Lint run: bash "${GITHUB_WORKSPACE}/scripts/ci/01-validate.sh" lint ``` Language examples live in [`examples/nodejs`](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0/examples/nodejs), [`examples/python`](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0/examples/python), [`examples/golang`](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0/examples/golang) and [`examples/docker`](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0/examples/docker). ## Running these on Runzivo The examples run on GitHub-hosted runners. They also run on Runzivo, which is in Early Access. Runzivo assigns each eligible job a fresh, single-use microVM. To try it, change only `runs-on` to the documented label: yaml ```yaml runs-on: rzv-ubuntu-24.04-x64-2vcpu-8gb ``` The repository's [`runzivo.yml`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/.github/workflows/runzivo.yml#L26-L41) reads the label from the `RUNZIVO_RUNNER_LABEL` repository variable and runs only on `push` and manual dispatch. See the [Runzivo docs](https://runzivo.dev/docs/). ## In the repo - [`docs/best-practices.md`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/docs/best-practices.md#the-ten-standards): the ten standards, each linked to code - [`scripts/lib/`](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0/scripts/lib): `01-logging.sh`, `02-paths.sh`, `03-errors.sh`, `04-cleanup.sh` - [`scripts/ci/`](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0/scripts/ci): `00-install-tools.sh`, `01-validate.sh`, `02-test.sh` - [`.github/workflows/`](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0/.github/workflows): `ci.yml`, `lint.yml`, `security.yml`, `runzivo.yml` and one workflow per example - [`docs/environments.md`](https://github.com/Runzivo/rzv-ci-plb/blob/v0.1.0/docs/environments.md#environment-naming): environment ids and the deploy gate ## Next in this series - Stop writing complex Bash inside GitHub Actions YAML - Error handling: traps, cleanup, logging and exit codes - Secure GitHub Actions: permissions, secrets and untrusted pull requests Every example in this series is tested in [rzv-ci-plb, the Runzivo CI playbook](https://github.com/Runzivo/rzv-ci-plb/tree/v0.1.0), pinned to tag `v0.1.0`. ## More from the blog Tutorials Published October 27, 2026 ### Stop writing complex Bash inside GitHub Actions YAML Move loops, retries and cleanup out of run: blocks into scripts you can lint, test and run locally. [Read the post](https://runzivo.dev/blog/stop-writing-complex-bash-in-github-actions-yaml/) Ditah Kumbong 4 min read Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published November 1, 2026 ### Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/tonight-release-cli-docs-and-pending-portal-updates/ # Clearer setup guidance and CLI 0.9.0 docs CLI documentation is available now. The portal items below have shipped in Core. Ditah Kumbong Founder October 21, 2026 2 min read Last updated October 22, 2026 Reading time 2 min left Share The Go `rzv` CLI 0.9.0 documentation is available now. The portal updates in this post have shipped in the deployed Core release. ## Available now The [CLI guide](https://runzivo.dev/docs/cli/) now documents the Go `rzv` CLI 0.9.0 that the installer ships. It covers the current commands, authentication, workspace selection, JSON output, and command help. ## Organization repositories Runzivo supports repositories owned by GitHub organizations, including GitHub Free organizations. Personal-account repositories are not supported. The [GitHub App permissions guide](https://runzivo.dev/docs/github-app-permissions/) explains the permissions requested during setup. ## Shipped portal updates These portal updates have shipped in Core. They describe current product behavior, not a completed customer journey or a payment activation. - For eligible capacity waits where Runzivo confirms the job never started and no runner resources remain allocated, Runzivo waits up to 900 seconds by default. This platform limit is configurable. When the wait expires, Runzivo ends the local attempt with zero execution charge, alerts staff, and provides rerun guidance. The attempt does not cancel the GitHub workflow or its sibling jobs. - After installation, setup checks the current GitHub App permissions again instead of relying on a stale cached mismatch. - GitHub onboarding explains each requested permission. The onboarding flow identifies AI-write permissions as Early Access permissions. Start with the [getting started guide](https://runzivo.dev/docs/getting-started/). - The signed-out billing preview identifies example checkout data. It does not mean checkout is available. ## More from the blog Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published November 1, 2026 ### Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ### Team and Business plans are available Monthly or yearly plans with included unit-minutes, bought from Billing & Credits in the portal. [Read the post](https://runzivo.dev/blog/team-and-business-plans/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/why-runzivo-does-not-ask-for-repository-administration/ # Why Runzivo does not ask for repository administration Update, 21 October 2026: organization repositories, including GitHub Free organizations, are supported. Personal-account repositories are not. Ditah Kumbong Founder October 21, 2026 2 min read Update note: this replaces the earlier statement that personal-account repositories would be supported through the Administration permission. Reading time 2 min left Share Runzivo runs GitHub Actions jobs for repositories owned by GitHub organizations, including GitHub Free organizations. It does not run jobs for repositories owned by a personal account, and it will not ask for the permission that would make that possible. ## What the earlier guide said The setup guide previously stated that personal-account repositories would need the GitHub App permission **Administration: Read and write**, and that support was planned. Runzivo withdraws that statement. The Runzivo GitHub Apps keep their current permissions. ## Why Runzivo will not request it GitHub only lets an app register a self-hosted runner on a personal repository if the app holds Administration: Read and write. There is no narrower option. That permission also lets an app change repository settings, branch protection, collaborators and deploy keys, and rename or archive a repository. Runzivo does not need that level of control. Organizations can use organization-level runners, which need only the narrower **Self-hosted runners** organization permission. Adding Administration to the Runzivo App would also send a new permission request to every existing installation, including the organizations that never need it. ## What this means for you If your repository belongs to a personal account, create a free GitHub organization, move or fork the repository into it, and connect that organization to Runzivo. Your job then runs on an isolated Runzivo runner with the same permissions every organization uses. The full list of permissions Runzivo requests, and what each one is for, is in the [GitHub App permissions guide](https://runzivo.dev/docs/github-app-permissions/). ## More from the blog Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published November 1, 2026 ### Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ### Team and Business plans are available Monthly or yearly plans with included unit-minutes, bought from Billing & Credits in the portal. [Read the post](https://runzivo.dev/blog/team-and-business-plans/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/blog/why-runzivo/ # Why I Built Runzivo: Faster CI. Less Waiting. I am building managed CI compute for teams who would rather ship code than maintain runners. Ditah Kumbong Founder September 13, 2026 5 min read Last updated October 18, 2026 Update note: Team section removed. Reading time 5 min left Share CI is where a development team discovers whether a change holds up. It is also where time disappears. A pull request waits for a runner. A test suite waits for capacity. A release waits for the queue to clear. Those delays are easy to accept one at a time, but they add up across a week of small changes and a team of people trying to keep work moving. I kept seeing the same trade-off. Hosted runners remove infrastructure work, but teams have limited control over startup time and performance. Self-hosted runners offer more control, but teams must maintain fleets, images, access boundaries, and cleanup. Teams should not have to choose between fast feedback and a manageable operating model. ## CI compute should fade into the background. That is why I started Runzivo. CI compute should be ready when a job needs it, isolated while it runs, and gone when it finishes. The workflow should stay familiar. Runzivo should handle the infrastructure behind it. This is a narrow problem on purpose. I am not introducing a new CI language or asking teams to rebuild working pipelines. I am starting where a workflow asks for a machine. A small change is easier to evaluate, undo, and fit into systems teams already use. ## What I am building first. V1 is managed Linux x64 compute for GitHub Actions. Each approved job receives an isolated, ephemeral environment. When the job finishes, that environment is destroyed. Teams install the Runzivo GitHub App, choose the repositories they want to use, and change the ` runs-on ` label in a workflow. Their existing steps stay in place. The first version is deliberately specific. It does not promise every operating system, architecture, or CI provider. It focuses on one integration and one runner target. That gives me a clear operating model to test with real jobs. I will measure performance before making speed claims. For V1, the goal is simple: less waiting around a CI workflow. ## The principles behind the service. Runzivo begins with a few principles. One job gets one isolated environment. Compute is ephemeral and is not reused across customers. GitHub integration stays simple. Customers should not have a runner fleet to patch, scale, or clean up. These are V1 design commitments. Early users will help me test them in practice. A clear environment lifecycle helps me reason about security and performance. It is easier to inspect than a shared environment used across jobs. A small product surface also makes the limits easier to understand. I am keeping V1 narrow so users know what it does, where its boundaries are, and how to report gaps. ## Why now. Teams are shipping more changes and automating more of the work around them. Generated code, larger test suites, and additional pull-request checks all put pressure on CI. The bottleneck is often not the person writing the change. It is the wait between submitting it for validation and receiving a useful answer. I do not think every team needs a new delivery platform to address that pressure. Many teams already have workflows they trust. They need a better place for selected jobs to run. That is the practical opening for Runzivo: keep the workflow familiar and make the compute layer easier to use and operate. ## What comes after V1. GitLab, macOS, additional regions, and observability are roadmap directions, not V1 features. I will consider them after early users test the GitHub Actions and Linux x64 experience. A roadmap item is not an available feature. My immediate job is more modest. Build the first service carefully. Listen to the teams trying it. Publish clear limits. Improve the parts that hold up in real use. Keep the rest on the roadmap until it earns its place in the product. ## Build with me. I am working with early users now. If your team spends too much time waiting on GitHub Actions, I would like to hear about the workflows that create the most friction. [Request Early Access](https://runzivo.dev/early-access/), and tell me what you are trying to run. Runzivo is early, focused, and open to feedback from the people using it. Start with one workflow. Then help me make the wait smaller. ## More from the blog Announcements Published November 1, 2026 ### Audit & Status: clearer evidence for your investigations Three views, one time range, readable execution evidence and a clearer audit log. [Read the post](https://runzivo.dev/blog/audit-status-redesign/) Ditah Kumbong 9 min read Announcements Published November 1, 2026 ### Coming soon: Sandbox developer workflows Upcoming developer workflows are not available in production. Read the Coming soon guides. [Read the post](https://runzivo.dev/blog/coming-soon-sandbox-developer-workflows/) Ditah Kumbong 2 min read Announcements Published October 31, 2026 ### Team and Business plans are available Monthly or yearly plans with included unit-minutes, bought from Billing & Credits in the portal. [Read the post](https://runzivo.dev/blog/team-and-business-plans/) Ditah Kumbong 2 min read ## Keep up with the build. Product updates, engineering notes, and Early Access opportunities. Work email By subscribing, you agree to receive Runzivo updates. Read our [privacy notice](https://runzivo.dev/legal/privacy/). [Back to the blog](https://runzivo.dev/blog/) [Subscribe to updates](https://runzivo.dev/newsletter/) --- Source: https://runzivo.dev/careers/ # Help build secure infrastructure for GitHub Actions. Runzivo is building managed, isolated CI/CD compute for GitHub Actions. ## Build with Runzivo We want to hear from people in product, business development, marketing, sales, platform engineering and secure execution. To introduce yourself, email [run@runzivo.dev](mailto:run@runzivo.dev?subject=Careers). Students: we welcome for-credit placements and projects through your school's co-op or work-integrated learning program, including platforms like Riipen. Have your program coordinator contact [run@runzivo.dev](mailto:run@runzivo.dev?subject=Student%20placement). --- Source: https://runzivo.dev/changelog/ # Changelog Subscribe via [RSS](https://runzivo.dev/changelog/rss.xml) to receive Runzivo product and service updates. 1. November 1, 2026 ## [Audit & Status: three views and clearer evidence](https://runzivo.dev/changelog/audit-status-redesign/) The live portal redesign combines Overview, Execution assurances and Audit log with one shared time range. - Overview, Execution assurances and Audit log share a URL-preserved range: 24 hours, 7, 30 or 60 days, or Custom. - Filter execution evidence by teardown outcome and expand records. Exception counts and recorded forced-stop reasons replace blanket success claims. - Automatic refresh depends on the range. 30 and 60 days: every 60 seconds. 7 days: every 15 seconds. 24 hours: every 3 seconds while the running count is above zero, otherwise every 15 seconds. Pause and Resume remain available. Custom ranges never refresh automatically. - Activity reads and CSV exports scrub credential-looking text. Current component state does not invent uptime history. 2. October 31, 2026 ## [rzv CLI 0.21.0: larger sandbox sizes and exact exec arguments](https://runzivo.dev/changelog/rzv-cli-0-21-0/) rzv 0.21.0 adds two larger sandbox sizes and runs exec arguments exactly as typed. - `rzv sandboxes create --size 8vcpu-32gb|16vcpu-64gb` Accepts the 8vcpu-32gb and 16vcpu-64gb sandbox sizes as well as 2vcpu-8gb and 4vcpu-16gb. Which sizes can start now depends on capacity; rzv sandboxes list shows them. - `rzv sandboxes exec -- ` With two or more arguments after --, quotes each one, so the sandbox runs exactly the argument list you typed. One argument still runs as a shell script; put pipes, && or $VARS in a single quoted argument. - The sandboxes help describes API key access correctly: sandboxes:read and sandboxes:write are key permissions, granted with rzv api-keys create --permissions, or use the all:all scope. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 3. October 31, 2026 ## [rzv CLI 0.20.0: Agent Sandboxes commands](https://runzivo.dev/changelog/rzv-cli-0-20-0/) rzv 0.20.0 adds commands for Agent Sandboxes. - `rzv sandboxes list|get|create|start|stop|delete` Creates and manages Agent Sandboxes, Linux virtual machines that last eight hours from their first start. list shows the sizes the environment offers. - `rzv sandboxes exec -- ` Runs a command with streamed output and exits with its status. It exits with 137 when output passes 8 MiB, and says when the sandbox stopped, expired or was deleted during the command. - `rzv sandboxes ssh ` Opens an interactive terminal and says why it closed. It does not run on Windows. - `rzv sandboxes terminal-ticket ` Prints a single-use terminal URL for a client that cannot send an Authorization header, such as a browser. - Every sandboxes command except ssh accepts --json. A command run without its subcommand prints its usage on separate lines. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 4. October 31, 2026 ## [Team and Business plans](https://runzivo.dev/changelog/team-and-business-plans/) Team and Business plans are available in the portal. - Owners and admins can subscribe to Team or Business in the portal under Billing & Credits, billed monthly or yearly. A yearly plan costs 15% less than twelve monthly payments. - A plan's included unit-minutes are granted each month and do not roll over. Usage draws on included unit-minutes first, then prepaid credit, then overage up to the plan's monthly overage cap. Overage is invoiced monthly. - If a renewal payment fails, a grace period of 7 days starts by default. To cancel or change a plan, contact support. A cancellation takes effect at the end of the paid term. 5. October 30, 2026 ## [Card checkout, Insights and code redemption](https://runzivo.dev/changelog/card-checkout-insights-and-codes/) Card checkout for Canada and the United States, Insights, and code redemption are available in the portal. - Workspaces billed in Canada or the United States can buy prepaid credit packs by card in the portal under Billing & Credits. Checkout is handled by Stripe. Bank transfer in CAD or USD remains available. - Credit pack prices are listed in CAD, USD, EUR and GBP. The 25,000-minute pack is now called the Team pack. Runzivo does not collect sales tax yet. - Insights under CI & Runners shows jobs by day and status, recorded minutes by runner size, duration and queue wait, a queue heatmap and the slowest workflows. - Billing & Credits has Redeem a code for promo codes and prepaid vouchers. 6. October 29, 2026 ## [rzv CLI 0.19.0: new sign-in address](https://runzivo.dev/changelog/rzv-cli-0-19-0/) rzv 0.19.0 signs in at the new production identity host. - Production sign-in moves to id.runzivo.dev. Run rzv login after upgrading; a sign-in made with an older rzv does not work with the new identity host. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 7. October 28, 2026 ## [rzv CLI 0.18.0: sign-in profiles](https://runzivo.dev/changelog/rzv-cli-0-18-0/) rzv 0.18.0 adds sign-in profiles and a default workspace setting. - `rzv login -p [-w ]` Keeps one sign-in per profile, so signing in to a second account no longer replaces the first. -p works on every command, and RZV_PROFILE sets the profile for a shell. - `rzv profiles list|use|remove` Lists your local profiles, switches the active one, or removes a profile's local sign-in. - RZV_WORKSPACE sets the default workspace, and --workspace accepts a workspace slug as well as an id. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 8. October 28, 2026 ## [rzv CLI 0.17.0: activity, notifications, insights and more](https://runzivo.dev/changelog/rzv-cli-0-17-0/) rzv 0.17.0 adds activity, notification, insight, AI, GitHub onboarding, code redemption and workspace closure commands. - `rzv activity list|export|status` Lists workspace activity with filters and paging, exports it as CSV, and shows audit signals with execution evidence. - `rzv api-keys create --permissions ` Creates an API key with fine-grained permissions. List, create and rename show each key's permissions. - `rzv notifications list|read|settings` Lists workspace notifications, marks them read, and shows or changes delivery settings. Needs your own sign-in. - `rzv jobs logs ` Shows a job's log text, or why it is not available. - `rzv insights summary|heatmap|slow-jobs` Shows job and minute totals, queue activity by hour, and the slowest workflows for the selected workspace. - `rzv ai providers|settings|usage` Manages the workspace AI provider connections and settings, and reports AI usage. Provider keys are read only from --key-file. - `rzv github installations` Lists every linked GitHub App installation with its setup and repository state. - `rzv github workspaces start|complete` Creates a workspace from a GitHub installation. - `rzv billing codes redeem --code-file ` Redeems a promo code or prepaid voucher for the selected workspace. - `rzv workspaces closures list|request|cancel` Asks Runzivo to close a workspace, or withdraws the request. Nothing is deleted immediately. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 9. October 27, 2026 ## [rzv CLI 0.16.0: close support tickets](https://runzivo.dev/changelog/rzv-cli-0-16-0/) rzv 0.16.0 adds a command that closes a support ticket you have open. - `rzv tickets close ` Closes a support ticket you have open, for the selected workspace or with --personal. The ticket is marked resolved. A ticket that is already closed says so. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 10. October 27, 2026 ## [rzv CLI 0.15.0: teams and permissions commands](https://runzivo.dev/changelog/rzv-cli-0-15-0/) rzv 0.15.0 adds team commands and a command that shows your workspace permissions. - `rzv teams list|show|create|rename|permissions|add-member|remove-member|delete` Lists, shows, creates, renames and deletes teams, sets team permissions, and adds or removes team members for the selected workspace. - `rzv permissions` Shows your permissions in the selected workspace, with the permission catalogue and presets. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/agent-onboarding-and-portal-navigation/ # Agent onboarding and portal navigation October 20, 2026 Agent onboarding, a redesigned workspace home, portal quick search, and permission-based billing visibility are now available. - The workspace home has a centred welcome area, a wider search field, and three action cards. - Onboard your agent to Runzivo copies a setup prompt for Claude, ChatGPT, Gemini, Grok, and Cursor. The prompt and public instructions are also available on the sign-in page and public preview. - Use Command+K on a Mac or Control+K elsewhere to open Quick search anywhere in the portal. - Billing data, including billing data in AI chat, now requires the View billing permission. The Member and Viewer presets do not include it. - Reservation cleanup and billing finalization are more reliable. --- Source: https://runzivo.dev/changelog/ai-early-access/ # AI features in early access October 18, 2026 AI chat, the pipeline builder and the CI fix agent enter early access, switched off until they are enabled for a workspace. - AI chat, the pipeline builder and the CI fix agent are built and deployed in early access. They are switched off and are not available to customers yet. - The pipeline builder writes GitHub Actions workflows and delivers them as a pull request. Its jobs run on Runzivo only after the workspace approves them. - The CI fix agent proposes changes to CI files for a failed run in a pull request from a new branch. It never pushes to an existing branch and never merges. --- Source: https://runzivo.dev/changelog/audit-status-redesign/ # Audit & Status: three views and clearer evidence November 1, 2026 The live portal redesign combines Overview, Execution assurances and Audit log with one shared time range. - Overview, Execution assurances and Audit log share a URL-preserved range: 24 hours, 7, 30 or 60 days, or Custom. - Filter execution evidence by teardown outcome and expand records. Exception counts and recorded forced-stop reasons replace blanket success claims. - Automatic refresh depends on the range. 30 and 60 days: every 60 seconds. 7 days: every 15 seconds. 24 hours: every 3 seconds while the running count is above zero, otherwise every 15 seconds. Pause and Resume remain available. Custom ranges never refresh automatically. - Activity reads and CSV exports scrub credential-looking text. Current component state does not invent uptime history. --- Source: https://runzivo.dev/changelog/card-checkout-insights-and-codes/ # Card checkout, Insights and code redemption October 30, 2026 Card checkout for Canada and the United States, Insights, and code redemption are available in the portal. - Workspaces billed in Canada or the United States can buy prepaid credit packs by card in the portal under Billing & Credits. Checkout is handled by Stripe. Bank transfer in CAD or USD remains available. - Credit pack prices are listed in CAD, USD, EUR and GBP. The 25,000-minute pack is now called the Team pack. Runzivo does not collect sales tax yet. - Insights under CI & Runners shows jobs by day and status, recorded minutes by runner size, duration and queue wait, a queue heatmap and the slowest workflows. - Billing & Credits has Redeem a code for promo codes and prepaid vouchers. --- Source: https://runzivo.dev/changelog/cli-0-9-0-and-pending-portal-updates/ # rzv CLI 0.9.0 documentation and pending portal updates October 21, 2026 Go rzv CLI 0.9.0 documentation is available. Capacity, setup, onboarding, and billing preview updates remain pending the Core release. - The Go rzv CLI 0.9.0 guide is available, with its installed commands and current workflow examples. - Runzivo supports GitHub organization repositories, including GitHub Free organizations. Personal-account repositories are not supported. - Pending Core release: runner capacity will show an actionable unavailable status when capacity cannot accept a job. - Pending Core release: setup will stop showing a false permissions-pending status, and onboarding will explain each requested GitHub App permission. The onboarding flow will identify AI-write permissions as Early Access permissions. - Pending Core release: billing preview wording will distinguish an example checkout state from live checkout availability. --- Source: https://runzivo.dev/changelog/core-capacity-setup-and-billing-preview/ # Core capacity, setup, and billing preview updates October 22, 2026 Core capacity handling, GitHub App setup guidance, and signed-out billing preview updates are now available. - For eligible capacity waits where Runzivo confirms the job never started and no runner resources remain allocated, Runzivo waits up to 900 seconds by default. This platform limit is configurable. When the wait expires, Runzivo ends the local attempt with zero execution charge, alerts staff, and provides rerun guidance. The attempt does not cancel the GitHub workflow or its sibling jobs. - After installation, setup checks the current GitHub App permissions again instead of relying on a stale cached mismatch. Onboarding explains each requested permission and identifies AI-write permissions as Early Access permissions. - The signed-out billing preview labels example checkout data as a preview. It does not indicate that checkout is available. --- Source: https://runzivo.dev/changelog/github-organization-repositories-only/ # GitHub organization repositories only October 21, 2026 Runzivo supports GitHub organization repositories only and will not request repository Administration for personal-account repositories. - Runzivo supports repositories owned by GitHub organizations, including GitHub Free organizations. Repositories owned by a personal account are not supported. - Runzivo withdrew the earlier statement that personal-account repositories would be supported through GitHub's Administration: Read and write permission. The Runzivo GitHub Apps do not request Administration and keep their current permissions. - To use Runzivo with a personal repository, create a free GitHub organization and move or fork the repository into it. --- Source: https://runzivo.dev/changelog/initial-publication/ # Initial publication September 13, 2026 Published the public Runzivo V1 changelog. V1 scope is managed Linux x64 compute for GitHub Actions. --- Source: https://runzivo.dev/changelog/page/2/ # Changelog Subscribe via [RSS](https://runzivo.dev/changelog/rss.xml) to receive Runzivo product and service updates. 1. October 26, 2026 ## [rzv CLI 0.14.0: workspace access commands](https://runzivo.dev/changelog/rzv-cli-0-14-0/) rzv 0.14.0 adds workspace settings, member and invitation commands, and a way to clear the billing country. - `rzv workspaces settings show|update` Shows and updates the settings for the selected workspace. - `rzv workspaces members list|role|remove` Lists workspace members, changes a member's role, or removes a member. - `rzv workspaces invitations list|invite|resend|revoke|teams|accept` Lists, sends, resends and revokes invitations, sets custom teams on an invitation, and accepts an invitation with your own sign-in. - `rzv billing country reset` Clears a billing country that no purchase has used yet, so the next purchase asks for it again. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 2. October 26, 2026 ## [rzv CLI 0.13.0: billing commands](https://runzivo.dev/changelog/rzv-cli-0-13-0/) rzv 0.13.0 adds billing invoices, automatic recharge, billing country, credit pack checkout and the billing portal. - `rzv billing invoices` Lists the invoices for the selected workspace. - `rzv billing auto-recharge` Reads and sets automatic recharge. Turning it on needs a person signed in, not an API key. - `rzv billing country` Reads and sets the billing country for the selected workspace. - `rzv billing checkout --pack --operation-id` Prints a link to the payment page for a credit pack, where card payments are available for your workspace. Card payments stay off until Runzivo turns them on; until then, buy credits by bank transfer from the portal. Reuse --operation-id when you retry the same purchase. - `rzv billing portal` Prints a link to the billing portal. - A refused billing change says why: your role does not allow it, or you need to run rzv login again. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 3. October 26, 2026 ## [rzv CLI 0.12.0: concurrency and runner commands](https://runzivo.dev/changelog/rzv-cli-0-12-0/) rzv 0.12.0 adds commands for concurrency limits and runner profiles and inventory. - `rzv concurrency` Shows the concurrent-job limit for the selected workspace, the jobs running now, and how many slots are left. - `rzv runners ` Shows the runner sizes a repository can use, with the workspace's running and waiting jobs on each. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 4. October 26, 2026 ## [rzv CLI 0.11.0: connection commands and clearer errors](https://runzivo.dev/changelog/rzv-cli-0-11-0/) rzv 0.11.0 adds gitlab connection commands, and GitLab is not part of V1. Messages for integrations that are not enabled are clearer. - GitLab is not part of V1 and is not enabled for workspaces yet. The rzv gitlab commands report that it isn't enabled. - `rzv gitlab connections` Lists the connections for the selected workspace. - `rzv gitlab connect` Opens the portal page where you set up the integration for the selected workspace. - `rzv gitlab disconnect` Removes a connection. A connection id must match glc\_ followed by 24 lowercase hex digits. - When an integration is not enabled for your account, the command says so in plain words instead of printing the raw error code. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 5. October 26, 2026 ## [rzv CLI 0.10.0: support tickets](https://runzivo.dev/changelog/rzv-cli-0-10-0/) rzv 0.10.0 adds support ticket commands and organization-only onboarding docs. - `rzv tickets list|open|show|reply` Work with support tickets for the selected workspace. Output supports --json. - Add --personal to work with your own tickets instead. It rejects RZV_API_KEY. - The onboarding docs say Runzivo is for organizations only. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. 6. October 23, 2026 ## [Portal navigation and Runner Templates](https://runzivo.dev/changelog/portal-navigation-and-runner-templates/) A regrouped portal sidebar and the Runner Templates page are now available. - The portal sidebar groups services by area. Planned services show a Soon label and don't open a page. Workspace settings are tabs under Settings, and your own profile, appearance, language and timezone are in the account menu. - Runner Templates is available under CI & Runners. It lists ten GitHub Actions workflows for Runzivo runners, with filters, a YAML preview and a copy button, in English and French. - The Terraform template applies only on pushes to main through a GitHub environment. Add required reviewers to that environment before you use apply. 7. October 22, 2026 ## [Core capacity, setup, and billing preview updates](https://runzivo.dev/changelog/core-capacity-setup-and-billing-preview/) Core capacity handling, GitHub App setup guidance, and signed-out billing preview updates are now available. - For eligible capacity waits where Runzivo confirms the job never started and no runner resources remain allocated, Runzivo waits up to 900 seconds by default. This platform limit is configurable. When the wait expires, Runzivo ends the local attempt with zero execution charge, alerts staff, and provides rerun guidance. The attempt does not cancel the GitHub workflow or its sibling jobs. - After installation, setup checks the current GitHub App permissions again instead of relying on a stale cached mismatch. Onboarding explains each requested permission and identifies AI-write permissions as Early Access permissions. - The signed-out billing preview labels example checkout data as a preview. It does not indicate that checkout is available. 8. October 21, 2026 ## [rzv CLI 0.9.0 documentation and pending portal updates](https://runzivo.dev/changelog/cli-0-9-0-and-pending-portal-updates/) Go rzv CLI 0.9.0 documentation is available. Capacity, setup, onboarding, and billing preview updates remain pending the Core release. - The Go rzv CLI 0.9.0 guide is available, with its installed commands and current workflow examples. - Runzivo supports GitHub organization repositories, including GitHub Free organizations. Personal-account repositories are not supported. - Pending Core release: runner capacity will show an actionable unavailable status when capacity cannot accept a job. - Pending Core release: setup will stop showing a false permissions-pending status, and onboarding will explain each requested GitHub App permission. The onboarding flow will identify AI-write permissions as Early Access permissions. - Pending Core release: billing preview wording will distinguish an example checkout state from live checkout availability. 9. October 21, 2026 ## [GitHub organization repositories only](https://runzivo.dev/changelog/github-organization-repositories-only/) Runzivo supports GitHub organization repositories only and will not request repository Administration for personal-account repositories. - Runzivo supports repositories owned by GitHub organizations, including GitHub Free organizations. Repositories owned by a personal account are not supported. - Runzivo withdrew the earlier statement that personal-account repositories would be supported through GitHub's Administration: Read and write permission. The Runzivo GitHub Apps do not request Administration and keep their current permissions. - To use Runzivo with a personal repository, create a free GitHub organization and move or fork the repository into it. 10. October 20, 2026 ## [Agent onboarding and portal navigation](https://runzivo.dev/changelog/agent-onboarding-and-portal-navigation/) Agent onboarding, a redesigned workspace home, portal quick search, and permission-based billing visibility are now available. - The workspace home has a centred welcome area, a wider search field, and three action cards. - Onboard your agent to Runzivo copies a setup prompt for Claude, ChatGPT, Gemini, Grok, and Cursor. The prompt and public instructions are also available on the sign-in page and public preview. - Use Command+K on a Mac or Control+K elsewhere to open Quick search anywhere in the portal. - Billing data, including billing data in AI chat, now requires the View billing permission. The Member and Viewer presets do not include it. - Reservation cleanup and billing finalization are more reliable. --- Source: https://runzivo.dev/changelog/page/3/ # Changelog Subscribe via [RSS](https://runzivo.dev/changelog/rss.xml) to receive Runzivo product and service updates. 1. October 19, 2026 ## [rzv CLI 0.9.0: Go rewrite and single-file downloads](https://runzivo.dev/changelog/rzv-cli-0-9-0/) rzv 0.9.0 is rewritten in Go and ships as single-file downloads for Linux, Mac and Windows. - rzv is rewritten in Go. Each download is one file with no runtime dependencies, and Linux no longer needs libatomic1. - rzv accounts is now rzv workspaces. The old name still works, and --workspace replaces --account, which also still works. - Downloads are available for Linux arm64, Intel Macs and Windows x86-64, alongside Linux x86-64 and Apple Silicon Macs. - `rzv whoami` Shows the signed-in identity, environment, session expiry and selected workspace. - `rzv login --env prd|shared` Chooses the environment. Production is the default, and --no-browser is available. - RZV_API_KEY works without a stored sign-in when you pass --workspace. - `rzv repositories list` Lists the repositories available to your workspace. - Release notes are on GitHub at Runzivo/rzv-cli. 2. October 19, 2026 ## [Customer portal sessions](https://runzivo.dev/changelog/portal-sessions/) Customer portal sessions last 14 days without activity and 30 days at most, keep sign-in tokens on the server, and ask you to confirm your identity before sensitive actions. - You stay signed in to the customer portal for 14 days without activity, and for 30 days at most. Your sign-in survives browser restarts. - Only your own activity, such as opening pages or taking actions, keeps a session alive. Background refreshes do not. - Your browser holds only an opaque session cookie. Sign-in tokens stay on the server, which renews short-lived access tokens. - Signing out ends the session immediately. Suspending an account or signing it out everywhere ends all of its sessions immediately. - When this update ships, everyone is signed out of the customer portal once. Sign in again to start a new session. - API key changes, account security settings, and billing changes (when paid billing is enabled) ask you to confirm it's you if you have not signed in recently. The sign-in and sessions guide lists the actions and the time limit. 3. October 18, 2026 ## [AI features in early access](https://runzivo.dev/changelog/ai-early-access/) AI chat, the pipeline builder and the CI fix agent enter early access, switched off until they are enabled for a workspace. - AI chat, the pipeline builder and the CI fix agent are built and deployed in early access. They are switched off and are not available to customers yet. - The pipeline builder writes GitHub Actions workflows and delivers them as a pull request. Its jobs run on Runzivo only after the workspace approves them. - The CI fix agent proposes changes to CI files for a failed run in a pull request from a new branch. It never pushes to an existing branch and never merges. 4. October 16, 2026 ## [rzv CLI 0.7.0: API key scopes](https://runzivo.dev/changelog/rzv-cli-0-7-0/) rzv CLI 0.7.0 adds the all:all, logs:read and audit:read API key scopes and lets workspace commands run with an API key. - `rzv api-keys create --scopes all:all` Adds the all:all scope, which gives a key full access to its workspace. It must be the only scope, and only a workspace owner can create it. - `rzv api-keys create --scopes logs:read,audit:read` Adds the logs:read scope for job log text and the audit:read scope for the workspace activity log. jobs:read stays metadata only. - `rzv workspace` Workspace settings, member and invitation commands now accept RZV_API_KEY. Core checks the key's scope and its creator's current role. Accepting an invitation still needs a human sign-in. - rzv CLI 0.7.0 matches @runzivo/customer-sdk 0.7.0. 5. October 14, 2026 ## [rzv CLI 0.4.0: staff SDK compatibility](https://runzivo.dev/changelog/rzv-cli-0-4-0/) rzv CLI 0.4.0 is available from the installer. It matches @runzivo/customer-sdk 0.4.0 and adds no new rzv commands. - @runzivo/customer-sdk 0.4.0 adds fleet.read and logs.read staff permission vocabulary and generated staff API types for console routes. - rzv CLI 0.4.0 aligns its package version with the SDK. It adds no new rzv commands. - rzv CLI 0.4.0 is available from the installer. @runzivo/customer-sdk 0.4.0 is not published to a package registry. Staff console access is restricted to authorized Runzivo staff. 6. October 14, 2026 ## [rzv CLI 0.3.4: workspace and API-key management](https://runzivo.dev/changelog/rzv-cli-0-3-4/) rzv CLI 0.3.4 adds workspace, API-key, and prepaid-purchase commands; the matching service update is pending. - `rzv workspace` Adds workspace settings, member, and invitation commands, including invitation create, resend, revoke, and accept. - `rzv api-keys ` Adds lifecycle management for delegated read API keys. A created secret is shown once. Rename changes only an active key's display name. - `rzv billing purchases` Lists a bounded set of prepaid purchases for the selected workspace. - `rzv billing portal ` Requests a sensitive Creem-hosted billing-management link only for an eligible verified payer. The command does not download invoices or manage saved payment methods. - rzv CLI 0.3.4 is available from the installer. The matching service update is pending. These commands will work once that update is deployed. @runzivo/customer-sdk 0.3.4 is not published to a package registry. Live provider behavior and invoice delivery have not been verified. Payment-provider activation and invitation email delivery remain disabled. 7. October 9, 2026 ## [rzv CLI 0.3.3: runner-profile availability updates](https://runzivo.dev/changelog/rzv-cli-0-3-3/) rzv CLI 0.3.3 recognizes current and legacy installation-account availability reasons when reading runner profiles. - `rzv runner-profiles ` Recognizes the server's new installation-account availability reasons instead of rejecting a valid runner-profile response. - Upgrade to this release before using a server that returns the new installation-account availability reasons. It adds no new rzv command. 8. October 8, 2026 ## [rzv CLI 0.3.2: matching SDK release](https://runzivo.dev/changelog/rzv-cli-0-3-2/) rzv CLI 0.3.2 aligns the CLI package version with the accompanying SDK. It adds no new rzv commands. - Refreshes the CLI package to version 0.3.2 to match the accompanying SDK. It adds no new rzv command. - The accompanying SDK adds the staff customer-directory client for internal staff tooling. - The accompanying server release includes internal onboarding-notification handling. SMTP delivery remains off. 9. October 8, 2026 ## [rzv CLI 0.3.1: clearer authorization errors, exact balances](https://runzivo.dev/changelog/rzv-cli-0-3-1/) rzv CLI 0.3.1 explains GitHub authorization failures and shows Billing balances exactly. - `rzv github authorize` Names what went wrong with GitHub device authorization, such as an expired code or a failed GitHub request, instead of a generic error. - `rzv billing` Shows allowance and balance in exact equivalent minutes, including fractions of a minute. - Release notes are on GitHub at Runzivo/rzv-cli. 10. October 8, 2026 ## [rzv CLI 0.3.0: test-mode Billing](https://runzivo.dev/changelog/rzv-cli-0-3-0/) rzv CLI 0.3.0 adds test-mode Billing commands. Customer charging stays disabled in this release. - `rzv billing` Shows the test-mode allowance, balance, and USD checkout packs for the selected account. - `rzv billing checkout --pack ` Starts a hosted test checkout for one pack. - `rzv billing checkout --pack --operation-id ` Retries after an unclear failure by replaying the same attempt instead of starting a new one. - Release notes are on GitHub at Runzivo/rzv-cli. --- Source: https://runzivo.dev/changelog/page/4/ # Changelog Subscribe via [RSS](https://runzivo.dev/changelog/rss.xml) to receive Runzivo product and service updates. 1. October 8, 2026 ## [rzv CLI 0.3.0: GitHub authorization and runner profiles](https://runzivo.dev/changelog/rzv-cli-0-2-0/) These GitHub authorization and runner profile commands shipped in the rzv 0.3.0 release on this date. No 0.2.0 release was published. - `rzv github authorize` Completes rzv github connect using GitHub device flow. - `rzv runner-profiles` Lists the runner configurations available to a connected repository. - Release notes are on GitHub at Runzivo/rzv-cli. 2. October 4, 2026 ## [rzv installer and first-request fixes](https://runzivo.dev/changelog/rzv-release-2026-10-04/) rzv release-2026-10-04-161209: on minimal Linux images the installer now names a missing system library, usually libatomic1, and prints the command to install it. The first request after a Runzivo service restart no longer fails. 3. October 3, 2026 ## [rzv CLI available](https://runzivo.dev/changelog/rzv-cli-available/) The rzv command-line tool is available for macOS (Apple Silicon) and Linux x64. Runners stay Linux x64; macOS runners are not available. - `curl -fsSL https://runzivo.dev/downloads/rzv/install.sh | sh` Installs rzv. - Approved Early Access accounts can sign in, choose an account, and read job status. - Release notes are on GitHub at Runzivo/rzv-cli. 4. September 13, 2026 ## [Initial publication](https://runzivo.dev/changelog/initial-publication/) Published the public Runzivo V1 changelog. V1 scope is managed Linux x64 compute for GitHub Actions. --- Source: https://runzivo.dev/changelog/portal-navigation-and-runner-templates/ # Portal navigation and Runner Templates October 23, 2026 A regrouped portal sidebar and the Runner Templates page are now available. - The portal sidebar groups services by area. Planned services show a Soon label and don't open a page. Workspace settings are tabs under Settings, and your own profile, appearance, language and timezone are in the account menu. - Runner Templates is available under CI & Runners. It lists ten GitHub Actions workflows for Runzivo runners, with filters, a YAML preview and a copy button, in English and French. - The Terraform template applies only on pushes to main through a GitHub environment. Add required reviewers to that environment before you use apply. --- Source: https://runzivo.dev/changelog/portal-sessions/ # Customer portal sessions October 19, 2026 Customer portal sessions last 14 days without activity and 30 days at most, keep sign-in tokens on the server, and ask you to confirm your identity before sensitive actions. - You stay signed in to the customer portal for 14 days without activity, and for 30 days at most. Your sign-in survives browser restarts. - Only your own activity, such as opening pages or taking actions, keeps a session alive. Background refreshes do not. - Your browser holds only an opaque session cookie. Sign-in tokens stay on the server, which renews short-lived access tokens. - Signing out ends the session immediately. Suspending an account or signing it out everywhere ends all of its sessions immediately. - When this update ships, everyone is signed out of the customer portal once. Sign in again to start a new session. - API key changes, account security settings, and billing changes (when paid billing is enabled) ask you to confirm it's you if you have not signed in recently. The sign-in and sessions guide lists the actions and the time limit. --- Source: https://runzivo.dev/changelog/rzv-cli-0-10-0/ # rzv CLI 0.10.0: support tickets October 26, 2026 rzv 0.10.0 adds support ticket commands and organization-only onboarding docs. - `rzv tickets list|open|show|reply` Work with support tickets for the selected workspace. Output supports --json. - Add --personal to work with your own tickets instead. It rejects RZV_API_KEY. - The onboarding docs say Runzivo is for organizations only. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-11-0/ # rzv CLI 0.11.0: connection commands and clearer errors October 26, 2026 rzv 0.11.0 adds gitlab connection commands, and GitLab is not part of V1. Messages for integrations that are not enabled are clearer. - GitLab is not part of V1 and is not enabled for workspaces yet. The rzv gitlab commands report that it isn't enabled. - `rzv gitlab connections` Lists the connections for the selected workspace. - `rzv gitlab connect` Opens the portal page where you set up the integration for the selected workspace. - `rzv gitlab disconnect` Removes a connection. A connection id must match glc\_ followed by 24 lowercase hex digits. - When an integration is not enabled for your account, the command says so in plain words instead of printing the raw error code. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-12-0/ # rzv CLI 0.12.0: concurrency and runner commands October 26, 2026 rzv 0.12.0 adds commands for concurrency limits and runner profiles and inventory. - `rzv concurrency` Shows the concurrent-job limit for the selected workspace, the jobs running now, and how many slots are left. - `rzv runners ` Shows the runner sizes a repository can use, with the workspace's running and waiting jobs on each. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-13-0/ # rzv CLI 0.13.0: billing commands October 26, 2026 rzv 0.13.0 adds billing invoices, automatic recharge, billing country, credit pack checkout and the billing portal. - `rzv billing invoices` Lists the invoices for the selected workspace. - `rzv billing auto-recharge` Reads and sets automatic recharge. Turning it on needs a person signed in, not an API key. - `rzv billing country` Reads and sets the billing country for the selected workspace. - `rzv billing checkout --pack --operation-id` Prints a link to the payment page for a credit pack, where card payments are available for your workspace. Card payments stay off until Runzivo turns them on; until then, buy credits by bank transfer from the portal. Reuse --operation-id when you retry the same purchase. - `rzv billing portal` Prints a link to the billing portal. - A refused billing change says why: your role does not allow it, or you need to run rzv login again. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-14-0/ # rzv CLI 0.14.0: workspace access commands October 26, 2026 rzv 0.14.0 adds workspace settings, member and invitation commands, and a way to clear the billing country. - `rzv workspaces settings show|update` Shows and updates the settings for the selected workspace. - `rzv workspaces members list|role|remove` Lists workspace members, changes a member's role, or removes a member. - `rzv workspaces invitations list|invite|resend|revoke|teams|accept` Lists, sends, resends and revokes invitations, sets custom teams on an invitation, and accepts an invitation with your own sign-in. - `rzv billing country reset` Clears a billing country that no purchase has used yet, so the next purchase asks for it again. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-15-0/ # rzv CLI 0.15.0: teams and permissions commands October 27, 2026 rzv 0.15.0 adds team commands and a command that shows your workspace permissions. - `rzv teams list|show|create|rename|permissions|add-member|remove-member|delete` Lists, shows, creates, renames and deletes teams, sets team permissions, and adds or removes team members for the selected workspace. - `rzv permissions` Shows your permissions in the selected workspace, with the permission catalogue and presets. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-16-0/ # rzv CLI 0.16.0: close support tickets October 27, 2026 rzv 0.16.0 adds a command that closes a support ticket you have open. - `rzv tickets close ` Closes a support ticket you have open, for the selected workspace or with --personal. The ticket is marked resolved. A ticket that is already closed says so. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-17-0/ # rzv CLI 0.17.0: activity, notifications, insights and more October 28, 2026 rzv 0.17.0 adds activity, notification, insight, AI, GitHub onboarding, code redemption and workspace closure commands. - `rzv activity list|export|status` Lists workspace activity with filters and paging, exports it as CSV, and shows audit signals with execution evidence. - `rzv api-keys create --permissions ` Creates an API key with fine-grained permissions. List, create and rename show each key's permissions. - `rzv notifications list|read|settings` Lists workspace notifications, marks them read, and shows or changes delivery settings. Needs your own sign-in. - `rzv jobs logs ` Shows a job's log text, or why it is not available. - `rzv insights summary|heatmap|slow-jobs` Shows job and minute totals, queue activity by hour, and the slowest workflows for the selected workspace. - `rzv ai providers|settings|usage` Manages the workspace AI provider connections and settings, and reports AI usage. Provider keys are read only from --key-file. - `rzv github installations` Lists every linked GitHub App installation with its setup and repository state. - `rzv github workspaces start|complete` Creates a workspace from a GitHub installation. - `rzv billing codes redeem --code-file ` Redeems a promo code or prepaid voucher for the selected workspace. - `rzv workspaces closures list|request|cancel` Asks Runzivo to close a workspace, or withdraws the request. Nothing is deleted immediately. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-18-0/ # rzv CLI 0.18.0: sign-in profiles October 28, 2026 rzv 0.18.0 adds sign-in profiles and a default workspace setting. - `rzv login -p [-w ]` Keeps one sign-in per profile, so signing in to a second account no longer replaces the first. -p works on every command, and RZV_PROFILE sets the profile for a shell. - `rzv profiles list|use|remove` Lists your local profiles, switches the active one, or removes a profile's local sign-in. - RZV_WORKSPACE sets the default workspace, and --workspace accepts a workspace slug as well as an id. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-19-0/ # rzv CLI 0.19.0: new sign-in address October 29, 2026 rzv 0.19.0 signs in at the new production identity host. - Production sign-in moves to id.runzivo.dev. Run rzv login after upgrading; a sign-in made with an older rzv does not work with the new identity host. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-2-0/ # rzv CLI 0.3.0: GitHub authorization and runner profiles October 8, 2026 These GitHub authorization and runner profile commands shipped in the rzv 0.3.0 release on this date. No 0.2.0 release was published. - `rzv github authorize` Completes rzv github connect using GitHub device flow. - `rzv runner-profiles` Lists the runner configurations available to a connected repository. - Release notes are on GitHub at Runzivo/rzv-cli. --- Source: https://runzivo.dev/changelog/rzv-cli-0-20-0/ # rzv CLI 0.20.0: Agent Sandboxes commands October 31, 2026 rzv 0.20.0 adds commands for Agent Sandboxes. - `rzv sandboxes list|get|create|start|stop|delete` Creates and manages Agent Sandboxes, Linux virtual machines that last eight hours from their first start. list shows the sizes the environment offers. - `rzv sandboxes exec -- ` Runs a command with streamed output and exits with its status. It exits with 137 when output passes 8 MiB, and says when the sandbox stopped, expired or was deleted during the command. - `rzv sandboxes ssh ` Opens an interactive terminal and says why it closed. It does not run on Windows. - `rzv sandboxes terminal-ticket ` Prints a single-use terminal URL for a client that cannot send an Authorization header, such as a browser. - Every sandboxes command except ssh accepts --json. A command run without its subcommand prints its usage on separate lines. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-21-0/ # rzv CLI 0.21.0: larger sandbox sizes and exact exec arguments October 31, 2026 rzv 0.21.0 adds two larger sandbox sizes and runs exec arguments exactly as typed. - `rzv sandboxes create --size 8vcpu-32gb|16vcpu-64gb` Accepts the 8vcpu-32gb and 16vcpu-64gb sandbox sizes as well as 2vcpu-8gb and 4vcpu-16gb. Which sizes can start now depends on capacity; rzv sandboxes list shows them. - `rzv sandboxes exec -- ` With two or more arguments after --, quotes each one, so the sandbox runs exactly the argument list you typed. One argument still runs as a shell script; put pipes, && or $VARS in a single quoted argument. - The sandboxes help describes API key access correctly: sandboxes:read and sandboxes:write are key permissions, granted with rzv api-keys create --permissions, or use the all:all scope. - Downloads are on GitHub at https://github.com/Runzivo/rzv-cli/releases/latest. Release notes are on the same page. --- Source: https://runzivo.dev/changelog/rzv-cli-0-3-0/ # rzv CLI 0.3.0: test-mode Billing October 8, 2026 rzv CLI 0.3.0 adds test-mode Billing commands. Customer charging stays disabled in this release. - `rzv billing` Shows the test-mode allowance, balance, and USD checkout packs for the selected account. - `rzv billing checkout --pack ` Starts a hosted test checkout for one pack. - `rzv billing checkout --pack --operation-id ` Retries after an unclear failure by replaying the same attempt instead of starting a new one. - Release notes are on GitHub at Runzivo/rzv-cli. --- Source: https://runzivo.dev/changelog/rzv-cli-0-3-1/ # rzv CLI 0.3.1: clearer authorization errors, exact balances October 8, 2026 rzv CLI 0.3.1 explains GitHub authorization failures and shows Billing balances exactly. - `rzv github authorize` Names what went wrong with GitHub device authorization, such as an expired code or a failed GitHub request, instead of a generic error. - `rzv billing` Shows allowance and balance in exact equivalent minutes, including fractions of a minute. - Release notes are on GitHub at Runzivo/rzv-cli. --- Source: https://runzivo.dev/changelog/rzv-cli-0-3-2/ # rzv CLI 0.3.2: matching SDK release October 8, 2026 rzv CLI 0.3.2 aligns the CLI package version with the accompanying SDK. It adds no new rzv commands. - Refreshes the CLI package to version 0.3.2 to match the accompanying SDK. It adds no new rzv command. - The accompanying SDK adds the staff customer-directory client for internal staff tooling. - The accompanying server release includes internal onboarding-notification handling. SMTP delivery remains off. --- Source: https://runzivo.dev/changelog/rzv-cli-0-3-3/ # rzv CLI 0.3.3: runner-profile availability updates October 9, 2026 rzv CLI 0.3.3 recognizes current and legacy installation-account availability reasons when reading runner profiles. - `rzv runner-profiles ` Recognizes the server's new installation-account availability reasons instead of rejecting a valid runner-profile response. - Upgrade to this release before using a server that returns the new installation-account availability reasons. It adds no new rzv command. --- Source: https://runzivo.dev/changelog/rzv-cli-0-3-4/ # rzv CLI 0.3.4: workspace and API-key management October 14, 2026 rzv CLI 0.3.4 adds workspace, API-key, and prepaid-purchase commands; the matching service update is pending. - `rzv workspace` Adds workspace settings, member, and invitation commands, including invitation create, resend, revoke, and accept. - `rzv api-keys ` Adds lifecycle management for delegated read API keys. A created secret is shown once. Rename changes only an active key's display name. - `rzv billing purchases` Lists a bounded set of prepaid purchases for the selected workspace. - `rzv billing portal ` Requests a sensitive Creem-hosted billing-management link only for an eligible verified payer. The command does not download invoices or manage saved payment methods. - rzv CLI 0.3.4 is available from the installer. The matching service update is pending. These commands will work once that update is deployed. @runzivo/customer-sdk 0.3.4 is not published to a package registry. Live provider behavior and invoice delivery have not been verified. Payment-provider activation and invitation email delivery remain disabled. --- Source: https://runzivo.dev/changelog/rzv-cli-0-4-0/ # rzv CLI 0.4.0: staff SDK compatibility October 14, 2026 rzv CLI 0.4.0 is available from the installer. It matches @runzivo/customer-sdk 0.4.0 and adds no new rzv commands. - @runzivo/customer-sdk 0.4.0 adds fleet.read and logs.read staff permission vocabulary and generated staff API types for console routes. - rzv CLI 0.4.0 aligns its package version with the SDK. It adds no new rzv commands. - rzv CLI 0.4.0 is available from the installer. @runzivo/customer-sdk 0.4.0 is not published to a package registry. Staff console access is restricted to authorized Runzivo staff. --- Source: https://runzivo.dev/changelog/rzv-cli-0-7-0/ # rzv CLI 0.7.0: API key scopes October 16, 2026 rzv CLI 0.7.0 adds the all:all, logs:read and audit:read API key scopes and lets workspace commands run with an API key. - `rzv api-keys create --scopes all:all` Adds the all:all scope, which gives a key full access to its workspace. It must be the only scope, and only a workspace owner can create it. - `rzv api-keys create --scopes logs:read,audit:read` Adds the logs:read scope for job log text and the audit:read scope for the workspace activity log. jobs:read stays metadata only. - `rzv workspace` Workspace settings, member and invitation commands now accept RZV_API_KEY. Core checks the key's scope and its creator's current role. Accepting an invitation still needs a human sign-in. - rzv CLI 0.7.0 matches @runzivo/customer-sdk 0.7.0. --- Source: https://runzivo.dev/changelog/rzv-cli-0-9-0/ # rzv CLI 0.9.0: Go rewrite and single-file downloads October 19, 2026 rzv 0.9.0 is rewritten in Go and ships as single-file downloads for Linux, Mac and Windows. - rzv is rewritten in Go. Each download is one file with no runtime dependencies, and Linux no longer needs libatomic1. - rzv accounts is now rzv workspaces. The old name still works, and --workspace replaces --account, which also still works. - Downloads are available for Linux arm64, Intel Macs and Windows x86-64, alongside Linux x86-64 and Apple Silicon Macs. - `rzv whoami` Shows the signed-in identity, environment, session expiry and selected workspace. - `rzv login --env prd|shared` Chooses the environment. Production is the default, and --no-browser is available. - RZV_API_KEY works without a stored sign-in when you pass --workspace. - `rzv repositories list` Lists the repositories available to your workspace. - Release notes are on GitHub at Runzivo/rzv-cli. --- Source: https://runzivo.dev/changelog/rzv-cli-available/ # rzv CLI available October 3, 2026 The rzv command-line tool is available for macOS (Apple Silicon) and Linux x64. Runners stay Linux x64; macOS runners are not available. - `curl -fsSL https://runzivo.dev/downloads/rzv/install.sh | sh` Installs rzv. - Approved Early Access accounts can sign in, choose an account, and read job status. - Release notes are on GitHub at Runzivo/rzv-cli. --- Source: https://runzivo.dev/changelog/rzv-release-2026-10-04/ # rzv installer and first-request fixes October 4, 2026 rzv release-2026-10-04-161209: on minimal Linux images the installer now names a missing system library, usually libatomic1, and prints the command to install it. The first request after a Runzivo service restart no longer fails. --- Source: https://runzivo.dev/changelog/team-and-business-plans/ # Team and Business plans October 31, 2026 Team and Business plans are available in the portal. - Owners and admins can subscribe to Team or Business in the portal under Billing & Credits, billed monthly or yearly. A yearly plan costs 15% less than twelve monthly payments. - A plan's included unit-minutes are granted each month and do not roll over. Usage draws on included unit-minutes first, then prepaid credit, then overage up to the plan's monthly overage cap. Overage is invoiced monthly. - If a renewal payment fails, a grace period of 7 days starts by default. To cancel or change a plan, contact support. A cancellation takes effect at the end of the paid term. --- Source: https://runzivo.dev/investors/ # A focused CI compute service, live in Early Access. Runzivo V1 is in Early Access: managed Linux x64 compute for GitHub Actions. [Book an investor call](https://calendar.app.google/MHx9yPmWJmw3Gcbc8) [Email investors](mailto:investors@runzivo.dev?subject=Investor%20inquiry) ## The problem CI is part of the feedback loop for every software change. Hosted runners remove infrastructure work, while self-hosted runners give teams more control but create runner fleet operations. Runzivo focuses on the gap between these choices. ## What is live today Runzivo V1 is live in Early Access: managed Linux x64 runners for GitHub Actions. Each eligible job runs in a fresh Firecracker microVM that is destroyed when the job finishes. Teams change one runner label and keep their workflow steps. The production service went live in October 2026. Customers use the portal and the rzv command-line tool, and each workspace gets a free monthly allowance. Workspaces billed in Canada and the United States can buy prepaid credit packs by card through Stripe. See [pricing](https://runzivo.dev/pricing/). ## Built, not yet switched on Team and Business subscriptions are in development and not live yet. The AI features are built and in early access: an AI chat, a pipeline builder that writes GitHub Actions workflows, and a CI fix agent that proposes fixes as pull requests. They stay off for customers until they are enabled for a workspace. ## Platform foundations The service also has workspace teams and permissions, a notification engine, and a staff console for running the platform, with most settings managed there instead of in server configuration. ## What Early Access will measure We measure recurring workloads against comparable queue, start and runtime baselines. We also measure reliability, teardown behavior, retention and unit economics without cloud credits. We make no broader claims until we have those results. --- Source: https://runzivo.dev/legal/privacy/ # Runzivo Privacy Notice Last updated: October 31, 2026 **Working draft, pending legal review.** This draft describes the website and current services, including paid plans and prepaid credits. Legal review remains pending; service availability does not mean this notice has been legally approved. ## Who we are Runzivo Technologies Inc. is a corporation incorporated in Ontario, Canada. We handle personal information in line with Canada's Personal Information Protection and Electronic Documents Act (PIPEDA). ## Who this notice covers This notice explains how Runzivo handles information you submit when you use the website, join the newsletter, contact us, or use a workspace, GitHub Actions runners or Agent Sandboxes. ## Newsletter subscriptions When you subscribe to the Runzivo newsletter, we collect your email address to send product updates, engineering notes, and pilot news. Buttondown processes the subscription and delivers the emails on our behalf. You can unsubscribe from any newsletter email or contact [hello@runzivo.dev](mailto:hello@runzivo.dev) to ask us to remove your address. ## Early Access and partner requests When you email us, book a call, or complete our partner form, we collect the details you choose to send, such as your name, email address, organization, and a description of your workflows. We use them to respond, assess fit, and run Early Access. Do not send credentials, secrets, or sensitive workflow data. ## Service providers We use service providers to run the website and handle requests: Buttondown for the newsletter, Google Workspace for email and call booking, Tally for the partner form, GitHub for the Runzivo GitHub App, Stripe to process card payments for workspaces billed in Canada and the United States, Leadsy to identify the organizations that visit the website, and LinkedIn to measure advertising. These providers may store or process information outside Canada, including in the United States and the European Union, where it may be subject to local laws. ## Cookies and visitor tracking With your permission, the runzivo.dev website loads a Leadsy script that records visits, may set cookies, and may identify the company a visitor works for, using the visitor's IP address, browser details, and the pages viewed. We use this to understand which organizations are interested in Runzivo. With the same permission, the website also loads the LinkedIn Insight Tag. LinkedIn uses it to measure how our LinkedIn ads perform and to let us reach groups of past website visitors on LinkedIn. LinkedIn does not share the identities of individual visitors with us. See [LinkedIn's Privacy Policy](https://www.linkedin.com/legal/privacy-policy). These scripts load only after you choose Accept in the cookie banner. If you choose Reject, make no choice, or your browser sends a Global Privacy Control signal, they do not load. Your choice is stored in your browser, and you can change it at any time with Cookie settings at the bottom of every page. You can also contact [hello@runzivo.dev](mailto:hello@runzivo.dev) to ask about information collected about you. The customer portal at app.runzivo.dev sets a strictly necessary session cookie when you sign in. It holds an opaque session identifier, not your sign-in tokens, and lasts up to 30 days. The portal needs it to keep you signed in, so the cookie banner does not control it. Signing out ends the session. ## Information involved in service operation To authorize and operate runners and Agent Sandboxes, Runzivo processes GitHub App installation and repository identifiers, workflow-job lifecycle information, runner and capacity records, and service logs needed for reliability, security, limits, and incident investigation. Runzivo keeps an activity log for each workspace: who acted, how they signed in (browser session, API key or CLI token), the action, its target and result, the time, the client IP address seen by our edge, and the browser or client user agent. We use it for security, abuse prevention and support. Workspace owners and admins can see every entry for their workspace, including members' IP addresses; members see their own entries; authorized Runzivo staff can see all entries. ## Workflow data and secrets Workflows are configured in GitHub. You control the source code, environment settings, and secrets available to a job through GitHub. Do not expose secrets in logs or support material. Runzivo does not add repository secrets to runner configuration, and platform credentials are not injected into customer workers. ## How information is used The V1 design uses operational information to authorize requested work, run and tear down isolated workers, enforce usage controls, maintain security, investigate failures, and improve the service. Workspace insights, such as job counts, durations and the job activity heat map, are built from these records and shown to members of that workspace. ## Retention We keep newsletter details until you unsubscribe. We keep Early Access and partner correspondence for as long as we need it to respond and run Early Access, then delete it unless the law requires us to keep it. We keep workspace activity log entries for 180 days, then delete them. ## Your choices and rights You can ask to see the personal information we hold about you, ask us to correct it, or withdraw your consent, subject to legal limits. Contact us at the address below. If you are not satisfied with our response, you can contact the Office of the Privacy Commissioner of Canada. ## Updates This notice remains a working draft and will be updated as the service and its legal review progress. ## Privacy contact Runzivo Technologies Inc. has designated a privacy officer. For privacy questions or requests, contact [hello@runzivo.dev](mailto:hello@runzivo.dev). --- Source: https://runzivo.dev/legal/terms/ # Runzivo Service Terms Last updated: October 31, 2026 **Working draft, pending legal review.** These terms have not completed legal review. The website currently offers Developer workspaces, paid plans and prepaid credits; availability does not mean this draft has been legally approved. ## Scope This draft describes Runzivo services provided by Runzivo Technologies Inc., including GitHub Actions runners on Linux x64 and Agent Sandboxes. AI CI tools remain Early Access; Devboxes are coming soon. See the pricing page and documentation for current availability. The existing Early Access provisions below apply to Early Access participation; they do not establish reviewed terms for paid subscriptions. Paid-service terms remain subject to legal review. ## Access and acceptable use Developer workspaces are available through signup. Team and Business subscriptions and prepaid credits are available through the portal. Early Access features require workspace enablement. Access to Early Access features may be limited, changed, suspended, or withdrawn while those features are evaluated. You are responsible for your GitHub organization, repositories, workflow configuration, and the code you run. Do not use the service to violate applicable law, interfere with other users, bypass authorization or capacity controls, or run workloads intended to abuse compute or network resources. ## Service capacity and allowances Current plan allowances and prices are described on the [pricing page](https://runzivo.dev/pricing/). Paid plan allowances replace the Developer allowance. Usage draws on included unit-minutes first, then prepaid credits, then eligible plan overage. Plans have controlled capacity. Developer and Team: “Run up to your plan's concurrent job limit. Jobs may queue when runner capacity is unavailable.” Business: “Higher concurrency limits, with optional dedicated, pre-warmed runner pools for guaranteed reserved capacity.” Dedicated pools are available on request (contact sales: run@runzivo.dev). No current service-level agreement applies. ## Founding offer The first 100 organizations to activate paid Runzivo service will keep the published runner rates shown on the pricing page for those same services, for the lifetime of an eligible paid account. To remain eligible, an organization must maintain a continuous paid account, renew when due, and remain in good standing. It must also complete at least one CI job in each rolling 90-day period. A CI job covered by a usage allowance counts toward this activity requirement. Eligibility ends if the organization cancels, does not renew, does not pay when due, or has no completed CI job during a rolling 90-day period. If service resumes after eligibility ends, then-current rates apply. The offer is not transferable and excludes future products and custom Enterprise pricing. ## Payments and currency Prices are listed in Canadian dollars, US dollars, euros and pounds sterling. Payment is currently in Canadian or US dollars: by card for workspaces billed in Canada or the United States, or by bank transfer in Canadian or US dollars. Card payments are processed by Stripe, and Runzivo is the seller for those sales. Card checkout is available only for workspaces billed in Canada or the United States. Runzivo is not registered to collect sales tax yet, so no tax is charged on any payment. See [currency and payments](https://runzivo.dev/pricing/#currency). ## Security and credentials Keep your GitHub account and organization controls secure. Do not place credentials or secret values in workflow logs or support requests. You remain responsible for the permissions and secrets made available to your workflows through GitHub. ## Feedback Early Access feedback helps Runzivo evaluate and improve the service. Runzivo may use feedback without obligation, while respecting the confidentiality commitments agreed with an approved organization, if any. ## No warranty Early Access is pre-release software provided "as is" and "as available", without warranties of any kind, to the extent the law allows. It may contain errors, change, or be unavailable. ## Limitation of liability To the extent the law allows, Runzivo Technologies Inc. is not liable for indirect, incidental, special, or consequential damages, or for lost data, profits, or revenue, arising from Early Access. ## Suspension and termination Either party may stop Early Access participation at any time. Runzivo may suspend access immediately to protect the service, other users, or its infrastructure. You can leave by changing your workflow label back and uninstalling the Runzivo GitHub App. ## Governing law These terms are governed by the laws of the Province of Ontario and the federal laws of Canada that apply there. ## Legal contact Runzivo Technologies Inc. is a corporation incorporated in Ontario, Canada. For legal questions about these draft terms, contact [hello@runzivo.dev](mailto:hello@runzivo.dev).