URLs, slugs and reserved names

Where a published dashboard lives, what a slug and a handle may be, how renames redirect, and which names are already taken.

The canonical URL

A dashboard lives on a subdomain, not on a path:

https://<your-handle>.dashies.xyz/<slug>
https://<workspace-slug>.dashies.xyz/<slug>

Every success message the server emits uses that form, and it is the form to share. A dashboard published with several files serves the rest beneath it:

https://<your-handle>.dashies.xyz/<slug>/<filename>

The old apex path form still works and redirects. A request to https://dashies.xyz/<handle>/<slug> 301s to the subdomain, preserving the filename and the query string. That redirect fires without any lookup, so it is byte-identical for a dashboard that is public, private or absent: it reveals nothing you did not already type.

What you pass, and what is added for you

You pass <slug>/<filename>. The handle is added server-side from your authorization; never include it. A bare <slug> means <slug>/index.html.

Rule	Value
Slug characters	`^[a-z0-9-]+$`
Slug length	64 characters
Filename characters	`^[a-z0-9._-]+$`
Path shape	exactly one or two segments

The full refusal texts are in Shared rules.

A spec's optional slug field is stricter than the path rule: it must match ^[a-z0-9](?:[a-z0-9-]{0,62}[a-z0-9])?$, so it cannot start or end with a hyphen. It must also equal the publish path's slug; renaming is update_dashboard's job, not the spec's.

Uniqueness

Slugs are unique per account, and per workspace. Two people may each own a dashboard called sales; so may two workspaces. What cannot repeat is one slug twice inside one account or one workspace.

Aliases share that namespace. A rename leaves the old slug behind as a permanent alias that 301s to the new canonical URL, and that alias occupies the name: you cannot rename a second dashboard onto a slug an earlier rename left behind.

Your handle and every workspace slug are labels under dashies.xyz, and they are registered in one shared unique namespace. A handle can therefore never equal a workspace slug, and the collision is refused atomically when the second one is created rather than discovered later at a URL.

Your handle is generated at sign-up from your email. It is capped so the final label fits a 63-octet DNS label, and where the derived name would collide with a reserved label or an existing one, a suffix is added.

Reserved subdomain labels

Sixteen labels can never be a handle or a workspace slug. They belong to infrastructure or to conventional service names, and a request reaching one is refused before any dashboard lookup.

mcp   sso    www     api     app   assets  auth   admin
static cdn   status  docs    mail  ns1     ns2    data

mcp is the publish server, sso the SAML service, docs this site, and data the cross-origin query engine host. The rest are held so they cannot be taken.

Reserved first path segments

Five words are routes of the Dashies web app itself. On a subdomain those routes would shadow a dashboard of the same name, so they are also refused as a personal dashboard slug:

pricing   auth   app   assets   api

auth, app, assets and api are in both lists. pricing is the only one of the five that is not also a reserved subdomain label, so it is refused as a slug while remaining available as a workspace slug or a handle. The two lists are not near-identical in the other direction: twelve of the sixteen subdomain labels do not appear here at all.

One legacy publish path does not enforce this

Publishing a spec is refused on both scopes: the guard runs after the scope is resolved, and the refusal names the workspace URL when that is where you were publishing. Renaming onto one of these is refused too. Since the spec is the supported authoring path, that is what you will hit.

The gap is the legacy body publish into a workspace, which carries no such guard. There, a workspace dashboard slugged pricing publishes cleanly and its URL then redirects to the apex pricing page rather than serving the dashboard, because those routes are apex-only and a subdomain sends them there. Avoid all five in a workspace as well; on that one path nothing stops you.

privacy and terms are apex-only pages and are deliberately not reserved, so https://<your-handle>.dashies.xyz/privacy resolves as a dashboard slug like any other.

Visibility

Visibility	Who can open the URL
`public`	Anyone with the link. No sign-in.
`private`	You. A signed-out request is sent to sign in.
Workspace `private`	Current members of that workspace.

A new personal dashboard defaults to public; a new workspace dashboard defaults to private, which is members-only. Visibility is not plan-gated in either direction, and there is no publish quota.

A dashboard a non-member cannot see returns the same 404 as one that does not exist. That is deliberate: a distinguishable "exists but is not yours" would make the URL an existence oracle.

Check it worked

Open the canonical URL in a private browser window. A public dashboard renders; a private one bounces you to sign in. If you renamed it, load the old URL too and confirm it lands on the new one.