Users & access
OtoDock supports a whole team, with roles that decide who can do what and sign-in options that fit how your organization already works.
The owner and platform roles
The first account you create during setup is the owner — a protected administrator that can't be deleted or demoted. From there, every user has a platform role:
| Role | Can do |
|---|---|
| Admin | Run the platform — manage users, settings, security, integrations, and all agents. |
| Creator | Create and manage their own agents — persona, tools, and settings. (Adding people to agents is an admin task.) |
| Member | Use the agents they're given access to. |
On top of that, each agent grants its own per-agent role — Viewer, Editor, or Manager — so someone can be a manager of one agent and a viewer of another. See Agents for what those mean.
Adding people
Admins add users from the Users page with a name, email, role, and a temporary password the person changes on first login. You can adjust anyone's role, assign them to agents (with a per-agent role), and manage their account from the same place.
A self-hosted install without a license includes five user accounts; a license (added under Setup → OtoDock) raises the cap.
Signing in
- Email and password. Local accounts with a configurable password-strength policy set under Setup → Security. If email is configured, users can reset their own password by email.
- Two-factor authentication. Users can turn on app-based 2FA (a standard authenticator code) for their own account, with one-time recovery codes.
- Single sign-on (SSO). Admins can connect an identity provider over OIDC — works with Authentik, Keycloak, Authelia, Okta, Microsoft Entra, and others — and map provider groups to OtoDock roles, so people sign in with the identity they already have. The exact settings are below.
Single sign-on (OIDC)
Connecting a provider is a handful of lines in the same .env (config.env on source
installs) as your other deployment settings. First create an OIDC application in your
provider with <DASHBOARD_PUBLIC_URL>/auth/callback as the redirect URI — that's the
one OtoDock derives automatically. Then:
# .env
OIDC_ENABLED=true
OIDC_PROVIDER_NAME=Authentik # login button reads "Sign in with <name>"
OIDC_DISCOVERY_URL=https://auth.example.com/application/o/<app-slug>/.well-known/openid-configuration
OIDC_CLIENT_ID=<from your provider>
OIDC_CLIENT_SECRET=<from your provider>
# Map your provider's groups to OtoDock roles. The mapping is also the access
# gate: someone in none of the mapped groups cannot sign in over SSO — so
# configure at least one, and put your users in it.
OIDC_ROLE_ADMIN_GROUP=OtoDock Admin
OIDC_ROLE_CREATOR_GROUP=OtoDock Creator
OIDC_ROLE_MEMBER_GROUP=OtoDock Member
Restart to apply (docker compose up -d) and the login page grows a "Sign in with …"
button. Local accounts keep working alongside SSO, so you can't lock yourself out. On
someone's first SSO sign-in OtoDock creates their account (it counts toward your user
cap), gives them the role of their highest mapped group, and attaches the agents marked
default-for-new-users.
The discovery URL is fetched at startup and the individual endpoints derive from it.
Providers without discovery can set OIDC_AUTHORIZE_URL / OIDC_TOKEN_URL /
OIDC_USERINFO_URL / OIDC_LOGOUT_URL directly, and OIDC_SCOPES (default
openid profile email groups) is adjustable — all documented in config.env.example.
Login security
OtoDock protects the login page out of the box:
- Rate limiting and slow-downs on repeated failed attempts, so guessing is impractical without locking out a legitimate user.
- Optional bot protection (Cloudflare Turnstile) you can enable under Setup → Security.
Login sessions stay valid while you're active and time out when idle (a duration admins set, seven days by default). You can also restrict a specific user to local-network sign-in only.
Set TRUSTED_PROXY so these protections see real client addresses instead of the
gateway's IP — see
Reverse proxy & HTTPS.
Personal API keys
For automation, any user can create a personal API key under User Settings → API Keys. The key is scoped to that user and shown once — copy it when you create it. It's used to drive OtoDock from the outside, most commonly to fire webhook triggers from another system. Revoke a key any time.
→ See API & Webhooks for how to use keys.
Next steps
- Agents → — per-agent roles and how to assign people.
- Configuration → — where SSO and security settings live.
- Usage & Limits → — budgets by role, user, and agent.