Setup and Data Seeding

ThunderID seeds its default resources through an in-process bootstrap subcommand. How you invoke it depends on whether you are developing from source, initializing a release artifact, or running a built distribution.

Command	Use case	Admin password
make run	Source development	Fixed dev default admin / admin (overridable)
./setup.sh / ./setup.ps1	Release / deployment initialization	Provided, otherwise auto-generated and printed
./start.sh --bootstrap-and-serve	Run a built distribution (local/dev)	Must be provided, otherwise startup fails

The admin password is never shipped by default

ThunderID is production-ready by default: the compiled product binary carries no built-in or fallback admin password. The bootstrap subcommand (the code that actually creates the admin user) only ever consumes a password that is explicitly supplied to it:

• The admin username defaults to admin.
• The admin password has no default and is never generated by the binary. It is resolved in order: --admin-password flag → ADMIN_PASSWORD environment variable. If neither is set, bootstrap fails with an error instead of creating an account with a predictable, publicly-known password.

Inventing a password when none is supplied is the responsibility of the setup tooling, not the product. Only ./setup.sh / ./setup.ps1 generate one, and only make run falls back to a fixed default (for local development). Every other path must be given a password or it refuses to start.

What gets seeded

All paths run the same in-process bootstrap subcommand, which creates the core resources through the service layer (no temporary server, no security bypass):

• Default Organization Unit
• Default User Type (Person) and Agent Type
• Admin user (see the credential rules above)
• System resource server with system resources, actions, and permissions
• Administrators group, Administrator role, and the role assignment
• Console application
• Default flows, themes, and translations

Development seeding (make run)

make run builds and runs ThunderID from source against local SQLite databases, seeding via go run … bootstrap before it starts the server. Because this path is source-only and never produces a shared or distributed artifact, build.sh supplies a fixed admin / admin default when ADMIN_USERNAME / ADMIN_PASSWORD aren't set.

This is the only path with a hardcoded password, and it exists purely for local development convenience. Override it at any time by exporting ADMIN_PASSWORD (and optionally ADMIN_USERNAME) before running.

Release initialization (./setup.sh / ./setup.ps1)

./setup.sh (and its Windows equivalent setup.ps1) is the designated entry point for initializing a release artifact or a deployment. It is the only place that will generate an admin password for you:

• If you supply a password (via the --admin-password flag, the ADMIN_PASSWORD environment variable, or the interactive prompt), it is used as-is.
• If you supply nothing, setup.sh generates a strong random password and prints it once in the completion summary. Capture it: it is stored only as a hash and cannot be recovered later.

Because there is no readable password to reuse, re-running setup with nothing supplied generates a new password and resets the admin account to it. To keep a stable password across runs, always supply ADMIN_PASSWORD.

Under the hood, setup.sh exports the resolved credentials and delegates to ./start.sh --bootstrap, which runs the compiled binary's in-process bootstrap one-shot (creating the resources above, then exiting) and starts the bundled consent server for the duration of the run. It reads the resource definitions from bootstrap/. After setup completes, use ./start.sh to serve.

Alongside seeding these resources, setup.sh (and setup.ps1) also generate this deployment's TLS, JWT signing, and AES encryption key material into config/certs when it is not already present, reusing any existing material on later runs. This key material is never shipped in the product, so each deployment gets its own; the server fails to start if it is missing.

Seed and serve in one step (./start.sh --bootstrap-and-serve)

./start.sh --bootstrap-and-serve is a local/dev convenience that seeds the default resources and then starts the long-running server in a single command. Unlike setup.sh, it never generates a password. You must provide one:

• Precedence is --admin-password flag → ADMIN_PASSWORD environment variable.
• If neither is provided, bootstrap fails and the server does not start.

Only the password is required. --admin-username is optional: it falls back to the ADMIN_USERNAME environment variable, then defaults to admin, so passing just --admin-password is enough.

The --admin-username / --admin-password flags are valid only with --bootstrap-and-serve; passing them with plain --bootstrap, or without any bootstrap mode, is an error.

./start.sh --bootstrap-and-serve --admin-username admin --admin-password admin

The bootstrap is idempotent (re-running is safe and does not create duplicates; existing resources are updated in place), and the server reuses the consent server it started.

note

./start.sh --bootstrap is the seed-only variant used internally by setup.sh; it takes credentials from the environment, not from flags. ./start.sh on its own only serves and performs no seeding.

In short

• make run: source development; defaults to admin / admin unless overridden via environment variables.
• ./setup.sh / ./setup.ps1: release/deployment initialization; provide a password, or one is generated and printed once.
• ./start.sh --bootstrap-and-serve: run a built distribution; you must provide a password (flag or environment variable) or startup fails.