Runtime target accounts and permissions
The runtime page first requires an account owned by the current Runtime target. This account determines whether someone can view the target, change runtime state, or administer the target. It is independent from a Qixin online-service account and from operator identity inside an App.
User and Admin
| Target role | Can | Cannot |
|---|---|---|
| User | Sign in to the runtime page; view the currently delivered App and runtime state; use an App that is already Running | Deploy, Preview, Start, Debug, or Stop; change target settings, licenses, or target accounts |
| Admin | Includes User viewing access; can also Deploy, Preview, Start, Debug, Stop, and manage target settings, licenses, and accounts | Does not automatically become an App user or receive an operator role inside the App |
Build prepares a version in the editor and then delivers it to the current target; the delivery stage requires target Admin access. A target User cannot start a Stopped App and is never promoted merely by opening the runtime page.
Runtime-page sign-in order
- Enter the runtime page with a Runtime target account.
- When the App is already Running, both target User and Admin can view and use its runtime entry point.
- When the App is Stopped, a target Admin confirms site conditions and performs Start. A User can only see the current state.
- When the App uses operator roles, sign in or switch to the actual operator with an App user as a separate step.
The local target supplied by Theseus Desktop provides a development administrator session and does not require another target account. The first connection to a remote target creates its initial Admin. That target's Admin then maintains other accounts according to least privilege.
App user is a separate identity
An App user represents the current operator and controls role-restricted Components and business operations inside a Page. It belongs only to that App.
| Identity | Protected scope | Typical tasks |
|---|---|---|
| Runtime target account | One execution target, its delivery, and runtime state | View state, deploy, start, debug, stop, and maintain the target |
| App user | Operator roles inside one App | Use authorized Components and business operations |
App Admin is only an App role. It has no target Admin permission to Deploy, Start, or Stop. Target Admin also does not replace App user as the recorded operator. See App users, roles, and runtime-page sign-in for configuration steps.
Recommended site assignments
| Scenario | Recommended access |
|---|---|
| Operator terminal that only views state and uses a running App | Target User, plus an App user when a business role is required |
| Delivery, debug, or maintenance workstation | Target Admin granted only to the people responsible for those tasks |
| Unattended display terminal | Target User, with the App started beforehand through a controlled Admin process |
| Target-account, License, or runtime-setting maintenance | Target Admin, with the change recorded |
Do not retain Admin credentials on a terminal merely so it can start an App once. Start the required App through a controlled Admin process, then let the User terminal operate it.
Common permission prompts
Qixin is signed in, but target Admin is still required
Qixin sign-in authorizes online services only. Remote connection, Deploy, Preview, Start, Debug, Stop, and target management use the current Runtime target's own Admin.
User can see the App but cannot Start
This is expected. User can inspect state and use an App that is already Running, but cannot change its lifecycle. An Admin must verify the target and site state before starting it.
App Admin cannot Stop
App Admin affects only role checks inside the App. Stop is a Runtime target control and requires target Admin.
The target is signed in, but an App user is still required
The target account grants entry to the runtime surface. The App can still require the actual operator to sign in with an App user. Neither identity replaces the other.
Security requirements
- Keep at least one available Admin for every remote target and manage its recovery according to site procedure.
- Grant Admin only to people who deliver, debug, or maintain. Use User for viewing terminals.
- Use trusted HTTPS for remote management. Do not bypass certificate checks to solve a connection problem.
- Before Deploy, Preview, Start, Debug, Stop, or target management, a person verifies target identity and equipment state.
- App roles do not replace equipment interlocks, backend authorization, emergency stops, or safety controllers.
Next steps
- Understand the overall flow: Runtime and site delivery
- Add a remote target: Connect a remote Runtime target
- Configure an operator terminal: Use Theseus Player on a site terminal