Skip to content

Local Development

Tommi Grönlund edited this page Oct 27, 2026 · 4 revisions

Documentation for the image tag 1.0.0-rc1.1. See Versions for the documentation of a release.

Local Development

Run the whole stack from source on your own machine, with every service and a Redis container started for you by .NET Aspire. This is for trying Qertum out or developing against it. For anything that holds real certificates, use Single Container or Multi Container.

Prerequisites

Tool Version Why
.NET SDK 10.0 or newer Builds and runs everything
Aspire CLI 13.6 or newer, on your PATH The AppHost needs it: dotnet tool install --global aspire.cli --version 13.6.0
Docker running daemon The AppHost starts a Redis container

Check them:

dotnet --version
aspire --version
docker info > /dev/null && echo docker ok

Run the stack

From the root of the source tree:

dotnet run --project Qertum.AppHost/Qertum.AppHost.csproj

The Aspire dashboard opens and lists every service with its URL and health. Open the webfrontend link and follow the onboarding flow to create or import a root CA.

Development credentials are admin / password. The identity provider forces a password change before the account can do anything else.

Build and test

dotnet build Qertum.sln
dotnet test Qertum.sln

The integration tests (IT-*) boot the whole stack and fail without a running Docker daemon. A failure with Docker stopped is not a regression; start Docker and run again.

Use the command-line client

dotnet run --project Qertum.Cli/Qertum.Cli.csproj -- --help

qca auth login prints a code and a URL; approve in a browser and the token is cached locally. Then, for example:

qca requests create -n www.example.com -T WebServer -k ECDSA-P256
qca requests approve <id>
qca cert download-cert <id> -F pfx --pfx-password ...
qca doctor        # read-only health and configuration checks

Global options --api-url, --identity-url, --token and --output table|json can also be set with the environment variables QERTUM_API_URL, QERTUM_IDENTITY_URL and QERTUM_TOKEN.

Reset to a clean state

Runtime data (database, CA files, key ring, identity store) is written under the build output directories, so it persists between runs. To start again from onboarding:

scripts/reset-dev-environment.sh --dry-run   # show what would be deleted
scripts/reset-dev-environment.sh             # delete runtime data
scripts/reset-dev-environment.sh --deep      # also remove build output and the CLI session

Notes

  • Development mode exposes the OpenAPI/Scalar API reference and the health endpoints. Production containers do not.
  • The AppHost is for local runs only; it does not publish a deployment.

Clone this wiki locally