Access control

Use it to protect a pre-launch deployment or to show it only to specific people. There are three modes.

runlot access set public      # Anyone can reach it (default)
runlot access set org         # Only members of this organization can reach it
runlot access set password    # Only people who know the shared password can reach it

runlot access            # Show the current setting
runlot access --json

Running these commands requires the admin role.

password mode

runlot access set password --password 'my-secret'

If you omit --password, the terminal prompts you for it. Visitors to a protected deployment see a password prompt before the app.

org mode

Members of the organization get in with their dashboard login. Anyone who is not a member of the organization receives a 403 response.

Reading access information in your worker

The access information verified at the front is passed to your worker as request headers.

You can read them with the helpers we provide.

import { identity, isSignedIn } from "@runlot/access";

const who = identity(request);
// { mode: "org", subject: "…", email: "[email protected]", orgRole: "admin" }

if (who.orgRole !== "admin") return new Response(null, { status: 403 });

Any Runlot-* header sent by a client is stripped at the front, and only verified values are added back. A client therefore cannot forge these values.

In a local environment that runs without the front, mode is public and every other value is null.

Bypassing from CI

Use this when automation needs to reach a protected deployment.

runlot access bypass --new

The secret is shown only once. There is no way to see it again afterwards.

curl -H "Runlot-Access-Bypass: <secret>" https://my-app.me.runlot.app/health

runlot access bypass --revoke

Unauthorized requests never start the project

Access is checked before the project starts. Even when an unauthorized request arrives, an automatically stopped project is not started, and that request is not counted toward usage.

Current limitations