AiHummer
English
Log in
v1.0.x
{ }Swagger

First Login

v1.0.x · updated 2026-07-07

The very first time AiHummer starts against an empty database, it bootstraps a single admin account and writes the initial password to ~/.aihummer/etc/initial-admin-password.txt (mode 0600). You use it to sign in once, then change it immediately. This page walks through that first login and how to harden it for production.

Find the initial password

The password is not printed to the log. On an empty database the gateway writes the generated admin password to a file inside the install root at startup — read it:

cat ~/.aihummer/etc/initial-admin-password.txt

The service journal only shows the banner INITIAL ADMIN CREATED — sign in at /admin/ and change the password with the path to the file (password_file=…), not the password itself. The password is logged only as a fallback if the file could not be written.

[!WARNING] Treat the password file as a secret: it exists only for the first login. Once you have signed in and changed the password, delete the file:

rm ~/.aihummer/etc/initial-admin-password.txt

Log in as admin

Open the admin Web UI and sign in with admin and the password from the file:

http://localhost:8781/

The admin Web UI is a separate, private listener (default :8781, AIHUMMER_WEBUI_ADDR), served at the root path / and ideally bound to an internal-only interface. It is not on the public gateway port: :8780 carries the API, pairing, WS/SSE and inbound traffic, and never serves the admin UI (it returns 404 for /admin and /v1/admin). The gateway owns external routing through its own built-in edge-router — there is no external nginx you have to configure.

Change the password immediately

Change the bootstrap password right after your first sign-in, from the admin UI, then delete the initial-admin-password.txt file. You can also reset the password from the bundled CLI:

aihummer set-password
# or
aihummer admin-password

set-password needs AIHUMMER_DATABASE_URL — run it as the user the install was performed for, or with the environment from ~/.aihummer/etc/gateway.env.

[!DANGER] Do not leave the bootstrap password in place, and do not leave the password file sitting on a production host. The bootstrap admin account is a full administrator — anyone who reads that file and reaches /admin/ has complete control.

Find your way around

A few landmarks in the admin UI after signing in:

  • Navigation — sections open at hash addresses (/#channels, /#settings…), so any page can be opened by direct link and revisited with the Back button.
  • Dark and light theme — the sun/moon toggle in the header; the choice is remembered in the browser.
  • Brand and mascot — the “Ai” letters in the logo carry the brand accent, and empty states, the setup wizard and the login screen feature the mascot — a fennec fox named Ham.
  • The “Account” page — change your own password, sign out and set up two-factor authentication: a TOTP app, passkeys (WebAuthn) and recovery codes.

Secure the admin surface

By itself, the /admin/* surface trusts development headers when no enterprise auth issuer is configured — which is fine on a laptop but unsafe on an exposed host. For any production deployment, protect /admin/* with an auth issuer and do not expose it without one.

[!IMPORTANT] Set AIHUMMER_OIDC_ISSUER (or configure LDAP/SAML) before exposing the admin UI. Without it, admin endpoints trust dev headers and must never be reachable from an untrusted network.

Enable enterprise SSO (production)

For production, move authentication onto your identity provider. AiHummer supports enterprise SSO so the bootstrap local account becomes a break-glass fallback rather than the daily path:

  • OIDC — protects /v1/admin/* (deny-by-default).
  • SAML — federation via /saml/metadata, /saml/acs, /saml/login.
  • LDAP / Active Directory — directory-backed login.
  • SCIM — automated user provisioning at /scim/v2/Users.

Once SSO is in place, scope down or retire day-to-day use of the local admin account and rely on your IdP’s groups and roles.

Where to next