Start here
Roles & access
Lunax has exactly three roles. Each person has one, it applies across the whole workspace, and only an admin can change it.
The three roles
| Role | Who it's for | Gets |
|---|---|---|
| Customer | Your users. Everyone starts here. | Own tickets, plus posting, voting, and commenting on public boards |
| Agent | Your support team | Everything a customer gets, plus the shared inbox and feedback moderation |
| Admin | Whoever runs the workspace | Everything an agent gets, plus apps, API keys, and role management |
Access at a glance
| Page | Anonymous | Customer | Agent | Admin |
|---|---|---|---|---|
/ | Yes | Yes | Yes | Yes |
/b/{slug} | Public apps | Public apps | All | All |
/docs | Yes | Yes | Yes | Yes |
/my | Sign in | Yes | Yes | Yes |
/inbox | Sign in | No | Yes | Yes |
/feedback | Sign in | No | Yes | Yes |
/admin | Sign in | No | No | Yes |
Blocked users are redirected somewhere useful rather than shown an error: a customer landing on /inbox goes to /my, and an agent landing on /admin goes to /inbox.
How signing in works
There are no passwords. Three ways in, all landing on the same account:
- Magic link — enter your email, click the link that arrives.
- Google — one click, if the workspace has it enabled.
- GitHub — same.
The same email address across different providers resolves to one profile, so signing in with Google after using a magic link doesn't create a duplicate. Your display name and avatar come from the provider when it supplies them; otherwise your name defaults to the part of your email before the @.
Your first sign-in creates the profile automatically with the customer role. There is no invite flow — people appear in the workspace only after they sign in themselves, or when a ticket is created on their behalf via the widget or API.
Becoming the first admin
A brand-new workspace has no admin, and /admin is unreachable until one exists. Fix it once, from the Supabase SQL editor, after signing in for the first time:
update public.profiles set role = 'admin' where email = 'you@example.com';The bundled migration 002_bootstrap_first_admin.sql does the same thing automatically — it promotes the oldest account, but only if no admin exists yet. From there, promote everyone else from the UI.
Changing someone's role
Admins open /admin/users, find the person, and pick a new role from the dropdown. It saves immediately. The same control promotes and demotes.
/admin — recovering means running the SQL above directly against the database. Keep at least two admins.Role changes take effect on the person's next request; they don't need to sign out and back in.
Things to know
- Any signed-in user can read the profile list — names, emails, and roles. Treat the workspace as visible to everyone in it.
- Agents can read the audit log, not just admins.
- There is no way to deactivate, suspend, or delete a user. The closest thing is demoting them to customer.
- No one can escalate their own role — that's blocked at the database level, not just in the UI.