Running a shared server

noodlelab serve on your own machine needs no setup: no logins, one local user. This page is for a server other people use.

Which pages may use the server

A browser lets any website send requests to a server on your machine, so the server checks where they come from:

• Without logins (the default on your own machine), it answers only to this machine’s names: localhost, a loopback address and the --host it was started with. With --host 0.0.0.0 --auth none it also answers to IP addresses, so reach it from other machines as http://192.168.1.5:8000, not by a host name. This stops DNS rebinding, where another site points its own name at your machine.

• Pages from other websites cannot open the editor’s WebSocket or save, run, upload or delete anything: those requests must come from the editor’s own page. On a shared server, the page’s host name must be the one the request was sent to (Host, or X-Forwarded-Host from a reverse proxy that rewrites Host).

Programs (the CLI, the MCP server, scripts) send no Origin header and are not affected.

Roles and guest links

On a shared server (--auth users), each person has one role in each workspace. A workspace is a project, and its managers are the project managers.

Role	Can
Viewer	Open graphs, browse files, and look at runs and reports.
Runner	Everything a viewer can, plus run graphs and export them to Python.
Editor	Everything a runner can, plus change and save graphs, upload files and copy examples.
Manager	Everything an editor can, plus add members, set roles, create guest links, and finalise or delete anyone’s runs.

Where roles are set:

• Admins are managers of every workspace. They set members and roles under Admin → Workspaces → Share….

• Managers do the same from the editor, with Members… in the top bar.

• Everyone else signed in gets a workspace’s default role. It can be no access, which means the workspace is for members only.

• A user who adds their own folder, when allow user workspaces is on, becomes its manager, and nobody else can open it until they share it. The folder may not contain or lie inside another workspace, the server’s home or its scratch, checkpoint and mount folders.

A guest link gives someone without an account view-only or view-and-run access to one workspace. It lasts until it expires (at most 30 days by default) or is revoked. Only a hash of its token is stored, so the link is shown once, when it is made. Guest links can be turned off in Admin → Settings.

The server enforces all of these rules. In the editor, viewers and runners get a read-only canvas marked View only or Run only.

Files stay inside the workspace. On a shared server, graphs, previews and the file browser reach only the workspace’s own folder and the mounts an admin configured, for admins too. Absolute paths (/data/run1.csv), ~ and paths that leave the workspace (../other-project) are refused, so one workspace cannot read another’s files or the server’s config.json. To share a folder on the server, add it as a mount (see Remote storage). Servers upgraded from earlier versions: graphs that used absolute paths such as /data/... need them changed to a mount (data://...).

Remote storage

Admins can mount S3, Google Cloud Storage, Azure, SFTP or a network share under a short name that graphs use in file paths (lab-s3://2026/run1.csv), for every workspace or only some. Remote storage explains how. A folder on the server itself is a mount too, with the URL local:///data/shared: on a shared server this is the only way to reach files outside a workspace.

Slurm clusters

A shared server can send runs to a Slurm cluster as batch jobs. Turn it on under Admin → Cluster: set the partition, account, time limit and resources, add setup lines such as module load, and press Test connection. People who may run graphs then get a Run on menu next to Run, with the choices On the server and On the cluster.

A cluster run looks the same in the editor: progress, previews and reports show up as usual, with the job state (Slurm job 1234 · pending) until it starts, and Stop cancels the job.

It needs:

• the workspaces on a file system shared with the compute nodes;

• noodlelab installed where the jobs run;

• a server that can run sbatch, directly or through ssh.

docs/slurm.md explains the setup and what a job looks like.

Docker

docker build -t noodlelab .
docker run -d -p 8000:8000 -v noodlelab-data:/data \
  -e NOODLELAB_ADMIN_TOKEN='<token>' noodlelab

Or run make docker-up (docker compose up -d --build, with the version taken from the git tag) with NOODLELAB_ADMIN_TOKEN set in .env; plain docker compose builds report version 0.0.0. The compose file also installs Claude Code for the Agent panel. For a public demo, set NOODLELAB_DEMO=1, which gives you guests only, one run at a time and a 25 MB file limit. render.yaml deploys it on Render’s free plan.

The Agent panel on a shared server

The Agent panel runs Claude Code or Codex CLI as the server’s user, so it is offered to admins only when logins are on, never on a demo server (NOODLELAB_DEMO=1), and only while Admin → Settings → agent terminal is on. Each agent session gets an API token of its own, revoked when the session ends.