OpenComputers
OpenComputers connects machines you control to MIOSA through an authenticated outbound agent session. A connected machine is an OpenComputer. It can be a workstation, a GPU machine, an on-premises server, or a supported existing server at a hosting provider.
MIOSA supplies the organization, authorization, and remote-operation surface. You operate the host and choose the permissions, files, services, and capabilities available to its agent.
OpenComputers and on-premises servers
A server in your office, lab, or data center is on-premises infrastructure. Connecting that server through OpenComputers makes it available as an explicit host target for supported operations. A headless server can perform command and file work without providing a desktop session.
OpenComputers describes the connection model, not the location of the hardware. The same model can connect a supported machine in your own building or at a hosting provider.
In these docs, BYOC means Bring Your Own Cloud: governed worker capacity in your AWS account or Google Cloud project. That is a separate onboarding path from connecting one existing machine.
Start with a verified connection
For a Linux server, follow Connect your first server. It includes installation prerequisites, the difference between a host key and an API key, service startup, and a command with an expected result. For other operating systems, use the current OSA installation guide and verify the required host capabilities. An operating system appearing in registration does not guarantee desktop support or a prebuilt agent for every CPU architecture.
Connect a machine
- Open OpenComputers in MIOSA and register the machine in the intended organization.
- Follow the generated installation and connection instructions on that machine, using the agent supported for its operating system and architecture.
- Save the host credential returned at registration; it is shown only once.
- Allow the agent’s outbound authenticated connection to MIOSA.
- Verify the host is online, inspect its capabilities, and run a small command on that exact host.
The agent initiates the connection, so it does not require an inbound management port or a public IP on your host. For unattended operation, configure the supported service startup method for the installed agent and verify that the connection returns after a restart.
Use the OpenComputers project documentation for agent installation details. The OpenComputers API reference describes host registration, lifecycle, jobs, files, tunnels, and sessions.
Verify a host with the API
List the hosts available to your organization:
curl https://api.miosa.ai/api/v1/opencomputers/hosts
-H "Authorization: Bearer $MIOSA_API_KEY"Select the intended online host and use its returned identifier for a read-only command:
curl -X POST "https://api.miosa.ai/api/v1/opencomputers/hosts/$HOST_ID/exec"
-H "Authorization: Bearer $MIOSA_API_KEY"
-H "Content-Type: application/json"
-d '{"cmd":"hostname","stream":false,"timeout_ms":10000}'With stream: false, the API collects output for the command and returns job_id, exit_code, stdout, and stderr.
Expect exit_code: 0 and the selected machine’s hostname in stdout.
For longer commands, use the default SSE mode and watch for a terminal result.
An accepted request is not proof that the command completed.
Keep the API key in your backend or terminal environment.
Capabilities and isolation
| Capability | What to verify on the selected host |
|---|---|
| Commands and files | The installed agent supports the operation and has the required user and filesystem permissions. |
| Agent work | The selected runner, model configuration, credentials, and tools are available. |
| Desktop access | The host has a supported desktop session and streaming backend; a headless host need not provide one. |
| Local models | The selected model runtime is installed and the machine has suitable CPU, GPU, and memory capacity. |
| Isolated guest workloads | The host advertises the required virtualization runtime and has passed the applicable setup and acceptance checks. |
Direct host execution runs within the host agent’s operating-system permissions. It does not automatically put each command in an isolated microVM. Registration alone does not turn an arbitrary host into a Sandbox worker pool or an App Engine Host.
Tunnels and local services
A tunnel exposes a selected local port through a MIOSA-managed URL.
Create it explicitly and choose the access policy appropriate to the service.
Use the returned public_url; do not construct a hostname yourself.
The tunnel API supports public, tenant_only, and password access modes.
See OpenComputers tunnels for request fields and access configuration.
An outbound management connection and a publicly accessible application tunnel are different things.
Placement and reliability
An explicitly selected host keeps the target unambiguous. Do not assume that an offline or full host causes the job to move to the cloud automatically. Fallback requires an authorized target with compatible capabilities, data access, and a recovery plan.
Monitor host status and active jobs before maintenance. A disconnected remote session does not prove that a local process stopped; confirm the outcome before retrying work that could have side effects. Your team remains responsible for the host’s operating system, storage, backups, power, and network availability.
Data and credentials
Running a command locally describes its execution location, not an absolute data-residency guarantee. Requested output, artifacts, desktop streams, and model requests can leave the host as part of the workflow. Set agent permissions and network access to match the data and services you intend to expose.
For hardware ownership, connectivity, and data-boundary examples, read On-premises servers. For current commercial terms, see Pricing.