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, Contributor, Editor, or Manager — so someone can be a manager of one agent and a viewer of another. Contributor is the role for an outside collaborator on a project: they can add files to the agent's shared workspace, but they never act as the agent. 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, and a license (added under Setup → OtoDock) raises the cap.

Removing people

When someone is removed from an agent, moved below the editor role there, loses the admin role, or has their account deleted, the automations they set up for the agent keep running. Their shared tasks, triggers and scheduled notifications on that agent move to the admin who made the change, with their schedules intact, and that admin gets one notification listing everything they now own. If the change came from your identity provider, the owner receives them instead. The notification also lists any agent API keys the person created, which keep working until you revoke them under the agent's API keys.

The person's open chats on that agent close, and if they no longer have access to the agent, their personal apps there stop until they're given access again. Deleting an account also removes the person's own personal tasks, triggers and notifications, and moves their personal files to an archive on the server rather than deleting them. An archive is deleted after 180 days by default, and admins manage the archives under Setup → System Settings.

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. A password can be up to 72 plain letters and digits long.
• Two-factor authentication. Users can turn on app-based 2FA (a standard authenticator code) for their own account, with one-time recovery codes. An admin can also require it for every local account by turning on Require Two-Factor Authentication under Setup → Security, and each person then sets it up at their next sign-in. People who sign in through SSO aren't affected, since their identity provider handles this.
• 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 / OIDC_ISSUER / OIDC_JWKS_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.

Signing out ends the sign-in on that device only, and a password change ends the person's other sign-ins. An admin can sign someone out of every device with Sign Out Everywhere when editing the person on the Users page.

Running behind a reverse proxy?

Set TRUSTED_PROXY so these protections see real client addresses instead of the gateway's IP — see Reverse proxy & HTTPS. Until it's set, users restricted to local-network sign-in can't sign in through the proxy at all, because OtoDock can't tell where they're connecting from.

Sharing and links

People can share apps and chats with their colleagues, and with anyone outside the platform through a link. A team app can also go to another agent, or from an admin to a whole department. Under Setup → Security → Sharing, admins decide which of these are allowed and whether a link can be shared without a password. Every share and every link on the install is listed under Admin → Shares, so an admin can revoke any of them. See Sharing.

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.