Skip to main content

First run

After Core is installed and the containers are healthy, a short bootstrap sequence brings Premora into service. The whole flow is designed so a broken identity provider can never lock you out.

1. Create the first administrator​

First-run is token-gated. On first boot — while no admin exists — the box generates a one-time setup token and writes it where only someone with host access can read it: the platform logs and secrets/setup-token in the install directory. This stops a publicly reachable deployment from being claimed by whoever loads the page first.

Open the web client; on a fresh deployment it shows Create your admin account. Read the token off the box:

cat secrets/setup-token
# or
docker compose logs omnibus | grep "SETUP TOKEN"

Enter an email + password and paste the token to create a DB-backed local administrator. This account exists before any SSO and is permanent break-glass access — keep its credentials in your secret store. The token is consumed once the admin exists.

:::tip Why local-first Premora mirrors the model enterprise admins already expect from self-managed GitLab/Bitbucket/Jira: a local admin exists before SSO, so a misconfigured or unreachable IdP can’t lock everyone out. The license is not used here — it gates distribution, not first-run; the setup token (read off the box) is what proves you operate the deployment. :::

:::note SSO-only deployments If you run single sign-on without a standing local admin, pre-seed your identity provider at install (via the environment) and let the first member of your designated admin group sign in — no setup token, no local password. The setup token guards only the local-admin path. See step 2. :::

2. Configure SSO (once)​

Sign in as the local admin and open Admin → Authentication. Configure one of:

  • OIDC / Microsoft Entra
  • SAML 2.0 (Premora acts as the SP)
  • LDAP / Active Directory bind

Map IdP groups → Premora scopes, and designate the group whose members receive admin access. Configuration is applied without a restart, and secrets are write-only (never returned on read). See Identity & SSO for the full reference.

3. Connect your first source​

Open the Sources area and add a connector — for example Confluence, Jira, or a Git repository. Each connector authenticates with its source system and projects that system’s permissions into Premora. See Configuring a connector.

4. Run the first sync​

Trigger the initial sync. Premora ingests the source, captures entitlement snapshots, and materializes content into the wiki. You can watch sync progress in the source tree as it populates.

5. Search and verify​

Once the first sync completes, run a search. Confirm that:

  • results are returned with citations and source lineage, and
  • a user only sees content they are entitled to in the source system.

Next steps​