Readyset Docs

Web UI

Start a local HTTP server that backs the RDST web client — a browser-based alternative to the CLI.

rdst web starts a local HTTP server that powers the RDST web client — a browser-based experience for every core RDST workflow. Use it when you want a visual alternative to the CLI without giving up the command line.

The CLI continues to work directly without the web server. rdst web is only required when you want the web client. Both share the same underlying services, the same configured targets, the same query registry, and the same audit snapshots.

Start the server

# Default: 127.0.0.1:8787
rdst web

Then open http://localhost:8787/ in your browser.

Other binding options

# Different port
rdst web --port 9000

# Bind to all interfaces (for remote access — see warning below)
rdst web --host 0.0.0.0 --port 8787

The server binds to 127.0.0.1 by default so only your local browser can reach it. If you pass --host 0.0.0.0, the server is reachable from your whole network. The server has no authentication of its own, so make sure the port is not exposed to untrusted networks.

What the web UI offers

The web client is designed to cover every main CLI workflow:

AreaWhat you can do in the browser
TargetsAdd, edit, test, and remove targets. Set the default.
TopLive-streaming slow-query view with sort, filter, and one-click analyze.
AnalyzePaste a query or pick one from the registry; see the full report with syntax-highlighted SQL, EXPLAIN output, index recommendations, and rewrites. Continue with an interactive Q&A pane.
AskNatural-language question → generated SQL → confirmation → result table.
ScanUpload or point at a directory to scan for ORM queries; view per-query risk scores.
Query registrySearch, filter, view, edit, and tag saved queries.
AuditRun a single-target audit with live progress; view past audit snapshots; diff across time.
FleetList every target with connectivity status; run a fleet audit with a concurrent progress view; diff fleet snapshots.
CacheDeploy Readyset, add and remove caches, view hit rates, run cache-compare benchmarks with a live latency chart.

Everything you can do from the CLI, you can do in the browser. Actions that modify state (adding caches, deploying Readyset) show a confirmation step first; you can copy the equivalent CLI command from any action panel for scripting.

How it streams

Several RDST operations take seconds to minutes — rdst top, rdst analyze, rdst audit, rdst fleet audit, rdst cache deploy. The web client uses Server-Sent Events (SSE) so you see each step land in real time instead of waiting for a blank screen to finish.

Typical event flow for an analyze:

  1. Connection opens, schema loading indicator
  2. EXPLAIN plan renders
  3. EXPLAIN ANALYZE progress bar (skippable from the UI)
  4. LLM insights stream in, section by section
  5. Validation results appear
  6. Final report is available for export

Running the UI alongside the CLI

The web server and the CLI are always in sync because they read and write the same local state. You can:

  • Start the server in one terminal, work in the CLI in another — registry changes appear in the browser immediately.
  • Register a new target via the CLI, refresh the UI, and it appears.
  • Run rdst audit in the terminal and open the resulting snapshot in the browser for a nicer visual view.

There is no separate daemon; rdst web is a stateless HTTP server over the same services the CLI uses directly.

Deployment patterns

For local development the default 127.0.0.1:8787 binding is exactly what you want. For shared team use, a few common patterns:

Run rdst web on a bastion host and forward the port over SSH:

# On the bastion, in a tmux session or similar:
rdst web --host 127.0.0.1 --port 8787

# On your laptop:
ssh -L 8787:localhost:8787 bastion.example.com
# Then open http://localhost:8787/

Forwarding keeps authentication at the SSH layer, so the web server does not need to be exposed publicly.

rdst web works fine inside a container if you bind to 0.0.0.0 and map the port. Keep the container on a private network.

docker run --rm -it \
    -p 127.0.0.1:8787:8787 \
    -e ANTHROPIC_API_KEY \
    -e PROD_ORDERS_PASSWORD \
    -v $HOME/.rdst:/root/.rdst \
    rdst:latest web --host 0.0.0.0 --port 8787

For a persistent install on a dedicated diagnostic host, run rdst web as a systemd service. Put a reverse proxy (nginx, Caddy) in front if you need TLS or auth.

# /etc/systemd/system/rdst-web.service
[Unit]
Description=RDST web server
After=network.target

[Service]
User=rdst
Environment=ANTHROPIC_API_KEY=...
Environment=PROD_ORDERS_PASSWORD=...
ExecStart=/usr/local/bin/rdst web --host 127.0.0.1 --port 8787
Restart=on-failure

[Install]
WantedBy=multi-user.target

Flags reference

FlagPurpose
-p, --port <N>Port to listen on (default 8787)
--host <ip>Host to bind to (default 127.0.0.1)

See also

  • Claude Code integration — MCP-based CLI-style access instead of a browser
  • Data Agents — scoped, guarded HTTP API for external consumers (different from rdst web, which exposes the full RDST surface)