Deploy URL

Once a deploy completes, the project gets its default address.

my-app.me.runlot.app

The form is <project>.<organization>.runlot.app.

The older -- address is gone

Addresses used to join the project and the organization into a single label, as in my-app--me.runlot.app. That form is no longer registered. A deploy registers only the two-label name, and projects deployed before the change were moved over. If you shared the older address somewhere, update it — it no longer resolves.

Why the labels can be split

A wildcard certificate covers a single subdomain label, so one *.runlot.app certificate could not cover an address with two labels. runlot now issues a wildcard certificate per organization, *.<organization>.runlot.app, over ACME DNS-01 — Google Trust Services is the primary CA, with Let's Encrypt as the fallback. That is what lets the project and the organization each have their own label.

Naming rules

Organization slugs and project names must follow these rules.

• ^[a-z0-9](-?[a-z0-9])*$
• 30 characters maximum (derived from the 63-character DNS label limit)
• A name may not contain two hyphens (--)

The -- rule stays even though the default address no longer uses --. The direct PostgreSQL address still joins the two names with -- (my-app--me.wire.runlot.app), and without the rule project c in organization a--b and project b--c in organization a would share that address.

Renaming a project moves this address

An admin can rename a project, on the project's Settings tab or with runlot project rename <current> <new>. The default address moves with the name, and the certificate does not have to be reissued — it is the organization wildcard, which already covers every project label underneath it.

The old address stops answering right away, and there is no alias. Keeping both alive would mean two addresses for one project and no way to say which is the real one, so update these yourself:

• the name in runlot.json
• any git remotes (runlot repo list prints the new addresses)
• any PostgreSQL connection strings you saved (runlot pg connect)

Nothing stored moves. Your database, files in env.storage, backup generations, secrets, and the contents of your repositories are all tracked by the project's id, not its name, so a rename does not copy or rebuild any of it. Custom domains stay attached.

One thing does not follow the name: an email address you already enabled keeps the old one. It is fixed when you turn email on, because mail is already being sent to it from outside. To move it, turn email off and on again — and be aware that mail to the old address stops at that point.

The organization slug is different: it cannot be changed. It is the label the wildcard certificate itself is issued for, so moving it would mean reissuing that certificate and keeping the old name resolving in the meantime.

TLS

The TLS certificate for this address is managed automatically at the front. There is nothing to configure, and http:// requests are redirected to https://.

To connect a domain you own, see Custom domains.

Headers the worker receives

The front adds the current placement details to the request headers. These headers are useful when diagnosing a problem.

request.headers.get("Runlot-Project-Id");
request.headers.get("Runlot-Epoch");
request.headers.get("Runlot-Node");
request.headers.get("Runlot-Slot");

Any runlot-* headers sent by the client are stripped at the front and re-added with trusted values. A client therefore cannot forge these header values.