Skip to content

Users & tenants

Tenants

A tenant is the customer separator — typically one customer or department.

Create

/admin/tenants → New:

Field Meaning
Name display name
Slug URL slug, unique
Branding logo, color (for status pages and PDFs)
Notes optional

Per-tenant data

After creation a tenant has:

  • 0 hosts
  • 0 custom dashboards
  • Default alert-channel templates (empty)
  • Audit log

You can immediately add hosts; profiles are tenant-wide (built-ins) available.

Delete tenant

Soft delete cascades: all hosts, services, alerts of the tenant are also soft-deleted. deletion_batch_id connects them — restore in trash UI brings the family back.

Permanent deletion after 30 days or via admin purge.

Cross-tenant visibility

Default: a user sees only their own tenant.

Super admin: all tenants. Visible in the tenant dropdown top left.

Custom roles can have tenant.cross_view — user sees multiple tenants without super-admin status.

Users

Create

/admin/users → New:

Field Meaning
Email login
First / last name display name
Tenant super admin: optional, otherwise fixed
Role default or custom
Active toggle
Password optional set or invite mail

Invite mail

When you create without password, Vesana sends an invite mail with a setup link. The user clicks, sets password + 2FA, is active.

Prerequisite: SMTP configured (see Setup wizard).

Forgot password

Login page → Forgot password → mail with reset link.

Reset tokens valid 1 h, single-use.

Active / inactive

Instead of deleting, set Active = false. Benefits:

  • Audit log keeps the user reference
  • Re-activation possible
  • Dashboard owner relationships remain

Inactive user can't login, all tokens invalidated.

Soft delete

Real delete is soft delete (see Trash). Audit log keeps user_id — that this user existed.

JWT vs. DB user

Active JWT tokens contain user IDs (sub). On soft delete the user stays in DB — JWT remains valid until expiry. On hard-delete cascade after 30 days, the user vanishes from the DB, but FK constraints on users(id) were intentionally removed (see architecture note in CLAUDE.md) so old JWTs don't cause DB errors.

Switch tenants?

Not directly. Workflow:

  1. Deactivate user in old tenant
  2. Create new user entry in new tenant with same email
  3. Resolve login overlap manually short-term

My-account view

Each user under /profile:

  • Email (read-only after creation)
  • Change display name
  • Change password
  • Enable 2FA / recovery codes
  • Language (DE/EN)
  • Theme
  • AI visibility (hide_ai)
  • Manage API keys (Pro+)

API keys (personal access tokens)

Alternative to browser login for CLI/scripts:

/profile → API keys → New:

  • Name + expiry
  • Scope (read-only / read-write)
  • Token shown exactly once

In requests: Authorization: Bearer <token>.

Revoke any time; old token hash invalidated.

Permissions vs. tenant scope

Permissions are tenant-scoped: a user with host.create can only create hosts in their tenant. Cross-tenant operations need super admin or special custom roles.

Details: Roles & permissions.

Next