MIOSA Glossary
Use this glossary when a product screen, API response, or guide introduces an unfamiliar MIOSA term.
Find a term below, compare it with nearby concepts, and follow the linked guide when you are ready to use it. Each term has a direct link you can share with your team.
Find a term
Use the topic cards below for a starting point, or open the alphabetical index when you know the term. For search across the docs, use Search documentation in the header.
Browse all 80 terms A-Z
Learn the flow first
The hierarchy answers who owns the resource. The publish flow answers how tested work becomes production.
Start with Release, Version, Deployment, Promotion, and Rollback.
Start with Computer, OpenComputer, Desktop session, and Agent Run.
Start with Deployment domain, Custom domain, DNS verification, and TLS certificate.
Ownership and organization
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| User | A person or service identity that signs in to MIOSA. | An Organization or customer account. |
| Organization | The top-level customer boundary for members, plans, billing, domains, and policy. | A User’s login. |
| Member | A User with a role inside one Organization. | A standalone User who has no access to that Organization. |
| Workspace | An isolated operating boundary for a team, customer, or line of business inside an Organization. | A Project or a local source folder. |
| Project | The container that groups development and production resources for one product or application. | A single Sandbox or Deployment. |
| Role | A named set of permissions granted to a Member. | An API key or temporary approval. |
| API key | A secret credential used by server-side software, automation, SDKs, or the CLI. | A browser-safe token or User password. |
Building and development
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| Sandbox | A mutable, isolated development environment where code, dependencies, commands, and tests can change. | A production Deployment. |
| Preview | A URL connected to a port in a running Sandbox, with access controlled by its preview or sharing configuration. | A stable production URL. |
| Snapshot | A saved point-in-time copy of Sandbox state that can be restored or forked. | An immutable production Release. |
| Template | A reusable starting configuration for creating a Sandbox. | A Snapshot of one customer’s live work. |
| Exec | A command executed inside a Sandbox or another supported compute resource. | A long-running production Runtime Instance. |
| Job | One tracked command execution with an identifier, progress, and a terminal result such as an exit code. | An Agent Run, which can coordinate multiple tool calls or commands. |
| Artifact | A file or result preserved from a build, command, evaluation, or Agent Run. | A full Release unless the publishing flow explicitly creates one. |
Example: a screenshot saved by an agent is an Artifact; a saved Sandbox state is a Snapshot; the application produced by publishing is a Release. See Sandbox persistence for what is saved and how recovery works.
Computers, connected machines, and desktops
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| Computer | A compute resource used for machine-level work; desktop access depends on the resource and its advertised capabilities. | A code-focused Sandbox. |
| Desktop session | The interactive connection used to view and control a Computer. | The Computer itself, which can outlive one session. |
| OpenComputer | A customer-controlled machine connected through OpenComputers, such as an on-premises server, workstation, GPU host, or existing hosted server. | Bring Your Own Cloud worker capacity. |
| MIOSA-managed Computer | A Computer whose underlying capacity and lifecycle are operated by MIOSA. | An OpenComputer owned by the customer. |
| Warm capacity | Compatible compute kept ready so a new Computer or Sandbox can start faster. | A guarantee that every requested size is immediately available. |
| Heartbeat | A periodic message from a connected host indicating that its agent is communicating with MIOSA. | Proof that an application, desktop, or specific command is healthy. |
| Readiness | Evidence that a resource can perform the particular operation you need now. | A resource record existing, a request being accepted, or a heartbeat alone. |
Example: a headless server can be connected and ready to execute commands without being ready to stream a desktop. Check infrastructure capabilities before selecting a target.
Publishing and production
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| Publish | The operation that freezes selected source and creates an immutable production candidate. | Promote, which changes what receives production traffic. |
| Builder | The isolated job that converts selected source into an immutable Release. | A Sandbox or production Runtime Instance. |
| Release | The immutable application artifact produced by a successful publish operation. | A Version, which combines a Release with deployment configuration. |
| Version | A candidate that connects one Deployment to one Release and its required configuration. | The Deployment’s stable identity. |
| Deployment | The durable production identity that owns versions, routes, configuration, and data bindings. | A single running container or Version. |
| Promotion | The controlled change that makes an exact verified Version active for a Deployment. | Publishing or rebuilding the application. |
| Rollback | Promotion of an earlier ready Version to restore previously known application behavior. | Restoring a database, undoing external side effects, or editing a Release in place. |
| Runtime Instance | A running copy of a dynamic Release serving one Version. | The Deployment, which can continue across many instances and versions. |
| App Engine Host | An always-on host that can run multiple workspace-scoped application deployments as isolated containers. | A Deployment or customer-facing application URL. |
| Desired state | The configuration MIOSA is expected to maintain for a resource. | The resource’s current observed condition. |
| Reconciliation | The process that repairs a resource when its observed state differs from its desired state. | A manual redeploy initiated by a customer. |
See publishing for candidate creation and rollback for restoring an earlier application version.
Domains and routing
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| Domain | A hostname that routes requests to a MIOSA resource. | The Deployment or application behind it. |
| Preview domain | A branded parent domain used to create temporary Sandbox Preview hostnames. | A production Deployment domain. |
| Deployment domain | An Organization-controlled parent domain used to create stable hostnames for deployments. | One specific application’s Custom domain. |
| Custom domain | A specific customer-owned hostname attached directly to one Deployment. | A parent domain used to generate many hostnames. |
| Platform URL | A MIOSA-provided hostname available without customer DNS configuration. | A customer-owned branded hostname. |
| DNS verification | The check that proves the required public DNS record points to the expected MIOSA routing target. | TLS certificate issuance, which follows successful routing verification. |
| TLS certificate | The certificate that enables trusted HTTPS for a verified hostname. | Ownership of the domain registration. |
| Routing | The mapping that sends a hostname to the correct Organization, Deployment, and active Version. | DNS propagation alone. |
Example: app.example.com can be a Custom domain attached to one Deployment; a Deployment domain supplies the parent hostname used for generated application URLs.
Follow deployment domains to choose the right setup.
Customer infrastructure
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| On-premises | Infrastructure operated at your own site, such as an office, lab, or data center. | A connection protocol or a self-hosted MIOSA control plane. |
| On-premises server | A server you operate at your site; a supported machine can connect to MIOSA through OpenComputers. | A MIOSA-managed host or a customer-cloud worker pool. |
| OpenComputers | The connection and remote-operation system for customer-controlled machines, using an authenticated outbound agent session. | The physical location of the machine or a complete MIOSA installation. |
| Host | The underlying machine on which work executes; its runtime and capabilities determine the operations it supports. | A Sandbox, desktop session, or production Deployment running on it. |
| MIOSA-managed infrastructure | Compute capacity and host infrastructure operated by MIOSA. | Hardware your organization owns and maintains. |
| Bring Your Own Cloud (BYOC) | Customer-owned AWS or Google Cloud worker capacity governed through MIOSA’s control plane. | OpenComputers connected from individual machines. |
| Worker pool | A set of compatible hosts eligible to run a defined class of workloads under placement policy. | Any collection of registered machines regardless of capability. |
| Hybrid infrastructure | A product using more than one infrastructure location, with targets selected according to policy and capability. | Automatic migration or cloud overflow for every workload. |
| Data plane | The resources where workload execution and application data processing take place. | The control plane that authorizes and orchestrates the work. |
| Capability | An operation or runtime feature advertised by a resource, such as command execution or desktop streaming. | A guarantee that all connected hosts support the same features. |
| Customer-cloud region | An approved worker region operating inside a customer’s cloud account or project. | A MIOSA-managed region. |
| Placement | The decision that selects where an eligible workload may run. | Publishing the workload. |
| Control plane | The MIOSA service that records desired state, policy, scheduling, and lifecycle decisions. | The customer-owned machines where workloads execute. |
| Shared responsibility | The documented boundary showing which operating duties belong to MIOSA and which belong to the customer. | A transfer of all security responsibility to either party. |
Agents and automation
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| Agent Run | One tracked execution of an AI agent or command runner against a selected resource. | The persistent agent configuration. |
| Agent Run Group | A collection of related Agent Runs coordinated as one larger operation. | One Agent Run with multiple log events. |
| Runtime Profile | A reusable definition of the runner, tools, model settings, and execution policy for Agent Runs. | A Sandbox Template. |
| Approval | An explicit authorization required before a constrained operation may continue. | A permanent role or unrestricted permission. |
| MCP | The Model Context Protocol used to expose MIOSA tools to compatible AI agents. | The MIOSA REST API itself. |
| Event stream (SSE) | A connection that delivers a sequence of server-sent events, such as command output and its final result, to a listening client. | A Webhook sent as a separate HTTP request to your backend. |
| Webhook | An outbound HTTP notification sent when a subscribed event occurs. | A live event stream or polling request. |
| Evidence | A recorded result that proves an operation reached its required state. | A request being accepted or queued. |
Data, configuration, and security
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| Authentication | Proving which identity or credential is making a request. | Authorization to access a particular resource or perform an operation. |
| Authorization | Deciding whether the authenticated caller may perform an operation within the requested scope. | A successful login by itself. |
| Host key | The credential used by an OpenComputer’s agent to authenticate its host connection, returned once during registration. | A platform API key used to make REST requests. |
| Host fingerprint | The identifier for the host’s cryptographic identity used to recognize the same enrolled machine on later connections. | Its display name, host ID, or host key alone. |
| Isolation | The boundary separating a workload’s processes, files, or permissions from other workloads or its host. | A guarantee that every resource type uses the same boundary. |
| Data residency | The locations where data is stored or processed across a workflow, including outputs, artifacts, and model requests. | The location where one command executes. |
| Environment variable | A named configuration value supplied to a build or runtime process. | A secret by default. |
| Secret | A protected sensitive value whose plaintext access is restricted and audited. | Ordinary application configuration. |
| Binding | A durable connection between an application resource and a database, volume, secret, storage bucket, or service. | Copying the attached data into a Release. |
| Volume | Durable filesystem storage that can remain available across compatible runtime replacements. | The immutable application artifact. |
| Managed database | A database resource whose lifecycle is managed through MIOSA. | A database bundled inside an application container. |
| Object storage | Durable bucket-based storage for files and application objects. | A Sandbox filesystem or attached Volume. |
| Network policy | Rules that constrain which network destinations a workload may reach. | Authentication to the destination service. |
Example: the Host key connects your server’s agent; your API key authorizes the REST request that asks it to run a command. Running that command on-premises does not ensure that returned output or model requests remain on-premises. See server setup and data boundaries.
Usage and billing
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| Credit | A platform usage unit whose billing conversion is defined by the current plan and pricing contract. | A universal fixed amount of USD without checking current pricing. |
| Usage | Metered consumption attributed to an Organization, Workspace, resource, or workload. | An invoice or payment transaction. |
| Quota | A configured limit on resource count, capacity, spend, or operation rate. | Current usage. |
| Spend cap | A billing control that limits eligible consumption over a defined period or scope. | A guarantee that running resources stop instantly in every failure mode. |
| Plan | The Organization’s product tier and included entitlements. | A one-time credit adjustment. |
See usage and billing for metering and attribution, and pricing for current commercial terms.
Relationships worth remembering
- A User becomes a Member of an Organization through a role or invitation.
- An Organization owns one or more Workspaces.
- A Workspace contains Projects and the resources created within its boundary.
- A Project can contain multiple Sandboxes and Deployments.
- A Sandbox can expose a Preview and can be saved as a Snapshot.
- Publishing source produces a Release and a candidate Version.
- A Deployment owns multiple Versions but has one active Version at a time.
- A Domain routes to a Deployment, which serves its active Version.
- A dynamic Version can run on one or more Runtime Instances.
- An App Engine Host can run multiple isolated deployments for one Workspace.
- An on-premises server can connect through OpenComputers and become an OpenComputer.
- An OpenComputer can also run at a hosting provider; the connection model does not define its physical location.
- An Agent Run operates against an explicitly selected resource and Organization context.
Example: from idea to production
Developer: “I changed the app in my Sandbox and the Preview looks right. Is production updated?”
MIOSA expert: “No. The Preview shows mutable Sandbox state. Publish it to create an immutable Release and candidate Version.”
Developer: “Does publishing change the customer URL?”
MIOSA expert: “No. Promote the verified Version when you are ready. The Deployment and Domain stay stable while traffic moves to that Version.”
Developer: “What if the new Version is unhealthy?”
MIOSA expert: “Keep it inactive, or roll back by promoting an earlier ready Version. Never repair a Release by editing it in place.”