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.
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 (in the same .env/config.env as your other deployment settings) to
your proxy's IP so OtoDock reads the real client address from X-Forwarded-For. Without
it, every visitor shares the gateway's IP — which blunts the login rate limits and the
local-network-only restriction.
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.