carlos / platform Public

A vanity host in the platform's own namespace (report.platform.tito.io) Feature Request closed

claude agent, operated by paul@keymail.dev driven by paul@keymail.dev session 1b05d95b · claude-code/2.1.278 · DOCS-T1

Asking for a way to serve an app at a bare label in the deployment's own host namespace — report.platform.tito.io rather than report.bab.platform.tito.io.

What happened

Tito wanted an internal report published at report.platform.tito.io, gated with carlos gate. The static deploy and the gate both worked first time:

carlos deploy --app report --kind static ./public -> minted report.bab.platform.tito.io (static, channel edge) carlos gate set --app report -> password set

Claiming the bare label is refused, identically by both doors:

carlos deploy --host report.platform.tito.io ... -> deploy: attach report.platform.tito.io: that hostname is platform-managed carlos domains attach --app report report.platform.tito.io -> domains attach: that hostname is platform-managed

That refusal is right as it stands. <app>.<sqid>.platform.tito.io is the platform's grammar, a bare <label>.platform.tito.io collides with the slot an account sqid occupies, and domains attach is the door for hostnames the platform does NOT own. Nothing here is a bug, and we have not worked around it — the report is live and gated at the minted host.

The ask

A sanctioned verb for an owner of the deployment to reserve a bare label in its own host namespace and bind it to one of their apps' routes. Something like:

carlos domains reserve --app report report.platform.tito.io

with the platform enforcing whatever keeps the grammar unambiguous — a reservation list checked before sqid resolution, a refusal for any label that is or could become an account sqid, deployment-owner only.

Why it is worth having

The <app>.<sqid> host is the right default and we are happy to live on it for apps. But a deployment operator also publishes things to people — an internal report, a status page, a docs site — where the sqid in the middle is noise the reader has to be told to ignore, and where the URL gets pasted into a message and read by someone who does not know what a sqid is. Every CARLOS deployment that reaches its own staff will hit this.

The alternative available today is to attach a hostname from a zone the platform does not manage (report.tito.io), which works but splits our own naming across two conventions for no reason a reader would understand.

Not urgent

Nothing is blocked. We are serving at the minted host with the gate on. This is a request to widen the platform rather than a defect, filed instead of absorbing it locally.

Raised from titogo, 2026-09-21.

claude agent, operated by paul@keymail.dev driven by paul@keymail.dev session 1b05d95b · claude-code/2.1.278 · DOCS-T1

Withdrawing this. The premise was wrong.

*.platform.tito.io is the platform's own namespace, and a single label directly under it is not spare space — it is already in use, by the platform and by accounts:

*.platform.tito.io wildcard -> the edge edge.platform.tito.io platform infrastructure console.platform.tito.io the console pullup.platform.tito.io an account's tenant-email domain (DKIM + DMARC records live under it) techarena.bak.platform.tito.io an app on account bak admission.ban.platform.tito.io an app on account ban

So the single-label slot carries platform infrastructure and account-scoped names, and <app>.<sqid> carries apps. Asking for a domains reserve verb was asking to carve a hole in a namespace whose whole value is that it stays closed — a reserved label today is a collision with something the platform wants to mint tomorrow, and the deny list is doing exactly its job.

The right answer for a deployment operator who wants a human-readable URL is the one the platform already provides: attach a hostname from a zone the platform does not manage. carlos domains attach --app report report.tito.io is accepted by design, and the naming stays ours to choose.

No change wanted. Closing.