Skip to main content

Documentation Index

Fetch the complete documentation index at: https://paper.brimble.io/llms.txt

Use this file to discover all available pages before exploring further.

Brimble can put a single shared password in front of a project. Visitors see a password prompt before any request reaches your service. Useful for staging deployments, internal tools, and anything that shouldn’t be publicly readable. The password check happens at the edge, no requests reach your container without it.

​
How it works

  • One password per project. No username. Anyone with the password can access the site. It’s a single shared secret with no audit trail, so don’t use it as the only access control for sensitive data.
  • Form-based login. A visitor without a session sees a Brimble-rendered password page. They enter the password, submit, and are redirected back to the URL they came from.
  • Session cookie. On a successful login, the proxy sets an httpOnly session cookie (x-brimble-session). Subsequent requests carry the cookie and pass through without re-prompting until the cookie expires.
  • Per-hostname. Cookies are scoped to the hostname. Authenticating on staging.example.com doesn’t grant access to app.example.com. Each protected hostname has its own session.

​
What visitors see

A request to a password-protected project returns a Brimble password page with a single password field. The visitor enters the password and submits. On success they’re redirected to the URL they were trying to reach. On failure the page reloads with an “Invalid credentials” message. The cookie is httpOnly, JavaScript can’t read it, so the password page is the only way to obtain a session.
Brimble password page with the project hostname, a single password input, and a submit button

​
When it applies

Password protection covers every request to the project, top-level URL, asset paths, API endpoints, WebSocket upgrades. There’s no per-path bypass. If you need a public health check on an otherwise-protected project, run an unprotected sibling project at a different hostname for the public endpoint, or implement app-level auth instead.

​
Checking the current state

In the dashboard, open the project. The overview shows Site password enabled: Yes or Site password enabled: No. This is read-only on the overview page, it surfaces the current state but doesn’t toggle it.

​
Enabling, changing, or disabling

Toggle and rotate password protection from the project’s Configuration tab. To enable or change the password:
  1. Open the project.
  2. Go to Settings → Configuration.
  3. Find Password protection and click to open the modal.
  4. Type a password (minimum 6 characters), or click the refresh icon to generate a strong one. Click the eye icon to reveal what you’ve entered.
  5. Click Enable. The change takes effect immediately, no redeploy needed.
To disable:
  1. Open the same modal from Settings → Configuration.
  2. Click Disable and confirm. Visitors stop being prompted on the next request.
Password protection modal showing the visitor password input with show and reroll affordances, plus enable and cancel buttons
Changing the password invalidates every existing visitor session. Anyone who was previously logged in re-prompts on their next request.

​
Troubleshooting

Form keeps rejecting the password. The password is case-sensitive and has no leading/trailing whitespace. Confirm exactly what was set with whoever configured it. Logged in once, but every page reload re-prompts. Your browser is dropping cookies. Check it accepts cookies from the project hostname, privacy modes and third-party-cookie blocks usually still allow first-party cookies, but extensions can interfere. Authenticated for staging.example.com, but app.example.com re-prompts. Cookies are per-hostname. Each hostname has its own session. curl -u user:pass returns the password page. That’s expected, Brimble doesn’t read Basic Auth headers. The browser’s password page is the only login surface.

​
Next steps

Last modified on May 10, 2026