The core example uses a new bootstrap administrator and email/password sign-in. It does not copy an organization's identity-provider registration, tenant IDs, passkey associations or credentials. Decide which released sign-in methods your installation should offer before rollout.
Align the URLs#
For the reference path layout:
api:
url: https://dicto.example.org/api
auth:
base_url: https://dicto.example.org/api/auth
trusted_origins:
- https://dicto.example.org
web_redirect_uris:
- https://dicto.example.org/management/auth.html
Merge these values into the complete server file, retaining its required settings. An origin is scheme/host/port, without a URL path. A callback is a complete allowed return URL. Add your actual browser-app callbacks separately; do not authorize a wildcard solely to work around an incorrect URL.
Bootstrap and SSO#
Supply a unique long-lived AUTH_SECRET and new bootstrap administrator values.
After first successful sign-in, disable seed.admin.enabled and recreate API/jobs.
The seeder skips existing users and is not an account recovery mechanism. Keep
auth secrets, any configured encryption keyring and database backups together
when migrating an existing installation; do not regenerate them as an upgrade.
For SSO, provision your own provider registration and configure the matching
auth.sso_providers entry from the schema/example. Register the
exact server callback required by the selected auth API version and provider ID.
The management return URL and identity-provider server callback are different
URLs. Verify the complete browser redirect chain rather than guessing a callback
from the app hostname. Passkeys/native associations need their own domain and
device verification and are outside the bootstrap example.
Browser runtime files must not contain server/provider credentials. Verify administration permissions with both authorized and non-administrator accounts. See management deployment for path-prefix checks.