The Admin Console
Overview
The Admin Console (Node Admin) is the control plane for your UnoLock Federated Node. You use it to finish setup, unlock the node after a restart, issue Safe registration codes, sign the browser client, manage Administrator access keys, change deployment settings and check node health.
Node Admin is served at https://node.example.com/admin. It is packaged separately from the hosted Safe app, so it stays available while the node is locked and even when the Safe app's integrity check has deliberately failed closed. The node's PWA launch page and locked landing page also link to Node Admin.
Node administration and Safe access use separate credentials. The admin console shows aggregate node status, not Safe activity history or relationship graphs.
Open the admin console
- Open
https://node.example.com/adminin your browser, using your own permanent hostname. Use the hostname, not the server's IP address. - Choose how to sign in:
- New node: select Register the first administrator, then Register admin key, and enter the one-time setup code printed by the launcher. See First Setup.
- Existing node: choose Sign in with an admin key and use your registered admin passkey and PIN.
- If the node is locked after a restart, sign-in succeeds first and the node then asks for an explicit unlock. Choose Unlock Node. See Restarts and Unlocking.
After unlock, the console opens Home. It does not repeat first-time setup once the Deploy, Client and Health checks have passed.
Note
/admin/ redirects to /admin. The admin console does not register a service worker, and managed endpoints do not expose node administration.
Admin views
| View | What it is for |
|---|---|
| Home | Node and lock state, setup actions, and a link to open the hosted Safe client (Open UnoLock) |
| Setup | The required Deploy, Client and Health readiness checks |
| Safes | Create, review and disable Safe registration codes |
| Clients | Rebuild and sign the hosted browser client |
| Access | Register, test, review and disable Administrator access keys |
| Settings | Deployment settings that apply after a restart, and optional crypto transaction integrations |
| Diagnostics | Refresh detailed node health checks |
Secondary views load only when you open them. A routine admin sign-in does not fetch every settings and registration record.
Home
Home is the starting point for normal administration. It shows the node's current lock state and setup actions. Choose Open UnoLock to open the hosted Safe client at https://node.example.com/.
Setup
Setup contains only the required readiness checks. Complete them in order:
| Check | What it does |
|---|---|
| Deploy | Confirms the permanent HTTPS URL and WebAuthn domain. |
| Client | Builds and signs the hosted client manifest in the admin browser. Use the offered Sign Client or Rebuild And Sign Client action and keep the page open until it finishes. This can take several minutes. |
| Health | Checks storage, key protection, client assets, TLS posture and incomplete upload cleanup. Resolve any failed check before continuing. |
Creating a Safe registration code and adding a backup admin passkey are useful next steps, but they are not readiness checks and do not cause Setup to reopen.
Safes
Safes lists the node's Safe registration codes, including after you sign in again or restart the node.
- Open Safes and create a Safe registration code. For a single person, use a short-lived code that permits one use.
- Give the person the node's HTTPS URL and the code through an appropriate channel. See Creating Safes.
- Review codes regularly and disable any you no longer need.
How saved codes behave:
- Only an authorized administrator on an unlocked node can retrieve a saved code, through the encrypted admin channel.
- Active codes can be shared again as a code, link or QR image. Viewing, copying, saving or printing a code does not use it up or extend its expiry.
- Printed and saved invitations omit the remaining-use count. The live count is shown in the Safes table.
- Inactive codes stay visible for reference but cannot create a Safe.
- Older invitations that stored only a hash show Code unavailable for this older invitation. Their original code cannot be recovered.
- Signing out clears retrieved codes from the page's memory.
Warning
Treat an active registration code, and any exported link, image or printout of it, as a credential. Never reuse the Administrator setup code as a Safe registration code.
Clients
Clients prepares and signs the hosted web client that your node serves to browsers. Native apps are built, signed and hosted separately.
Client signing code
The Client signing code identifies the node's protected client-update signing key. It has six groups of four hexadecimal characters.
- Share it with your users through a trusted channel so they can compare it with the code shown when they add the server in the UnoLock app.
- Ordinary client updates do not change it. Replacing the signing key does.
- Record the code while you trust the node. A code read from a compromised server is not independent proof of its identity.
Rebuild status
Clients compares the active client in persistent node storage with the client bundled in the running node image, and reports one of three states:
| Status | Meaning |
|---|---|
| Rebuild not needed | The active client matches this node image. It still needs a valid signature. |
| Rebuild required | The image contains a newer or different client, or the active client predates build tracking. |
| Status unavailable | This installation has no packaged build identifier. |
When a rebuild is required, the node installs the image's client into persistent storage as one complete staged bundle and activates it atomically. Re-check this status after every node image upgrade. On a paired active node, the standby must acknowledge client activation before the job completes.
Access
Access manages Administrator access keys under Admin Access Keys. You can register a passkey on the current device or a separate hardware security key.
To set up a recovery key:
- Open Access and register a separate hardware security key.
- Give it a recognizable name.
- Verify it with a fresh sign-in.
- Restart the node and use that key for the first unlock before you treat it as a working recovery key.
- Store the security key and its PIN separately from your node backups.
The node prevents you from disabling the last active Administrator key that can unlock it. After adding or disabling a key, create a new backup and retire older backups that still contain a recovery record for a disabled key. See Backup and Recovery.
Settings
Settings holds deployment configuration. Changes are saved as pending configuration and applied on the next restart.
- Record the old and new values.
- Save the pending configuration.
- Restart the node in a maintenance window, then sign in and unlock.
- Repeat the Setup and Diagnostics checks.
Warning
Do not change the permanent URL or WebAuthn relying-party identity on a configured node. Your admin and Safe passkeys depend on it.
Attachment transfer storage limit
Attachment transfer storage limit (%) sets the node-wide temporary storage budget shared by message attachments and federation relays. The default is 20% of the total capacity of the filesystem that holds the archive root. Values from 0 to 100 are accepted. 0 disables new relay and message-attachment reservations. Committed Safe data is not limited by this budget. See Configuration for details.
Crypto transactions
Settings can enable optional client crypto transaction APIs and store Tatum testnet or mainnet API keys. Leave the integration disabled unless you have accepted the provider, billing, network and key custody consequences. Provider keys are Administrator secrets.
Diagnostics
Diagnostics shows detailed node health. Open it, refresh Node Health, and investigate every failed check.
Health checks cover network posture, runtime dependencies, key protection, TLS files, database availability, archive storage, hosted client assets and stale multipart cleanup. Diagnostics also reports host-security warnings, including swap and core dumps. See Host Security.
Health checks do not expose Safe IDs, archive IDs, Receive Addresses, onion routes, filenames or user activity.
Note
Diagnostics is a point-in-time view, not a monitoring system. Set up separate alerting on the host. See Host Security.
Cluster actions
On nodes paired in active/standby mode, the admin console also provides Verify Standby Recovery, Prepare Planned Switchover, Fail Over to Standby and Remove Unavailable Standby. See Active/Standby and Failover.
FAQs
Can I reach the admin console while the node is locked?
Yes. /admin opens while the node is locked, so you can sign in and choose Unlock Node. Safe APIs, archive transfers and federation services stay unavailable until the node is unlocked.
Does the Administrator see what is inside users' Safes?
No. Admin views expose aggregate status only. With trusted client software, administrative access alone does not expose Safe contents.
Is there a separate owner role?
No. There is one Administrator function. Internal recovery records may use the term owner, but it is not a separate public role.
Is there an API token for administration?
No. Privileged actions use /admin/start and /admin/api, the same encrypted callback pattern used for Safe APIs. There is no bearer-token administration API.
Why does Setup show Client and the menu show Clients?
Client is the Setup readiness check that signs the hosted browser app. Clients is the view where you rebuild, re-sign and check the client's status at any time.