Basic Authentication

Bahriya can protect an HTTP container's ingress with HTTP Basic Authentication. Any request reaching the container must include a valid Authorization: Basic ... header — Bahriya rejects everything else with 401 Unauthorized.

This is useful for staging environments, internal tools, dashboards that don't have their own auth layer, and any deployment that needs a simple credential gate without the complexity of full SSO.

Basic Authentication is only available on HTTP containers. Worker containers don't accept inbound traffic and the setting has no effect on them.

Configuration

Click + Add credential to add a row. Each row has a username and a password. Use the trash icon to remove a row. The + Add credential button is disabled once you have ten credentials configured.

Username rules

Usernames must match the pattern ^[A-Za-z0-9._-]{1,64}$:

• Letters (a-z, A-Z), digits, and the characters ., _, -.
• 1 to 64 characters in length.
• Each username within a single container must be unique.

How passwords are stored

When you add or rotate a password, Bahriya encrypts the value before writing it to the database. The plaintext password is never stored. The deployment pipeline decrypts the value only at the moment it provisions your container, and only the Bahriya ingress holds the credential at runtime — your application never sees the password and neither does the rest of the platform.

Passwords are not retrievable

Once saved, you cannot read a password back. The console displays existing credentials as masked rows: the username is visible, but the password input shows only placeholder dots.

You can:

• Rotate a password by typing a new value in the password field for an existing row, then clicking Update.
• Delete a credential by clicking the trash icon next to it.
• Keep existing passwords unchanged by leaving their rows untouched — saving the form without typing in the password field preserves the stored value.

If a customer forgets their password, the only path is to set a new one and share it again. There is no recovery flow.

Worker containers

If you change a container from http to worker (or always create it as a worker), basic auth is automatically disabled and any saved credentials are cleared on the next save. Workers run without an ingress; basic auth would have no effect.

Combining with other security features

Basic auth runs at the Bahriya ingress, before the request reaches your container. You can combine it with:

• Rate limiting — applied to all requests, including ones that fail basic auth. Use this if you want to throttle brute-force attempts on the basic-auth credentials.
• IP allow list / deny list — evaluated before basic auth. A blocked IP never gets the chance to present credentials.

Changes take effect on the next deployment

Enabling basic auth, rotating a password, adding a new user, or removing a credential all trigger a new deployment of the container so the ingress picks up the updated configuration. Deployments are rolling and have no downtime.