Runtime and site delivery
A Runtime target is where an App actually receives a version and runs. It can be the local target on the development computer or a remote target on an industrial PC, edge device, or site server.
The editor always remains on the development computer. Switching targets changes only where Preview, Build, Start, and Debug operate. It does not move the project, Git repository, AI conversations, or editor settings.
Choose a local or remote target
| Choice | Best for | Confirm before use |
|---|---|---|
| Local target | First-time learning, Page and logic checks, and fast development iterations | The local machine has the packages and equipment conditions needed for the test; local results do not replace site acceptance |
| Remote target | Commissioning on an industrial PC or edge device, using the real network and equipment, and delivering a site terminal | The address and certificate are trusted, target permissions are correct, licenses and equipment are available, and downtime is approved |
The first tutorial uses the local target. Connect a remote Runtime target only when the App must run in the real environment of another machine.
Delivery sequence
Save → verify target → Stop → Build → Preview / Start / Debug → accept → Stop
Save, Build, and runtime execution are separate stages. Save does not change the target version, Build does not Start automatically, and Start does not read changes that have not been delivered. See From Save to runtime for action and state meanings. Build and runtime acceptance is the authoritative procedure, including Problems handling.
Checks before remote delivery
Before acting on a production or site target, confirm at least the following:
- The target name, address, machine, and physical location agree.
- The remote connection uses trusted HTTPS and the network path meets site-security requirements.
- The current person uses target
Adminaccess for deployment and lifecycle operations. - The existing App, runtime state, and replacement impact on the target have been reviewed.
- Licenses, external equipment, process parameters, interlocks, and the recovery plan are ready.
- When a terminal will show Pages continuously, Theseus Player acceptance is planned.
A Runtime target account authorizes only one execution target. Qixin online-service accounts and operator identities inside the App do not follow target changes. See Runtime target accounts and permissions.
Continue by task
| Task | Documentation |
|---|---|
| Add, check, and bind a remote target | Connect a remote Runtime target |
| Distinguish User, Admin, and App user permissions | Runtime target accounts and permissions |
| Decide what is available in the current state | Runtime states and controls |
| Complete Build and runtime acceptance | Build and runtime acceptance |
| Configure and accept a site runtime terminal | Use Theseus Player on a site terminal |
| Install or update a target License | License management |
| Diagnose connection, Build, and runtime failures | Troubleshooting |
Delivery principles
- Prefer the local target for development checks; perform site acceptance on the real target under real equipment conditions.
- A person with the required permission explicitly performs Build, Start, Debug, Stop, and target changes.
- Reachability does not grant deployment permission. Verify target identity, Admin access, and site state as well.
- A successful Build proves that a version can be generated and delivered. It is not production approval.