Preview your web apps with RWX

We're excited to roll out RWX web apps, giving teams a simple way to expose a preview web app from an RWX run definition.

These days, code moves faster than traditional environment strategies were designed for. A fixed path from development to staging to production can work for release gates, but it’s a poor fit for reviewing every branch, pull request, or agent-generated change. Those environments become shared bottlenecks, or they turn into a pile of infrastructure your team has to keep alive.

RWX web apps give you another option: a deployed preview environment for each change, without maintaining a separate preview deployment system. Build the app, start the services it needs, boot the server, and share a URL.

Because web apps spin down after they’ve been idle, keeping a URL around for every branch or pull request doesn’t mean keeping every preview running. When someone opens the URL again, RWX starts it back up.

That setup can live in your existing run definition:

tasks:
  # your tasks to build the app

  - key: my-app
    use: [build]
    app:
      endpoint: pr-${{ init.pull-request-number }}
      port: 3000
    run: ./start-your-app

A web app task runs a long-lived process and serves traffic on a public rwx.run URL. The endpoint becomes part of the subdomain, and the port is where RWX sends traffic to your server process.

If your app needs a database, cache, or other backing services, you can start them with background-processes before the server boots. That means the preview environment can use the same Docker Compose services, installation tasks, and build outputs that the rest of your RWX run uses.

And because it runs on RWX, your preview app also benefits from content-based caching. Dependency installation, generated assets, build outputs, and other setup work can be reused when nothing relevant has changed, keeping preview apps fast without maintaining a separate image or snapshot system.

Once the app is running, RWX gives you a URL you can print, post to a pull request, send to Slack, or hand to an agent. You can use a canonical URL pinned to a specific cache key, which is useful for integration tests that should run against a stable preview. Or you can use a friendly URL that tracks the latest build for a given endpoint. Both variants are accessible from within your tasks.

Learn more in the docs.