The agent-native cloud platform for sandboxes, CI pipelines, and building container images.

RWX gives developers and AI agents a programmatic interface to run code in the cloud with sub-second cached builds, DAG-based parallelization, and structured output. Developers and agents can iterate on changes until CI passes — without a single commit or push.

Features

DAG-based execution — Define task dependencies as a graph. RWX determines optimal ordering and runs independent tasks in parallel automatically.
Content-based caching — Results are cached based on filesystem contents and reused across runs. Individual tasks cache independently, so a single cache miss doesn't invalidate everything.
Right-sized compute — Each task specifies its own CPU and memory requirements, up to 64 cores. No fixed runner sizes.
Agent-native — Trigger builds from the CLI and iterate on changes before pushing. AI agents and developers get immediate feedback loops with rwx run --wait, rwx results, rwx logs, and rwx artifacts — all with --output json for machine-readable results.
Container image builds — Build OCI-compatible images without Dockerfiles. Tasks execute on separate machines in parallel and combine into a single image.
Semantic output — Structured results rather than raw logs. Failed tests, filesystem contents, and detailed diagnostics are accessible programmatically.
Remote debugging — SSH into running tasks or set breakpoints to inspect intermediate state.

Install the RWX Skill

The RWX Skill gives AI coding agents direct access to RWX — agents can find relevant documentation, lint run definition files, and validate changes with real RWX runs. The skill provides deterministic tools instead of relying on web searches, so agents generate accurate run definitions from scratch or migrate existing ones from platforms like GitHub Actions.

Claude Code:

/install-skill rwx

Cursor, GitHub Copilot, OpenAI Codex, and other agents:

npx skills add rwx-cloud/skills

Once installed, agents can:

/rwx — Invoke the skill directly with a prompt
rwx docs search <query> — Search RWX documentation
rwx lint — Validate run definition syntax
rwx run <file> --wait — Execute runs and iterate until they pass
rwx logs / rwx artifacts — Debug failures programmatically
rwx packages list / rwx packages show — Browse built-in packages

Getting Started

Install the CLI

macOS & WSL:

brew install rwx-cloud/tap/rwx

Linux:

Download the latest release from GitHub for your platform, then move the binary to a directory in your PATH.

Authenticate

rwx login

Verify with rwx whoami. You'll need an RWX Cloud account and an organization.

VS Code Extension

ext install RWX.rwx-vscode-extension

Or find it on the VS Code Marketplace.

Run your first task

Create a tasks.yml:

base:
  image: ubuntu:24.04
  config: rwx/base 1.0.0

tasks:
  - key: hello-world
    run: echo hello world

rwx run tasks.yml --open

The CLI outputs a URL to view results. The --open flag launches your browser automatically.

Connect to GitHub

Install the RWX GitHub App to trigger runs on push and report commit status checks back to GitHub.

Create .rwx/push.yml in your repository:

on:
  github:
    push:
      init:
        commit-sha: ${{ event.git.sha }}

base:
  image: ubuntu:24.04
  config: rwx/base 1.0.0

tasks:
  - key: code
    call: git/clone 2.0.3
    with:
      github-token: ${{ github.token }}
      commit-sha: ${{ init.commit-sha }}

  - key: test
    use: [code]
    run: echo "tests pass"

Push the commit and a status check appears on the commit in GitHub.

To run locally against any commit:

rwx run .rwx/push.yml --init commit-sha=$(git rev-parse HEAD) --open

See the full GitHub integration guide.

Connect to GitLab

Configure a GitLab integration from your RWX organization settings. You'll need a GitLab access token with api, self_rotate, and read_repository scopes. Group tokens work across all projects in a group; project tokens require setup per project.

Create .rwx/push.yml in your repository:

on:
  gitlab:
    push:
      init:
        commit-sha: ${{ event.git.sha }}

base:
  image: ubuntu:24.04
  config: rwx/base 1.0.0

tasks:
  - key: code
    call: git/clone 2.0.3
    with:
      ssh-key: ${{ gitlab['YOUR_ORG/YOUR_REPO'].ssh-key }}
      commit-sha: ${{ init.commit-sha }}

  - key: test
    use: [code]
    run: echo "tests pass"

Push the commit and a Pipeline link appears in GitLab's UI pointing to the RWX run.

See the full GitLab integration guide.

Sandboxes for Coding Agents

RWX sandboxes give coding agents isolated cloud environments to execute commands — run tests, install dependencies, start services — while the agent stays on your machine with your configuration and oversight.

Initialize a sandbox configuration:

rwx sandbox init

This generates .rwx/sandbox.yml. A minimal configuration:

on:
  cli:
    init:
      commit-sha: ${{ event.git.sha }}

base:
  image: ubuntu:24.04
  config: rwx/base 1.0.0

