rs2 / restspace

2.5 Health checks and the developer loop

This short section gathers the operational basics you'll lean on while developing: confirming the node is up, and the rs2 CLI verbs that make up the day-to-day loop.

Is the node up?

Two tenant-independent endpoints report the node itself:

curl.exe http://127.0.0.1:3100/healthz    # liveness — the process is running
curl.exe http://127.0.0.1:3100/readyz     # readiness — ready to serve

These never depend on a tenant, so they're what a load balancer or container orchestrator should probe. If /readyz answers, requests to your mounts will be routed.

The rs2 developer loop

The CLI is primarily for building and shipping services, with focused commands for login, file upload, mount edits, auth bootstrap, and instruction-plane mirroring. You still talk to the rest of a tenant over plain HTTP. The commands you'll meet most often are:

Command Does
rs2 new <name> [--js] Scaffold a custom-service project (Rust/Wasm by default, --js for a JavaScript bundle)
rs2 dev [serverConfig.json] Run a local node (same code as rs2-server)
rs2 test [projectDir] Validate a custom service's manifest and built component
rs2 deploy <file> --name <n> [--bundle] Upload a custom service to a running node's services API
rs2 login / rs2 send Save a login token; PUT one local file to a tenant path
rs2 service add / set-access Make a small ETag-safe mount/config change
rs2 auth init Bootstrap auth and the first operator on a fresh open node
rs2 pull / rs2 push Mirror and safely update the tenant's instruction plane
rs2 migrate <services.json> Convert a v1 Restspace config to an RS2 tenant config

For now, rs2 dev is the one to know: it starts a node exactly like rs2-server, so you can iterate without leaving the CLI. Appendix E is the complete command reference.

A typical inner loop

  1. Edit ./tenants/main.json (or PUT /services/raw on a running node).
  2. Reload (restart, or the live PUT).
  3. Make requests with curl/Invoke-RestMethod/fetch.
  4. Read X-Trace-Id on the response; if something failed, look up that trace in the logs (Part 10) or read the problem+json body.

That's the whole getting-started arc: install, run, configure a tenant, make requests. Part 3 steps back to explain the concepts those requests rely on — messages, mounts, the store pattern, and capabilities — so the rest of the manual's services make sense as instances of a few ideas rather than a pile of features.

← Previous: 2.4 Your first request · Manual home · Next: Part 3 — 3.1 Messages and bodies →