On-premises servers
Use servers you already operate as execution targets for MIOSA agents and remote workflows. A supported Linux server in your office, lab, or data center connects through OpenComputers, the same connection path used for customer-controlled workstations and other existing machines.
On-premises tells you where the server runs. OpenComputers tells you how MIOSA connects to it. The connected host is an OpenComputer.
What runs where
| Layer | Location and responsibility |
|---|---|
| MIOSA organization, workspace, API, and orchestration | MIOSA control plane |
| Server hardware, operating system, power, and disks | Your premises; operated by your organization |
| OpenComputers agent and authorized execution | Your server, within the installed runtime’s permissions and capabilities |
| Local applications, files, and private services | Your environment; access depends on the agent’s identity and network reachability |
| Commands, status, output, and requested artifacts | May pass through MIOSA as part of the workflow |
A headless server can support commands, files, and agent work without an interactive desktop. Desktop access requires a supported desktop session and streaming capability on that host. Connecting a machine does not by itself create isolated Sandbox capacity or enable every managed Computer feature.
Connect and verify a server
Use Connect your first server for the complete Linux walkthrough with commands and expected results. The capability comparison helps choose between an OpenComputer, a managed resource, and BYOC.
- Choose a supported host and decide which files, services, and credentials its agent may access.
- Register the machine in the OpenComputers interface and follow the generated installation and connection instructions on that server.
- Allow the agent’s authenticated outbound connection to MIOSA through your network policy.
- Confirm the host is online and advertises the capabilities your workflow requires.
- Select that exact host, run a small read-only command, and verify its returned result.
- Configure service startup and monitor host connectivity before relying on it for unattended work.
The agent establishes the connection from your network. You do not need to expose an inbound management port or give the server a public IP for that connection. Any tunnel that publishes a local service is a separate, explicit exposure with its own access policy.
See the OpenComputers guide for connection details and the OpenComputers API for host operations.
Execution location and data boundaries
Running work on your server keeps that execution on your hardware. It does not imply that all data stays on-premises: command output, logs, artifacts, desktop streams, or model requests can leave the machine according to the workflow you configure. For example, an agent using an external model provider may send prompts or selected file content to that provider. Choose model endpoints, output handling, secrets, and network policy according to your data requirements.
Operating your servers
Your organization maintains power, physical access, hardware replacement, OS updates, local storage, backups, firewall rules, and agent permissions. MIOSA provides the connected control-plane surface and reports host state. A server being online is not evidence that its applications are healthy or its data is backed up.
Before maintenance, stop new work and inspect active jobs before disconnecting or shutting down the host. If a connection is lost while work is running, verify the job’s actual outcome before retrying operations that could produce duplicate side effects. Do not assume that a local process stopped when its remote session disconnected.
On-premises, BYOC, and hybrid use
| Scenario | Use |
|---|---|
| Run agent jobs on a server in your own data center | OpenComputers on that server |
| Connect one existing rented server or cloud VM | OpenComputers on that supported machine |
| Provision governed worker pools in your AWS account or Google Cloud project | The provider’s BYOC onboarding path |
| Combine local execution and MIOSA-managed compute | Explicit target selection with compatible capabilities and an approved data boundary |
A registered OpenComputer does not automatically become a BYOC region, a fleet of Sandbox workers, or an App Engine Host. Each of those resource roles has its own runtime and acceptance requirements.