Public workspaces

By default a workspace is private: only its members can see anything in it. A workspace owner can instead make it public, which lets anyone on the internet read it without signing in.

This is useful for publishing results — a paper’s training curves, a public benchmark, an open-source project’s runs — where you want people to explore the data rather than look at screenshots of it.

What “public” exposes

Making a workspace public grants anonymous, signed-out read access to everything in it:

• every project in the workspace
• every run, including its config, attributes, and tags
• every metric, series, and chart
• every RL environment and its data

This exposes every member’s data, not just yours

A workspace is shared, so publishing it publishes everyone’s runs in it — including colleagues who may not expect that. Run configs and attributes frequently carry things you didn’t mean to publish: internal dataset paths, model names, hostnames, experiment notes. Review what’s in the workspace before flipping the switch, or move the runs you want to publish into a workspace of their own.

Public access is read-only. Anonymous visitors cannot create, edit, archive, or delete anything, and they can’t see workspace members, invitations, or API keys — those stay members-only regardless of visibility.

Make a workspace public

Only workspace owners can change visibility.

1. Open the workspace Settings.
2. Go to the Danger zone section.
3. Turn on the Public workspace switch.
4. Read the confirmation dialog and choose Make public.

Make a workspace private again

Turn the Public workspace switch off and confirm with Make private. The workspace stops being readable by the public immediately, and only members can access it again.

Links stay the same

Visibility doesn’t change any URLs. A link you shared while the workspace was public keeps working for signed-out visitors only as long as it stays public — after you make it private, the same link prompts them to sign in.

Sharing a public workspace

Once a workspace is public, the ordinary portal URLs work for anyone — no separate “publish” step and no special share link. Because the portal encodes your view in the URL, you can send someone a link to a specific comparison, filter, or selected metrics and they’ll land on exactly that view. See Sharing & bookmarking.

Signed-out visitors see the workspace in read-only form with a Sign in button in the header.

Reading a public workspace from the SDK

Public workspaces are readable through the query SDK without an API key, which makes them convenient for reproducible notebooks and examples:

from metrana.query import QueryClient

client = QueryClient(
    workspace_name="some-public-workspace",
    project_name="some-project",
)
runs = client.fetch_runs()

fetch_runs needs a project, so give the client a default project_name (or pass project_name= per call); without either it raises ConfigError.

See Query configuration for details.

Private and nonexistent look identical

When a workspace isn’t publicly readable, the API answers the same way whether it’s private or simply doesn’t exist. This is deliberate — it stops outsiders from confirming that a given private workspace exists by probing names.