Skip to main content

First run

After Core is installed and the pods 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. Bootstrap the local admin​

First-run bootstrap creates a DB-backed local administrator that exists before any SSO is configured. This account is permanent break-glass access — keep its credentials in your secret store. It is the account you use to perform the rest of this setup.

:::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. :::

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​