Operations and deployment
Manage the service, execution target, and persistent research records as separate responsibilities. First verify a local connection with the quickstart, then choose the operation you need.
Choose an operation
| Goal | Guide |
|---|---|
| Submit, wait, follow logs, cancel, or delete Tasks | Task management |
| Browse and inspect workspace artifacts | Workspace files |
| Copy completed Task snapshots | Task synchronization |
| Configure service access and tokens | Authentication |
| Host a service with or without Studio | Deployment |
| Use CLI direct access or Studio forwarding | Remote machines |
| Forward configured HTTP requests | HTTP proxy |
| Schedule recurring Jobs | Scheduling |
| Send task notifications through DingTalk | Notifications |
| Diagnose failures, back up, and recover records | Troubleshooting and recovery |
Establish the execution environment
A remote service owns its plugins, data, worker processes, and workspace. Direct CLI access uses the target service token; Studio uses the local token and forwards through its same-origin backend to a configured target. Use the same execution target for submission, waiting, logs, and artifact queries.
Task synchronization copies terminal Task directories. Prepare raw data, plugin dependencies, model credentials, and Agent session environments separately. See workspace concepts for storage boundaries and client configuration for connection precedence.
Preserve evidence while maintaining the service
Retain distinct Task identities for experiments. A fixed-name rerun replaces a finished directory; deletion removes records and artifacts. Cancellation and service shutdown affect workers but do not provide resumable execution. Read task lifecycle before choosing cleanup or recovery actions.