Skip to content
Limen

Using the console

The web console is for looking around and for the occasional admin action. For daily work, see the CLI guide. Setting it up for your own deployment: the console runbook.

Open https://<your proxy>/console/ (locally https://localhost:3443/console/) and choose Continue with single sign-on. You sign in with the same identity provider as the CLI. What you see depends on your roles.

Page What you can do Who
Overview See your identity and roles, what you can reach (with a copy-paste limen ssh command), and recent sessions. Admins also get live counts: active sessions, users, locks, workers, policy version everyone
Resources Search and filter by kind and label (click a label chip to filter by it; the URL is shareable, e.g. ?kind=postgres&label=env=staging). Open a resource to see its labels and, for admins, its target, which roles grant access, which live workers can serve it (a red none means sessions will fail), and its sessions everyone sees their own; admins see all
Sessions Browse live and past sessions, filterable by user, resource, kind, people or bots, how they ended, and a UTC time range. Open one to replay the recording (SSH) or read its statements and commands (SQL, Redis, MongoDB, search, RabbitMQ, and Kafka sessions have no recording), or its Kubernetes API requests (one kubectl session per login and cluster) (the control plane verifies its hash first) and, as an admin, end it with a reason everyone sees their own; admins see all
Access Ask for access that expires, see your requests, and (for approvers) the queue of requests waiting for you, with the reason and what the requester did on that resource in the past 30 days. Admins and auditors also see active grants (admins can revoke) and everyone’s requests. See access requests everyone
Reviews Access reviews: the items assigned to you to keep or remove, and for admins start a review, give back a withheld role, and download a signed evidence pack. See access reviews everyone sees their own; admins and auditors see all
Users See who has signed in and their roles. Lock a user (they are signed out, can’t log in, and their open sessions end within seconds) or unlock them, always with an audited reason admins
Bots The CI jobs that can log in (from the bot documents in policy): what each one matches, its last login and CI run (with a link to the run), and its sessions. Lock one from its page, like a person. See the bots guide admins
Workers See enrolled proxies and workers and their tunnels. See which join tokens are still outstanding (who made them, when they expire; never their values), create single-use join tokens (shown once) and revoke a component admins
Audit trail The last 30 days of events (sign-ins, denials, locks, kills, revokes, token creation, policy changes), filterable by event (or a prefix such as auth.*), user, people or bots, text in the details, session, and a UTC time range; each applied filter is a chip you can remove, and a row’s trail link lists every event of its session. A Kubernetes tab lists every kubectl API request (user, cluster, verb, resource, namespace, name, status, time), filterable by cluster, verb, namespace, user, and “refused or failed”. A user’s page shows their recent activity. It is a summary: the complete, signed events live in your audit sinks admins
Dashboards Built-in charts for the last 24 hours, 7 days or 30 days: sessions over time (people and bots apart), sign-ins next to denials, bot sessions by repository, busiest resources and people, session length, why access was denied, and admin actions, plus security panels (most refused people, out-of-hours access, longest sessions, accounts and addresses used, sessions without a recording) and reliability panels (quiet components, tunnels per worker, database, Kubernetes and web-app errors). Pick a view (Overview, Security, Reliability, Bots, Usage, Everything) or Choose panels. Every number, bar and row links to the audit trail or sessions list for the same period, with the filters already set. Drawn by the console itself, nothing to install admins
Policy Browse every document as the YAML behind it, with its owner: files applied with limen admin apply, the console, or a pipeline through the API. Edit, create, and delete the documents the console owns; the rest are read-only here. Check a change: paste YAML, see the diff, nothing is applied admins
Policy changes Writes held because they widen standing access: a pipeline’s roles and mappings, or another admin’s change with --widening-approval=all. Each shows who made it, the CI run behind it, and who gains access. Approve applies it to the policy as it is now, or supersedes it if that would give access the page didn’t show; reject needs a note. Never your own change, nor one from a CI run you started admins, and approver groups of writer grants

Also in the pages above: a resource’s page has Request access when you can ask, and Who can reach it for admins and auditors. Resources → Discovered (admins) holds what workers found in the cloud until you accept it (discovery). Audit trail has a search box that finds a command or statement and opens the recording at that moment (search); auditors get the audit trail and every session too, read-only. Policy has an access simulator and the difference shows who gains or loses access and the policy’s test results. A live SSH session has Watch it (watching).

A few things worth knowing:

  • One owner per document. What files define stays in Git: the console shows it read-only, and limen admin apply changes it. What the console creates, the console owns (source console, namespace default), and a file apply leaves it alone. Every console write goes through the same checks as the API and limen admin apply: owners, etags (an edit made against a stale page is refused), policy tests with --policy-tests=required, and a second admin with --widening-approval=all.
  • Everything you change is audited as you, marked as coming from the console.
  • List pages refresh themselves every 10 seconds (Overview, Resources, Sessions, Users, Bots, Workers, Audit trail, Dashboards). Refreshing pauses while the tab is hidden, while you have text selected, and while anything on the page has focus or a form has unsaved input, so it never eats what you are typing.
  • Phones and tablets. The menu becomes a strip you scroll sideways, wide tables scroll inside their own box, and the controls are sized for a thumb. Checked in the Chromium and WebKit (Safari) engines, from a 360px phone to a 1440px desktop, in light and dark, with no sideways scrolling and no axe-core (WCAG 2.1 AA) violations.
  • Supported browsers. The current and previous major release of Chrome, Edge, Safari (macOS, iOS and iPadOS), Firefox and Firefox ESR, and Chrome on Android. The oldest versions that have what the console’s styling uses (color-mix() and :has(), from browser compatibility data) are Chrome and Edge 111, Safari 16.2 and Firefox 121. Below those, a style that is not understood is dropped, so some colour is expected to be lost; that was not tried. What was run, on 2026-10-28, with no sideways scrolling, JavaScript errors or axe-core (WCAG 2.1 AA) violations in light and dark: Chromium and WebKit (Playwright), and Firefox 159 on macOS (Puppeteer, four sizes from 360px to 1440px). Those runs covered the pages a fresh dev stack can show, not every page with real data. Not tried: Firefox ESR, Firefox below 159, Firefox with touch emulation, versions older than the engines above, real devices and screen readers.
  • Switch theme with the sun/moon buttons at the bottom of the sidebar (it follows your system by default).
  • Browser sign-ins last 8 hours by default (never longer than the maximum certificate lifetime), or until you sign out or an admin locks you. This is separate from the CLI’s short-lived certificate.
  • Setup for your own deployment (OIDC client, public URL): docs/runbooks/console.md.

Command lists. Database, Redis, MongoDB and search sessions have no terminal recording. Their session page lists what ran (up to 500 entries, including the ones policy refused). The console keeps that text in the control plane’s database for 30 days (table db_statements), visible only to admins and the session’s own user. The complete trail stays in S3 and Datadog.