MIOSA Glossary
Use this glossary when a product screen, API response, or guide introduces an unfamiliar MIOSA term.
Definitions describe the customer-visible product model. They intentionally leave out private infrastructure and implementation details.
Learn the flow first
The hierarchy answers who owns the resource. The publish flow answers how tested work becomes production.
I am building
Start with Project, Sandbox, Preview, Snapshot, and Artifact.
I am deploying
Start with Release, Version, Deployment, Promotion, and Rollback.
I need a desktop
Start with Computer, OpenComputer, Desktop session, and Agent Run.
I am connecting a domain
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 temporary public URL connected to a port in a running Sandbox. | 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. |
| Artifact | A file or result preserved from a build, command, evaluation, or Agent Run. | A full Release unless the publishing flow explicitly creates one. |
Computers and interactive desktops
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| Computer | A managed or connected machine that gives an agent a full interactive desktop, browser, and operating system. | 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 to MIOSA through the OpenComputers agent. | 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. |
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 behavior. | 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. |
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. |
Customer infrastructure
| Term | Plain-language definition | Do not confuse it with |
|---|---|---|
| Bring Your Own Cloud (BYOC) | Customer-owned AWS or Google Cloud worker capacity governed through MIOSA’s control plane. | OpenComputers connected from individual machines. |
| 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. |
| 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 |
|---|---|---|
| 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. |
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. |
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 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.”
Keep learning
Core concepts Understand the complete resource hierarchy and immutable production model.
Quickstart Create, preview, publish, verify, and promote an application.
Deployment domains Choose between platform URLs, deployment domains, and custom domains.
Customer infrastructure Compare MIOSA-managed compute, OpenComputers, BYOC, and hybrid placement.