Docs
On this page

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.

I am building
I am deploying
I need a desktop
I am connecting a domain

Ownership and organization

TermPlain-language definitionDo not confuse it with
UserA person or service identity that signs in to MIOSA.An Organization or customer account.
OrganizationThe top-level customer boundary for members, plans, billing, domains, and policy.A User’s login.
MemberA User with a role inside one Organization.A standalone User who has no access to that Organization.
WorkspaceAn isolated operating boundary for a team, customer, or line of business inside an Organization.A Project or a local source folder.
ProjectThe container that groups development and production resources for one product or application.A single Sandbox or Deployment.
RoleA named set of permissions granted to a Member.An API key or temporary approval.
API keyA secret credential used by server-side software, automation, SDKs, or the CLI.A browser-safe token or User password.

Building and development

TermPlain-language definitionDo not confuse it with
SandboxA mutable, isolated development environment where code, dependencies, commands, and tests can change.A production Deployment.
PreviewA URL connected to a port in a running Sandbox, with access controlled by its preview or sharing configuration.A stable production URL.
SnapshotA saved point-in-time copy of Sandbox state that can be restored or forked.An immutable production Release.
TemplateA reusable starting configuration for creating a Sandbox.A Snapshot of one customer’s live work.
ExecA command executed inside a Sandbox or another supported compute resource.A long-running production Runtime Instance.
JobOne 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.
ArtifactA 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

TermPlain-language definitionDo not confuse it with
ComputerA compute resource used for machine-level work; desktop access depends on the resource and its advertised capabilities.A code-focused Sandbox.
Desktop sessionThe interactive connection used to view and control a Computer.The Computer itself, which can outlive one session.
OpenComputerA 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 ComputerA Computer whose underlying capacity and lifecycle are operated by MIOSA.An OpenComputer owned by the customer.
Warm capacityCompatible compute kept ready so a new Computer or Sandbox can start faster.A guarantee that every requested size is immediately available.
HeartbeatA periodic message from a connected host indicating that its agent is communicating with MIOSA.Proof that an application, desktop, or specific command is healthy.
ReadinessEvidence 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

TermPlain-language definitionDo not confuse it with
PublishThe operation that freezes selected source and creates an immutable production candidate.Promote, which changes what receives production traffic.
BuilderThe isolated job that converts selected source into an immutable Release.A Sandbox or production Runtime Instance.
ReleaseThe immutable application artifact produced by a successful publish operation.A Version, which combines a Release with deployment configuration.
VersionA candidate that connects one Deployment to one Release and its required configuration.The Deployment’s stable identity.
DeploymentThe durable production identity that owns versions, routes, configuration, and data bindings.A single running container or Version.
PromotionThe controlled change that makes an exact verified Version active for a Deployment.Publishing or rebuilding the application.
RollbackPromotion 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 InstanceA running copy of a dynamic Release serving one Version.The Deployment, which can continue across many instances and versions.
App Engine HostAn always-on host that can run multiple workspace-scoped application deployments as isolated containers.A Deployment or customer-facing application URL.
Desired stateThe configuration MIOSA is expected to maintain for a resource.The resource’s current observed condition.
ReconciliationThe 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

TermPlain-language definitionDo not confuse it with
DomainA hostname that routes requests to a MIOSA resource.The Deployment or application behind it.
Preview domainA branded parent domain used to create temporary Sandbox Preview hostnames.A production Deployment domain.
Deployment domainAn Organization-controlled parent domain used to create stable hostnames for deployments.One specific application’s Custom domain.
Custom domainA specific customer-owned hostname attached directly to one Deployment.A parent domain used to generate many hostnames.
Platform URLA MIOSA-provided hostname available without customer DNS configuration.A customer-owned branded hostname.
DNS verificationThe check that proves the required public DNS record points to the expected MIOSA routing target.TLS certificate issuance, which follows successful routing verification.
TLS certificateThe certificate that enables trusted HTTPS for a verified hostname.Ownership of the domain registration.
RoutingThe 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

TermPlain-language definitionDo not confuse it with
On-premisesInfrastructure 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 serverA 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.
OpenComputersThe 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.
HostThe 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 infrastructureCompute 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 poolA set of compatible hosts eligible to run a defined class of workloads under placement policy.Any collection of registered machines regardless of capability.
Hybrid infrastructureA product using more than one infrastructure location, with targets selected according to policy and capability.Automatic migration or cloud overflow for every workload.
Data planeThe resources where workload execution and application data processing take place.The control plane that authorizes and orchestrates the work.
CapabilityAn 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 regionAn approved worker region operating inside a customer’s cloud account or project.A MIOSA-managed region.
PlacementThe decision that selects where an eligible workload may run.Publishing the workload.
Control planeThe MIOSA service that records desired state, policy, scheduling, and lifecycle decisions.The customer-owned machines where workloads execute.
Shared responsibilityThe 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

TermPlain-language definitionDo not confuse it with
Agent RunOne tracked execution of an AI agent or command runner against a selected resource.The persistent agent configuration.
Agent Run GroupA collection of related Agent Runs coordinated as one larger operation.One Agent Run with multiple log events.
Runtime ProfileA reusable definition of the runner, tools, model settings, and execution policy for Agent Runs.A Sandbox Template.
ApprovalAn explicit authorization required before a constrained operation may continue.A permanent role or unrestricted permission.
MCPThe 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.
WebhookAn outbound HTTP notification sent when a subscribed event occurs.A live event stream or polling request.
EvidenceA recorded result that proves an operation reached its required state.A request being accepted or queued.

Data, configuration, and security

TermPlain-language definitionDo not confuse it with
AuthenticationProving which identity or credential is making a request.Authorization to access a particular resource or perform an operation.
AuthorizationDeciding whether the authenticated caller may perform an operation within the requested scope.A successful login by itself.
Host keyThe 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 fingerprintThe 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.
IsolationThe 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 residencyThe locations where data is stored or processed across a workflow, including outputs, artifacts, and model requests.The location where one command executes.
Environment variableA named configuration value supplied to a build or runtime process.A secret by default.
SecretA protected sensitive value whose plaintext access is restricted and audited.Ordinary application configuration.
BindingA durable connection between an application resource and a database, volume, secret, storage bucket, or service.Copying the attached data into a Release.
VolumeDurable filesystem storage that can remain available across compatible runtime replacements.The immutable application artifact.
Managed databaseA database resource whose lifecycle is managed through MIOSA.A database bundled inside an application container.
Object storageDurable bucket-based storage for files and application objects.A Sandbox filesystem or attached Volume.
Network policyRules 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

TermPlain-language definitionDo not confuse it with
CreditA 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.
UsageMetered consumption attributed to an Organization, Workspace, resource, or workload.An invoice or payment transaction.
QuotaA configured limit on resource count, capacity, spend, or operation rate.Current usage.
Spend capA billing control that limits eligible consumption over a defined period or scope.A guarantee that running resources stop instantly in every failure mode.
PlanThe 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.”

Keep learning

Was this helpful?