Web console

An optional, alpha web console for debugging your self-hosted io.sign deployment

🚧

Alpha, optional deployment

The 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:

PathUpstream variableNotes
/v2API_UPSTREAMRequired
/identityIDENTITY_UPSTREAMFalls back to API_UPSTREAM if unset
/v1/webhooksWEBHOOKS_UPSTREAMRequired

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:

ProviderauthModeWhat the console sends
dev-headersnonex-user-id / x-organisation-id (local development only)
basicbasicAuthorization: Basic ...
bearerbearerAuthorization: Bearer <JWT>
clerkclerkAuthorization: Bearer <Clerk session token>
gatewaygatewayNothing. 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 the none auth mode beyond localhost

The dev-headers provider (authMode: none) trusts caller-controlled x-user-id and x-organisation-id headers, so any reachable deployment running the API with JWT_ENABLED=false would 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.


Did this page help you?