Customer-hosted sign-in and recovery
How people sign in to a customer-hosted console, how the first administrator is created and recovered, and what the Recursift-hosted service keeps instead.
How sign-in works
The installer sets the console to the customer deployment profile. In that profile people sign in with an email address and a password stored on your server. Hosted sign-in providers and email links are not registered, even if their keys are present, and no identity-provider or license request is made at startup or sign-in. Passwords are hashed with Argon2id using 64 MiB and three iterations. If you configure an email allowlist, it also applies to local sign-in.
Origins and the proxy
The console's public URL settings must be the same bare HTTPS origin, and the installer writes both from --origin. Additional internal origins must be listed exactly; the installer adds the console's loopback address for local checks. Wildcards are not accepted. A request whose Host is not one of these origins, or a browser change without the exact configured Origin, is refused with 403 Forbidden. Forwarded headers never add trust, so a proxy must preserve the public Host.
Create the first administrator
sudo bash deploy/customer/bootstrap-admin.sh --email owner@customer.exampleThe script loads the console's protected configuration and runs the bootstrap as the console's service account. It prints a one-time link. Open it and choose a password of 12 to 1,024 characters.
- The secret is 32 random bytes carried in the link fragment. The page removes it from the address bar and submits it in the request body.
- Only a SHA-256 hash of the secret is stored. It expires after 15 minutes and works once. Issuing a new link invalidates the previous one.
- Only one bootstrap can complete, even under concurrent attempts. Bootstrap refuses an existing identity it did not create.
- There is no default password and no web endpoint that issues setup links. Shell access to the server is the bootstrap and recovery authority, so protect it.
Do not capture the printed link, request bodies, browser history or session cookies in logs or support bundles.
What the first account can do
The first local account is an owner under the console's existing per-user model. There is no global administrator role and no access across owners. A local credential cannot reach another user's endpoints, resources or investigations.
Recover or disable an account
The console's local administration command has three operations: bootstrap, recover and disable, each taking --email. Recover needs an existing local credential. It issues the same single-use setup link, clears lockout, re-enables a disabled credential, and invalidates every earlier session once used. Disable invalidates outstanding links and sessions at the next server request.
Ten incorrect passwords lock a credential for 15 minutes. Error messages do not reveal whether the account exists, is disabled, or the password was wrong. Recovery does not bypass the email allowlist.
Identity audit
Bootstrap, recovery and disable are recorded in an append-only audit table in the same transaction as the change; if the audit write fails, the change is rolled back. Records hold the actor, action, user, origin and outcome, never a password, raw token or token hash. The database refuses to truncate that table.
Keep the sign-in secret stable
The console's sign-in secret is generated at install and backed up with the server. Changing it signs everyone out. Do not change it unless that is what you intend.
What the hosted service keeps
The Recursift-hosted console at recursift.app is unchanged by the customer profile. It keeps its hosted sign-in with OAuth and email links, and its email allowlist. Accounts do not move between the hosted service and a customer-hosted server, and switching a console's profile does not carry credentials across.