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.
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:
- Open the project.
- Go to Settings → Configuration.
- Find Password protection and click to open the modal.
- 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.
- Click Enable. The change takes effect immediately, no redeploy needed.
To disable:
- Open the same modal from Settings → Configuration.
- Click Disable and confirm. Visitors stop being prompted on the next request.
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
