Licensed to be used in conjunction with basebox, only.
// start
Roles in basebox
This documentation distinguishes four roles. Each has its own main section so nobody has to navigate through someone else's topics: whoever connects the OpenAI API should not pass GPU drivers; whoever installs a server should not pass SDK tutorials.
| Role | What you do | Your section |
|---|---|---|
| User | Chat, process files, use apps and knowledge bases | Use basebox |
| Administrator | Configure basebox as an application: users, groups, models, apps, connectors, audit | Administration |
| Developer / Integrator | Integrate basebox into software: OpenAI-compatible API, REST API, MCP, custom connectors | Developer |
| Platform Operator | Install and operate basebox Server: bare metal, NVIDIA, Kubernetes, inference, monitoring | Developer → Installation & Operations |
One person can hold several roles – in small organizations often all four. The separation serves navigation, not responsibility.
Two roles that are often confused
Administrator ≠ Platform Operator. The administrator works in the basebox interface and configures the application. The platform operator works on the server and owns the operating system, GPU, Kubernetes and inference. In the Cloud, the customer side has only the administrator – basebox handles operation. With Server there are both, and the platform operator is either your IT or basebox, where commissioned.
Developer ≠ Platform Operator. Using the API takes an API key and a base URL – nothing more. Kubernetes, Helm and drivers belong in Developer → Installation & Operations.
For security and compliance stakeholders
Data protection officers, IT security and compliance have no main section of their own in this table because they read across all roles. Their entry point is Security & Compliance, structured by Demo, Cloud and Server.