rs2 / restspace

2.2 Running your first node (serverConfig.json)

A node is configured by a single serverConfig.json — operator-level settings: where to listen, how tenancy is resolved, where files and logs live. This is distinct from a tenant config (the next section); the server config is about the process, the tenant config about an application.

A minimal server config

{
  "listen": "127.0.0.1:3100",
  "tenancy": { "mode": "single", "tenant": "main" },
  "fileRoot": "./data",
  "dataRoot": "./data-store",
  "tenantsDir": "./tenants"
}
  • listen — the address and port to bind.
  • tenancy — single means every request belongs to one tenant (here main); multi resolves the tenant from the Host header (covered in Part 10).
  • fileRoot — the local directory the default file store writes under.
  • dataRoot — the separate local directory used by the default, durable data store. Keeping records out of fileRoot prevents a file mount from exposing data records or password hashes.
  • tenantsDir — where <tenant>.json configs are read from.

Relative paths are resolved from the directory containing serverConfig.json, not from whichever directory you launched the process in.

logging is optional; left out, the node writes per-tenant NDJSON to ./logs. Part 10 covers it.

Starting it

cargo run -p rs2-server -- serverConfig.json
# or, equivalently, during development:
rs2 dev serverConfig.json

The node binds the listener and is ready when the health endpoints answer:

curl.exe http://127.0.0.1:3100/healthz    # liveness
curl.exe http://127.0.0.1:3100/readyz     # readiness

/healthz and /readyz are tenant-independent — they report the node itself, not any one application. If /readyz answers, you're ready to add a tenant.

What you don't have yet

A bare node with no tenant config serves nothing useful — every real path lives behind a mount, and mounts are declared in the tenant config. So far you have a running process listening on a port. The next section gives it something to do.

Tip — keep it running. Leave the node running in one terminal and make requests from another. On a running server you'll later edit the tenant live through the services API (Part 10) rather than restarting.

← Previous: 2.1 Installing · Manual home · Next: 2.3 Writing a minimal tenant config →