tasks:
  - key: code
    call: git/clone 2.0.3
    with:
      preserve-git-dir: true
      repository: https://github.com/your-org/your-repo.git
      ref: ${{ init.commit-sha }}
      github-token: ${{ github.token }}

  - key: sandbox
    use: code
    run: rwx-sandbox

Execute commands in the sandbox:

rwx sandbox exec -- npm test

Local changes automatically sync to the cloud before execution and sync back afterward. The sandbox persists between commands, so state like installed packages and running services carries over.

For more complex setups with background services like databases:

  - key: sandbox
    use: [code, docker-images, npm-install]
    docker: true
    background-processes:
      - key: start-databases
        run: docker compose up
        ready-check: rwx-docker-ready-check
    run: |
      npm run migrate
      rwx-sandbox

Sandboxes are uniquely identified by working directory, git branch, and config file — so multiple agents working in separate git worktrees each get their own isolated sandbox automatically.

rwx sandbox list          # List running sandboxes
rwx sandbox stop          # Stop current sandbox
rwx sandbox stop --all    # Stop all sandboxes
rwx sandbox reset         # Reset to fresh state

See the full sandboxes for coding agents guide.

CI Workflow Example

A typical CI workflow installs system packages, clones the repository, sets up a language runtime, installs dependencies, and runs tests. Here's a Node.js example triggered on pull requests:

on:
  github:
    pull_request:
      init:
        commit-sha: ${{ event.git.sha }}

base:
  image: ubuntu:24.04
  config: rwx/base 1.0.0

tasks:
  - key: code
    call: git/clone 2.0.3
    with:
      github-token: ${{ github.token }}
      commit-sha: ${{ init.commit-sha }}

  - key: node
    call: nodejs/install 1.1.11
    with:
      node-version: 20.12.1

  - key: npm-install
    use: [code, node]
    run: npm install
    filter:
      - package.json
      - package-lock.json

  - key: lint
    use: [code, node, npm-install]
    run: npm run lint

  - key: test
    use: [code, node, npm-install]
    run: npm test

The filter on npm-install ensures only changes to package.json and package-lock.json bust the cache — source code changes skip the install step entirely. lint and test run in parallel since neither depends on the other.

See the full CI reference workflow guide.

Building Container Images

RWX builds OCI-compatible container images natively — no Dockerfiles or BuildKit required. Tasks run in parallel across distributed infrastructure and combine into a single image. See RUNTIME.md for how this works under the hood.

A simple image that runs a script:

base:
  image: ubuntu:24.04
  config: none

tasks:
  - key: image
    run: |
      cat <<'EOF' > script.sh
      #!/usr/bin/env bash
      echo "hello from a container built on RWX"
      EOF
      chmod +x script.sh
      echo "$PWD/script.sh" | tee $RWX_IMAGE/command

Push the built image to a registry:

rwx image push <task-id> --to <registry>/<repository>:<tag>

A full Node.js image build with dependency caching and multi-stage isolation:

base:
  image: node:24.11.0-trixie-slim
  config: none

tasks:
  - key: system
    run: |
      apt-get -y update
      apt-get -y install curl jq
      apt-get -y clean

  - key: code
    use: system
    call: git/clone 2.0.3
    with:
      repository: https://github.com/your-org/your-repo.git
      ref: ${{ init.commit-sha }}
      github-token: ${{ github.token }}

  - key: npm-install
    use: code
    run: npm ci --omit=dev
    filter:
      - package.json
      - package-lock.json

  - key: image
    use: npm-install
    run: |
      echo "node" | tee $RWX_IMAGE/user
      echo "node server.js" | tee $RWX_IMAGE/command
    env:
      NODE_ENV: production

Image metadata like CMD, ENTRYPOINT, USER, and WORKDIR is set by writing to files under $RWX_IMAGE/. The filter on npm-install ensures dependency changes only bust the cache when package.json or package-lock.json actually change.

For orchestrating build, push, and test as a complete workflow, use embedded runs to split each phase into its own file. See the full building container images guide and migrating from Dockerfile.

Documentation

Support & Community

Discord — Chat with the engineering team
Slack — Shared channels for existing customers
Schedule a call — Video conference with the co-founders
GitHub Issues — For open source projects
Status Page

License

See LICENSE.

Accelerated Container Runtime

RWX is powered by a purpose-built container runtime designed for speed and parallelism. It rethinks CI and container image builds from first principles — replacing the VM-per-job model and sequential Dockerfile layers with graph-based task execution across distributed infrastructure.

How it works

Traditional CI systems run steps sequentially inside a single VM or container. RWX takes a different approach: tasks execute on separate machines simultaneously, each with right-sized compute, and results are combined through content-based caching.

Graph-based scheduling

Tasks are defined as a directed acyclic graph (DAG). The runtime analyzes dependencies and schedules independent tasks across distributed infrastructure in parallel. Only tasks whose inputs have changed are re-executed — unchanged tasks resolve instantly from cache.

