Web console
An optional, alpha web console for debugging your self-hosted io.sign deployment
Alpha, optional deploymentThe web console is an alpha component and an optional part of a self-hosted io.sign deployment, intended for debugging only. Do not rely on it in production. Manage signing policies and signers through the Dashboard and the API instead.
The web console (apps/frontend) is a static single-page app served by nginx, shipped as its own image separate from the io.sign API. It is optional: run it only if you want a browser-based view over a self-hosted backend. For the backend it connects to, see Configuring io.sign. Pull it from the public registry, the same as the API and migrations images.
The console must be served same-origin with the API, because the API has no CORS support. The nginx image proxies the API paths for you:
| Path | Upstream variable | Notes |
|---|---|---|
/v2 | API_UPSTREAM | Required |
/identity | IDENTITY_UPSTREAM | Falls back to API_UPSTREAM if unset |
/v1/webhooks | WEBHOOKS_UPSTREAM | Required |
The container runs as a non-root user and listens on port 8080, not 80. Publish it to any host port you like.
docker run -d --name io-sign-frontend -p 8080:8080 \
-e API_UPSTREAM=http://<your-api-host>:3000 \
-e WEBHOOKS_UPSTREAM=http://<your-webhooks-host>:3010 \
<registry>/<frontend-image>:<tag>The console picks its authentication provider from a runtime config.json (or the matching environment variables), so you can point it at your identity provider without rebuilding the image:
| Provider | authMode | What the console sends |
|---|---|---|
dev-headers | none | x-user-id / x-organisation-id (local development only) |
basic | basic | Authorization: Basic ... |
bearer | bearer | Authorization: Bearer <JWT> |
clerk | clerk | Authorization: Bearer <Clerk session token> |
gateway | gateway | Nothing. A fronting proxy injects the credential |
Pair the console with the backend by running it in bearer or clerk against a real identity provider, then adding that provider to JWT_PROVIDERS on the API. Use the gateway provider when a reverse proxy or sidecar injects the credential upstream (for example mTLS or a signed header): the console sends no auth headers and the gateway asserts the enforced identity to the API.
Never expose thenoneauth mode beyond localhostThe
dev-headersprovider (authMode: none) trusts caller-controlledx-user-idandx-organisation-idheaders, so any reachable deployment running the API withJWT_ENABLED=falsewould accept unauthenticated, tenant-selectable requests. A JWT-enabled API rejects those headers, so this pairing fails closed against production.
The configuration and deployment details on this page are drawn from the io-sign repository documentation. Content was rephrased for compliance with licensing restrictions.
Updated about 2 months ago