Configure and Run

Configure the Server

CORS allowed origins:

make run (and .\build.ps1 run on Windows) automatically configures the Gate and Console development origins (https://localhost:5190 and https://localhost:5191) on startup, so no manual CORS setup is required for the standard flow.

tip

To allow additional origins, add them to backend/cmd/server/config/resources/server_configs/cors.yaml or set them at runtime with PUT /server-config/cors.

Configure the Gate client:

Open backend/cmd/server/deployment.yaml and make the following change:

gate_client:
  port: 5190

tip

This configuration points the backend server to the local ThunderID Gate application for authentication.

Run the Server

All-in-one (Backend + Frontend together)

Start the ThunderID server and apps in development mode.

Linux/macOS

make run

Windows

.\build.ps1 run

note

This command will automatically set up your complete development environment:

What happens:

• Installs frontend dependencies and builds packages
• Starts the frontend development servers
• Generates local development key material if missing: TLS, JWT signing, and encryption keys (release builds never bake key material; each deployment generates its own at setup)
• Initializes SQLite databases
• Starts the backend server
• Runs the bootstrap script which creates:
  • The Console application with the correct redirect URIs
  • The default admin user (credentials default to admin / admin; configurable via ADMIN_USERNAME / ADMIN_PASSWORD environment variables)

Services that start:

• Backend server: https://localhost:8090
• ThunderID Gate (Login/Register): https://localhost:5190/gate
• ThunderID Console (Admin Console): https://localhost:5191/console

Separate terminals (for debugging independently)

Use this approach when you need to debug the backend and frontend independently.

Terminal 1 - Backend:

Linux/macOS

make run_backend

Windows

.\build.ps1 run_backend

Terminal 2 - Frontend:

Linux/macOS

make run_frontend

Windows

.\build.ps1 run_frontend

Terminal 3 - Seed the initial data (one-time only):

The bootstrap subcommand never invents an admin password on its own. Pass one explicitly with --admin-password (or ADMIN_PASSWORD).

Linux/macOS

PUBLIC_URL="https://localhost:8090" \
go run -C backend/cmd/server . bootstrap \
--admin-password "admin" \
--console-redirect-uris "https://localhost:5191/console"

Windows

$env:PUBLIC_URL = "https://localhost:8090"
go run -C backend/cmd/server . bootstrap `
--admin-password "admin" `
--console-redirect-uris "https://localhost:5191/console"

This runs the in-process bootstrap subcommand, which creates the default resources (including the Console application and the default admin user, credentials default to admin / admin) directly through the service layer. No temporary server or security bypass is involved. You only need to do this once: the data persists in the SQLite databases, and the subcommand is idempotent if re-run.

warning

Don't use ./setup.sh here. That script is designed for the packaged distribution zip and expects a compiled ./thunderid binary at the project root. From source code, run the bootstrap subcommand as shown above, or use make run (Option A) which handles everything for you.