This is a fundamental departure from systems like GitHub Actions, where parallelization requires manually partitioning work across separate jobs — each with duplicated setup steps. In RWX, maximum parallelization comes from the dependency graph itself. Engineers define what depends on what; the runtime handles the rest.

Pipeline definitions can also be generated at runtime, enabling dynamic workflows driven by code rather than static YAML.

Content-based caching with sandboxing

Rather than caching by key name or step order, the runtime caches based on actual filesystem contents. Tasks are sandboxed so that only files matching a filter specification exist on disk during execution. This prevents unrelated file changes from busting the cache and eliminates the manual hashFiles key management required by traditional CI.

This design means:

Cache hits survive misses — individual tasks cache independently, so a miss on one task doesn't invalidate downstream tasks
No all-or-nothing invalidation — unlike BuildKit, where a single changed layer rebuilds everything below it, RWX can resume cache hits after a miss
Cross-run reuse — cache is shared across branches, PRs, and local CLI runs
The entire registry is the cache — rather than limited per-branch or per-runner caches, the full history of cached results is available

Per-task compute

Each task specifies its own resource requirements. The runtime allocates the exact CPU and memory needed per task rather than provisioning a fixed-size runner for the entire pipeline. A compilation step can claim 16 cores while a linting step runs on 2 — simultaneously, on separate machines. Tasks scale up to 64 cores.

Minimal base images

RWX uses minimal container images rather than the bloated VM images common in traditional CI (GitHub Actions ships a 74 GiB image with hundreds of pre-installed packages). Dependencies are explicit, declared per-task, making builds portable and reproducible.

Building container images without Dockerfiles

RWX can build OCI-compatible container images without Dockerfiles or BuildKit. Instead of sequential RUN / COPY layers, images are defined as a graph of tasks — the same primitive used for CI pipelines.

Why replace Dockerfiles

Dockerfiles have fundamental limitations:

Build context overhead — most builds upload the entire repository into the build context, wasting time especially with remote builders
Sequential execution — layers execute one after another, even when they have no dependency on each other
Fragile caching — cache invalidation cascades: one changed layer rebuilds everything below it, forcing developers into tedious COPY ordering tricks
Multi-stage complexity — multi-stage builds help with parallelism but require manual COPY --from file transfers between stages

How task-based image builds work

The runtime saves the filesystem changes from every task, producing a container layer at each step. These layers compose into a final OCI-compatible image that can be pulled with docker pull or rwx image pull.

A Dockerfile like this:

FROM node:24-slim AS builder
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:24-slim AS runtime
COPY --from=builder /app/dist ./dist
CMD ["node", "dist/index.js"]

Becomes a set of tasks:

base:
  image: node:24-slim
  config: none

tasks:
  - key: code
    run: git clone ...

  - key: npm-install
    use: code
    run: npm ci
    filter:
      - package.json
      - package-lock.json

  - key: build
    use: code
    run: npm run build
    outputs:
      artifacts:
        - key: dist
          path: dist

  - key: dist
    run: cp -a ${{ tasks.build.artifacts.dist }}/. ./dist

  - key: image
    use: dist
    run: echo "node dist/index.js" | tee $RWX_IMAGE/command

Key differences from Dockerfiles:

npm-install and build can run in parallel on separate machines
filter ensures only package.json and package-lock.json affect the cache for npm-install — changes to source files don't trigger a reinstall
Artifacts replace COPY --from for transferring files between stages
Image metadata (CMD, ENTRYPOINT, ENV, WORKDIR) is set by writing to files under $RWX_IMAGE/

No compression overhead

Cloud networks are substantially faster than compression algorithms. The runtime stores and transmits layers uncompressed — it is faster to upload 1 GB of data than to gzip 1 GB of data. Storage cost is treated as negligible compared to compute cost.

No build context uploads

Instead of uploading the repository into a build context, RWX clones the repository directly on the build machine using its git/clone package. This avoids transferring the entire repo over the network before the build even starts.

Dockerfile instruction mapping

For teams migrating from Dockerfiles, each instruction has a direct equivalent:

Dockerfile	RWX
`FROM`	`base.image` in YAML config
`RUN`	Multi-line `run` scripts in tasks
`COPY` / `ADD`	`git/clone` package + `filter`
`CMD`	Write to `$RWX_IMAGE/command` or `command.json`
`ENTRYPOINT`	Write to `$RWX_IMAGE/entrypoint` or `entrypoint.json`
`ENV`	Task-level `env` configuration
`ARG`	Init parameters with `${{ init.param-name }}`
`WORKDIR`	Write path to `$RWX_IMAGE/workspace`
`LABEL`	Write to `$RWX_IMAGE/labels/{key}`
`USER`	Write username to `$RWX_IMAGE/user`
`SHELL`	Write to `$RWX_IMAGE/shell`

See the full Migrating from Dockerfile guide for detailed examples.

dan-manges/README.md

Select an option

No results found