# Build on MIOSA Understand the building blocks. Run code in a sandbox, inspect a preview, and publish a version you can return to. ## Build on MIOSA [Quickstart](/docs/quickstart) · [API reference](/docs/api) ## The building blocks - [Sandbox to deployment](/docs/quickstart): A complete first workflow: create an environment, write an application, inspect it, and publish a version with a clear rollback path. - [Install the CLI or SDK](/docs/installation): Pick the interface that matches your workflow, configure credentials once, and verify the connection before making changes. - [The product model](/docs/product-model): A small resource vocabulary makes the system easier to understand. Give every resource a clear owner, lifetime and purpose. - [Projects](/docs/projects): Group the resources for one application without hiding who owns them. - [Services](/docs/services): Choose a web process, a worker or a scheduled job according to the work it does. - [Deployments and rollback](/docs/deployments): Publish a specific version, verify that version, and retain a clear route to the last known good release. - [Sandboxes](/docs/sandboxes): An isolated place for code and tools. Create it for a task, keep the state you need, and stop it when the task is finished. - [Snapshots and persistence](/docs/snapshots): Save the state you intend to recover, understand what the snapshot includes, and verify the restored instance. - [Computers](/docs/computers): Use a desktop when the task depends on visual applications, browser state or direct interaction. - [Data and bindings](/docs/data): Choose storage by the shape and lifetime of the data, then connect it explicitly to the application. - [Domains and previews](/docs/networking): Understand what a temporary preview exposes and what a stable domain promises to its users. - [Models, harnesses and tools](/docs/agents): An agent is easier to understand when its reasoning, execution loop and machine are separate concepts. - [CLI workflow](/docs/cli): Use explicit resources and structured output to make terminal workflows readable and repeatable. - [SDKs](/docs/sdks): Use the same resource model from application code. Pick a language and keep identifiers and failures explicit. - [MCP](/docs/mcp): Expose defined capabilities to an agent client without making the client guess how to call your service. - [API fundamentals](/docs/api-reference): Read the resource contract, send an explicit request, and inspect the exact response before taking the next action. - [Permissions and secrets](/docs/security): Make the ownership boundary visible, keep credentials out of browser bundles, and preserve useful failures. - [Make this documentation your own](/docs/customization): Replace the content, adjust the tokens, and connect only the services you need. The reading experience works on its own. - [Changelog](/docs/changelog): Changes to this local documentation reconstruction. ## Learn by doing [Learn and earn](/docs/learn/earn) · [Glossary](/docs/glossary) · [Interactive labs](/docs/learn/games) ## Machine-readable documentation [Index](/llms.txt) · [Full context](/llms-full.txt) --- # Sandbox to deployment A complete first workflow: create an environment, write an application, inspect it, and publish a version with a clear rollback path. ## Before you start For a real cloud workflow, install your provider’s CLI or SDK and configure an account with the permissions you need. The following examples describe the MIOSA workflow; they do not execute a production request from this page. For a working local request, use the [API explorer](/docs/api). For a visual simulation, use the [sandbox lab](/docs/learn/labs/sandbox). ## 1. Create a sandbox Name the workspace explicitly. Treat the returned resource identifier as the identity of your sandbox and use it for subsequent operations. ## 2. Run your application Install dependencies inside the sandbox, then start the application on a known port. Read its output before assuming it is ready. -- node --version\nmiosa sandbox exec -- npm install'}} /> Use environment variables or a secrets binding for credentials. Do not put a production key into a browser bundle, a copied tutorial or a committed file. ## 3. Inspect the preview A successful command is one piece of evidence. Also open the application, exercise its main task, and inspect its logs. Check the candidate that you intend to publish rather than an unrelated development instance. B[Candidate version]\n B --> C[Preview and checks]\n C --> D{Verified?}\n D -->|Yes| E[Promote release]\n D -->|No| A'} /> ## 4. Publish a version Publishing should identify an immutable candidate. Verify that candidate, then promote that same identifier. Save the returned deployment address rather than constructing a URL from a guessed naming pattern. ```bash miosa app preview ./app --json miosa app verify ./app --json miosa app promote ./app --yes --json ``` ## 5. Keep a way back Record the active release and the previous known good version. When a release fails, inspect the exact failed operation. A retry, recovery and rollback solve different problems; choose the one that matches the state you can observe. Read [deployments and rollback](/docs/deployments) next, or put the sequence into practice in [Shipping](/docs/learn/labs/shipping). ## Make the example yours Change these values to see a parameterized example. The selected language stays synchronized with the rest of the tutorial. --- # Install the CLI or SDK Pick the interface that matches your workflow, configure credentials once, and verify the connection before making changes. ## Choose an interface The CLI is useful when a person or coding agent works in a terminal. An SDK is useful inside an application. MCP exposes defined capabilities to an agent through its client’s tool interface. These are reference installation examples. Check the provider’s current installation documentation before connecting a production account. ## Configure credentials Keep a production API key on the server or in the CLI environment. A browser should receive only the limited credentials that its task actually requires. ```bash miosa login ``` Run this reconstruction with npm run dev. Its local learning flows, search and sandbox API work without a MIOSA account. ## Verify the selected account Before creating resources, inspect the account, organization and workspace selected by your client. Make this step explicit in automation so a default profile does not silently choose the wrong environment. ## Use structured output Prefer structured output when a script needs to read a result. Capture the returned resource or operation identifier and pass that value to the next step. Avoid parsing a human-readable status sentence when a JSON field is available. ## Next steps Read the [CLI workflow](/docs/cli), compare [SDK examples](/docs/sdks), or follow the [quickstart](/docs/quickstart). --- # The product model A small resource vocabulary makes the system easier to understand. Give every resource a clear owner, lifetime and purpose. ## Ownership comes first An organization owns workspaces. A workspace groups resources and controls who can use them. A project can group resources for one application. These boundaries should be explicit in requests and visible in the interface. W[Workspace]\n W --> P[Project]\n P --> S[Sandbox]\n P --> D[Deployment]\n P --> B[Database]\n W --> C[Computer]'} /> ## Separate resources by lifetime | Resource | Main job | Lifetime | | --- | --- | --- | | Sandbox | Build, test and execute code | Often disposable | | Computer | Operate desktop applications | Task or session based | | Deployment | Serve a published application | Managed release | | Database or volume | Keep application state | Persistent | ## Connect with bindings A binding records how an application uses another resource. It might supply a database URL, a storage location or a scoped capability. Keeping these connections explicit makes deployment and recovery easier to inspect. ## Keep identities stable A name is useful to a person, but a returned identifier names the actual resource. Keep the identifier in operation records. Reusing a familiar display name does not mean you are operating on the same instance. ## Learn by doing [Practice the resource model](/docs/learn/labs/model), or [explore the glossary](/docs/glossary). --- # Learn MIOSA your way Read the words, try the labs, and understand what you build. Pick a path and make it your own. [Learn the words](/docs/glossary) · [Try the labs](/docs/learn/games) · [Follow the quickstart](/docs/quickstart) --- # Learn and earn Learn how the building blocks fit together. Read, practice, and track your progress across three learning paths. ## Learn the words - [Core primitives](/docs/learn/final/category/core): +$2.50 practice credits - [Organization](/docs/learn/final/category/organization): +$2.50 practice credits - [Networking and domains](/docs/learn/final/category/networking): +$2.50 practice credits - [Data](/docs/learn/final/category/data): +$2.50 practice credits - [Agents](/docs/learn/final/category/agents): +$2.50 practice credits - [Runtimes](/docs/learn/final/category/runtimes): +$2.50 practice credits - [Billing and usage](/docs/learn/final/category/billing): +$2.50 practice credits - [Platform builders](/docs/learn/final/category/builders): +$2.50 practice credits ## Learn with games - [The words](/docs/learn/labs/words): +$5 practice credits - [How MIOSA fits together](/docs/learn/labs/model): +$5 practice credits - [Your first sandbox](/docs/learn/labs/sandbox): +$7 practice credits - [Shipping](/docs/learn/labs/shipping): +$7 practice credits - [Running a fleet](/docs/learn/labs/fleet): +$8 practice credits - [Connecting things](/docs/learn/labs/connections): +$8 practice credits - [Building a product](/docs/learn/labs/product): +$10 practice credits ## Learn with videos Video lessons are not available yet. ## Local practice Progress is saved in this browser. Credits are illustrative and have no monetary value. No MIOSA account is connected. --- # Learn the words Plain-language explanations for the building blocks. Explore a category, practice the terms, then check what you know. ## Core primitives The building blocks: workspaces, sandboxes, computers and deployments. [Practice this category](/docs/glossary?category=core) ## Organization How people, workspaces and permissions fit together. [Practice this category](/docs/glossary?category=organization) ## Networking and domains Connect a running process to the people who need it. [Practice this category](/docs/glossary?category=networking) ## Data Choose what survives a restart, and where it belongs. [Practice this category](/docs/glossary?category=data) ## Agents Separate the model, the harness, the tools and the machine. [Practice this category](/docs/glossary?category=agents) ## Runtimes Understand the environment your code runs inside. [Practice this category](/docs/glossary?category=runtimes) ## Billing and usage Read resource usage and distinguish it from credit balance. [Practice this category](/docs/glossary?category=billing) ## Platform builders Build a product that gives each customer the right boundaries. [Practice this category](/docs/glossary?category=builders) --- # Learn with games Build your understanding by doing. Seven short, interactive labs take you from the vocabulary to your first product. ## The words Put the right name on each building block. [Open the lab](/docs/learn/labs/words) ## How MIOSA fits together Connect the workspace, sandbox and deployment. [Open the lab](/docs/learn/labs/model) ## Your first sandbox Create, pause, snapshot and restore a machine. [Open the lab](/docs/learn/labs/sandbox) ## Shipping Take a tested version from preview to release. [Open the lab](/docs/learn/labs/shipping) ## Running a fleet Keep useful machines running within a budget. [Open the lab](/docs/learn/labs/fleet) ## Connecting things Give each resource its correct connection. [Open the lab](/docs/learn/labs/connections) ## Building a product Keep customer boundaries intact as you ship. [Open the lab](/docs/learn/labs/product) --- # Learn with videos Short lessons for the ideas behind the platform. This track opens when the lessons are ready. ## Lessons planned - Quickstart: not available yet - Sandboxes: not available yet - Machines: not available yet - Computers: not available yet - Browser: not available yet - Agents: not available yet - Deploy: not available yet - Data: not available yet - Build: not available yet - Platforms: not available yet - Organization: not available yet - Pricing: not available yet --- # Projects Group the resources for one application without hiding who owns them. ## Give the application a home A project groups related services and resources inside a workspace. Use a name that helps the next person recognize the application, then keep its persistent identifier in deployment records. ## Model environments explicitly Development, staging and production have different jobs. Give each environment its own configuration and data bindings. A shared source repository does not require a shared production database. ## Keep the resource map readable List the web service, worker, database and storage used by the application. A person should be able to inspect that map without reconstructing it from environment-variable names. ## Start small Follow the [quickstart](/docs/quickstart), then read [services](/docs/services) and [data bindings](/docs/data). --- # Services Choose a web process, a worker or a scheduled job according to the work it does. ## Choose a service shape A web service accepts requests. A worker consumes background tasks. A scheduled job runs at defined times. Name the role before selecting the resources. | Shape | Input | Readiness evidence | | --- | --- | --- | | Web service | HTTP requests | A healthy application response | | Worker | Queue messages | A connected consumer and successful work | | Scheduled job | A schedule | A completed run with a recorded result | ## Configure before release Set the start command, environment and resource bindings deliberately. Keep secret values out of source control. Verify the application using the same configuration shape it will use when published. ## Observe behavior Logs describe individual events. Metrics describe behavior over time. Use both to understand whether a deployment is healthy, and keep the active release identifier attached to observations. ## Publish a known version Read [deployments and rollback](/docs/deployments) before promoting the first production release. --- # Deployments and rollback Publish a specific version, verify that version, and retain a clear route to the last known good release. ## Candidate, preview, release A candidate is the built version you intend to publish. A preview lets you inspect it. A release makes a verified version active. Treat these as separate states rather than three names for one button. ## Verify before promotion Check the application route, required configuration, data connections and the main user task. Save the release identifier that passed those checks. ```bash miosa app preview ./app --json miosa app verify ./app --json miosa app promote ./app --yes --json ``` ## Recover the right thing A failed operation may be recoverable without rebuilding. A broken active release may require a rollback. Inspect the current operation and release states before choosing either action. ## Practice the order The [Shipping lab](/docs/learn/labs/shipping) makes the sequence explicit. It records local practice completion after you put the steps in the right order. --- # Sandboxes An isolated place for code and tools. Create it for a task, keep the state you need, and stop it when the task is finished. ## Start with a purpose A sandbox is useful for a build, a test, a coding agent or a short-lived development environment. Choose its template, workspace and resource size for the workload you intend to run. ## Understand the lifecycle The local lab uses four visible actions: create, pause, resume and remove. Pausing keeps the simulated machine available to resume. Removing it ends that instance. A saved snapshot is a separate recovery point. | Action | What to check | | --- | --- | | Create | The returned identifier and initial state | | Execute | Exit status, stdout and stderr | | Pause | Whether work is still running and what state is retained | | Snapshot | The saved version and its resource scope | | Remove | Whether required data was stored elsewhere | ## Inspect readiness “Running” does not necessarily mean an application is ready to serve requests. Check the process, the listening port, and an application-level response. Use the platform’s readiness contract where one is available. Put data that must survive an instance into a persistent resource, or save a documented recovery point. Do not rely on a temporary filesystem by accident. ## Try the local sandbox API The [API explorer](/docs/api) can create and list example resources in a process-local store. It is intentionally isolated from real cloud infrastructure. Restarting the app clears these API examples. ## Practice Open [Your first sandbox](/docs/learn/labs/sandbox) to try the lifecycle visually, then read [snapshots and persistence](/docs/snapshots). --- # Snapshots and persistence Save the state you intend to recover, understand what the snapshot includes, and verify the restored instance. ## Decide what must survive An environment contains several kinds of state: source files, installed software, configuration, and application data. A snapshot may cover some of these while a database or external storage covers others. Read the scope before treating a snapshot as a complete backup. ## Save a recovery point Use a descriptive name and record the source resource. A useful recovery record identifies the saved version and explains when you would restore it. ## Restore and inspect After restoring, verify the files, configuration and application behavior that matter to the task. A successful restore response is not a substitute for checking the application. ## Snapshot or volume? | Need | Useful starting point | | --- | --- | | Recreate an environment at a known state | Snapshot | | Keep changing files across process restarts | Persistent volume | | Query application records | Database | | Store exported artifacts | Object storage | ## Practice recovery In the [sandbox lab](/docs/learn/labs/sandbox), create a machine, save a snapshot, remove the machine and restore it. The lab makes the distinction between an active instance and a saved state visible. --- # Computers Use a desktop when the task depends on visual applications, browser state or direct interaction. ## When a desktop helps Some tasks are naturally expressed through files and commands. Others require a visual browser, a native application or a screen that a person and agent can inspect together. Choose a computer for that second group. ## Make readiness observable A machine can be running while its desktop or application is still starting. Check the surface the task actually needs, and keep the session attached to the correct computer identifier. ## Separate viewing from control A live viewer shows what is happening. Input control changes the machine. A product should make that distinction clear, especially when a person and an agent share a session. ## Choose the smallest useful surface Use a [sandbox](/docs/sandboxes) for code execution alone. Use a computer when a desktop is part of the task. Store important output in a persistent resource before ending the session. --- # Data and bindings Choose storage by the shape and lifetime of the data, then connect it explicitly to the application. ## Match the data to the resource | Data | Starting point | | --- | --- | | Customer records and relationships | Relational database | | Files that change during a workload | Persistent volume | | Uploaded images and exported artifacts | Object storage | | A recoverable environment state | Snapshot | ## A binding is a connection The application should receive the right endpoint and credentials through configuration. Keep the binding attached to the application and environment it serves, so a staging release does not accidentally use production data. ## Separate identity from location A returned URL tells you where to connect. A resource identifier tells you what is being connected. Keep both when recording an operation. ## Check recovery assumptions Test the recovery path for the data that matters. An application rollback does not necessarily roll back database changes. Read [snapshots](/docs/snapshots) and [deployment recovery](/docs/deployments) as different responsibilities. --- # Domains and previews Understand what a temporary preview exposes and what a stable domain promises to its users. ## From a port to a preview An application listens on a port. A preview routes a browser request to that application so a person can inspect it. Check both the process and the application response before sharing a link. ## A domain is a stable entry A custom domain gives people a recognizable address. Configure its DNS and platform binding, then verify the returned public route. Do not guess a deployment address from a name. ## Access is a separate decision A reachable address does not imply that everyone should have permission to use it. Decide whether the route is public, authenticated or shared through a limited token. ## Connect the right resource The [Connections lab](/docs/learn/labs/connections) helps distinguish a domain, a database binding and a persistent volume. Each connection has a different job. --- # Models, harnesses and tools An agent is easier to understand when its reasoning, execution loop and machine are separate concepts. ## Four pieces, four responsibilities | Piece | Responsibility | | --- | --- | | Model | Generate the next response or action request | | Harness | Coordinate the execution loop | | Tool | Perform a defined action | | Machine | Provide the execution environment | ## Give actions a useful boundary A tool should expose a clear input and result. The harness should preserve failures and operation identifiers so later steps do not invent success from an incomplete response. ## Keep context grounded Give an agent the resource identifiers, files and observations relevant to the task. Separate an instruction from a document that is merely being read. ## Learn the vocabulary Open the [Agents glossary category](/docs/glossary?category=agents), or read [MCP](/docs/mcp) for a standard way to expose tools to a client. --- # CLI workflow Use explicit resources and structured output to make terminal workflows readable and repeatable. ## Inspect before changing Start by checking the active account and workspace. Inspect existing resources before creating replacements. The resource returned by a previous operation is usually more useful than a guessed name. ## Capture identifiers When a command returns a resource or operation identifier, store it for the next step. Prefer JSON output to a script that extracts values from a status sentence. ```bash miosa capabilities --json miosa app inspect ./app --json miosa app plan ./app --goal deploy --json ``` ## Read failures as state An interrupted client does not necessarily mean the server operation stopped. Inspect the recorded operation before retrying it. A retry must not silently create a second resource. ## Choose the interface Use the CLI for terminal work, the [SDKs](/docs/sdks) for application code, and [MCP](/docs/mcp) for a client that needs a tool interface. --- # Build your own dots Always-on agents that each get their own cloud computer and browser, working in the background. ## Choose the environment Always-on agents that each get their own cloud computer and browser, working in the background. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/dots) --- # Build your own Grok Bot Named agents, each with its own cloud computer, teaming up to get work done around the clock. ## Choose the environment Named agents, each with its own cloud computer, teaming up to get work done around the clock. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/grok-bot) --- # Build your own Manus A general computer-use agent: full Linux desktops with browser, files, and human handoff. ## Choose the environment A general computer-use agent: full Linux desktops with browser, files, and human handoff. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/manus) --- # Build your own Genspark A super-agent product that plans, researches, and produces finished work for your users. ## Choose the environment A super-agent product that plans, researches, and produces finished work for your users. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/genspark) --- # Run Claude Code Coding harnesses running in sandboxes, with streamed events and collected artifacts. ## Choose the environment Coding harnesses running in sandboxes, with streamed events and collected artifacts. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/claude-code) --- # Build your own Lovable A prompt-to-app builder: the agent writes the app in a sandbox and you publish it. ## Choose the environment A prompt-to-app builder: the agent writes the app in a sandbox and you publish it. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/lovable) --- # Build your own Devin An autonomous software engineer: dispatch long-running agent runs and stream their work. ## Choose the environment An autonomous software engineer: dispatch long-running agent runs and stream their work. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/devin) --- # Build your own OpenSwarm An AI desktop where every user gets a personal agent with a real computer behind it. ## Choose the environment An AI desktop where every user gets a personal agent with a real computer behind it. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/openswarm) --- # Build your own Replit Agent A cloud workspace where an agent builds, runs, and previews apps in isolated sandboxes. ## Choose the environment A cloud workspace where an agent builds, runs, and previews apps in isolated sandboxes. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/replit) --- # Build your own An agent like ChatGPT agent Build an agent that browses, clicks and fills forms in a real browser session you can watch. ## Choose the environment Build an agent that browses, clicks and fills forms in a real browser session you can watch. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/chatgpt-agent) --- # Build your own Perplexity Comet An agentic browser: navigate, extract, and act on the web with a live viewer. ## Choose the environment An agentic browser: navigate, extract, and act on the web with a live viewer. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/comet) --- # Run OpenClaw A personal agent that lives on a persistent virtual device and works while you are away. ## Choose the environment A personal agent that lives on a persistent virtual device and works while you are away. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/openclaw) --- # Run Hermes Agent An open agent that runs for businesses: many agents, each with tools and its own workspace. ## Choose the environment An open agent that runs for businesses: many agents, each with tools and its own workspace. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/hermes-agent) --- # Build your own An agent like Gemini agent Build an orchestrator that plans and delegates work to sub-agents. ## Choose the environment Build an orchestrator that plans and delegates work to sub-agents. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/gemini-agent) --- # Run Cursor agents Fleets of coding agents working in parallel on isolated machines, coordinated from one place. ## Choose the environment Fleets of coding agents working in parallel on isolated machines, coordinated from one place. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/cursor) --- # Build your own v0 Generate a UI from a prompt and publish it to a stable URL in one step. ## Choose the environment Generate a UI from a prompt and publish it to a stable URL in one step. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/v0) --- # Build your own Bolt Full-stack apps from a prompt, running on dynamic runtimes with real servers. ## Choose the environment Full-stack apps from a prompt, running on dynamic runtimes with real servers. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/bolt) --- # Build your own Windsurf An agentic IDE: run its agents against isolated sandboxes instead of a laptop. ## Choose the environment An agentic IDE: run its agents against isolated sandboxes instead of a laptop. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/windsurf) --- # Build your own GitHub Copilot agent A coding agent that takes an issue, works in a sandbox, and opens a pull request. ## Choose the environment A coding agent that takes an issue, works in a sandbox, and opens a pull request. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/github-copilot) --- # Run OpenHands An open-source software agent with a sandboxed workspace for every task. ## Choose the environment An open-source software agent with a sandboxed workspace for every task. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/openhands) --- # Build your own Emergent A full-stack app builder: prompts become running software with real infrastructure. ## Choose the environment A full-stack app builder: prompts become running software with real infrastructure. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/emergent) --- # Build your own Base44 Describe an app, get a working one: generated, previewed, and published for you. ## Choose the environment Describe an app, get a working one: generated, previewed, and published for you. Use a sandbox for isolated code and previews, or a computer for a persistent browser, desktop and human handoff. ## Run, observe, and publish 1. Choose the authenticated user and workspace. 2. Create an isolated environment and start the agent. 3. Stream events, inspect artifacts and review a preview. 4. Save a snapshot and publish a verified version. [Agent runs](/docs/agents) · [Snapshots](/docs/snapshots) · [Deployments](/docs/deployments) [Original MIOSA recipe](https://miosa.ai/docs/build/base44) --- # SDKs Use the same resource model from application code. Pick a language and keep identifiers and failures explicit. ## Install your client The installation and cloud examples are reference snippets. This documentation does not execute them or require an API key to read them. ## Create a client Keep the credential in the server environment. Create a client where the application can reuse its configuration rather than scattering keys through handlers. ## Keep the returned identity An SDK makes a request easier to express; it does not remove the need to inspect its result. Keep the resource identifier and state returned by a create operation. Use that exact identifier in later requests. ## Handle the operation you started For a long-running operation, preserve its identity and inspect its state. A timeout in the calling process is not evidence that nothing happened on the server. ## Explore the local contract The [API explorer](/docs/api) provides working requests against this reconstruction’s local example API. Its schema describes that example surface rather than claiming full compatibility with the production SDK. --- # MCP Expose defined capabilities to an agent client without making the client guess how to call your service. ## Tools describe actions An MCP server advertises capabilities with structured inputs. The client can discover these tools, request an action and read its result. This makes the integration boundary visible. ## Configuration belongs to the client A local server may communicate over standard input and output. A hosted server may use an HTTP transport. Follow the selected client’s configuration format rather than copying a configuration for a different product. ## Keep credentials scoped A server can hold a credential on behalf of a client, but that does not justify exposing every operation. Give the integration the resource and action scope the task needs. ## This project’s boundary The documentation assistant is an HTTP endpoint, not an MCP server. Craft Anything was used to inspect the reference site; it is not a runtime dependency of this documentation application. --- # API fundamentals Read the resource contract, send an explicit request, and inspect the exact response before taking the next action. ## The local API surface This project provides a small, working sandbox API for learning. It is described by its own OpenAPI document and is independent of the MIOSA production API. | Method | Path | Behavior | | --- | --- | --- | | GET | `/api/sandboxes` | List local example sandboxes | | POST | `/api/sandboxes` | Create an example sandbox | | GET | `/api/sandboxes/{id}` | Inspect one example | | DELETE | `/api/sandboxes/{id}` | Remove one example | ## Create an example ```bash curl -X POST http://localhost:5173/api/sandboxes \ -H 'Content-Type: application/json' \ -d '{"name":"hello-docs","template":"node"}' ``` The response includes an identifier, a name, a template and a state. Use the returned identifier to inspect or delete that exact example. ## Errors Malformed JSON and invalid fields return a 400 response with a concrete message. An unknown identifier returns 404. The interactive explorer shows request and response bodies so you can compare the contract with the behavior. The sample API stores records in this Node process. Restarting it resets those examples. Browser learning progress is separate and remains in localStorage. ## Explore the schema Open the [interactive reference](/docs/api) to send a request, or inspect [the OpenAPI document](/openapi.json) directly. --- # Interactive API reference Explore a working local sandbox API. Inspect its schema and try requests against this learning project. [Learn the words](/docs/glossary) · [Try the labs](/docs/learn/games) · [Follow the quickstart](/docs/quickstart) --- # Permissions and secrets Make the ownership boundary visible, keep credentials out of browser bundles, and preserve useful failures. ## Begin at the boundary A workspace, tenant or project identifies the resources an action is allowed to affect. A display name alone does not establish permission. Send the exact resource identity required by the contract. ## Put credentials in the right place Server credentials stay on the server. Browser integrations should use limited credentials intended for that surface. Do not include secrets in query strings, copied examples or source control. ## Preserve refusal A failed or refused operation is part of the system’s behavior. Show the reason and the next useful action instead of changing an error into a generic success state. ## Local project behavior Learning progress stays in the current browser. The sample sandbox API stores only synthetic resources in memory. The optional model key is read only by the server-side assistant route. No MIOSA account is connected. --- # Make this documentation your own Replace the content, adjust the tokens, and connect only the services you need. The reading experience works on its own. ## Add an article Create a `.svx` file in `src/content`. Its frontmatter supplies the title, description, slug, section and order. The content registry discovers that metadata and the article body. ```yaml --- slug: your-first-guide title: Your first guide description: A short, useful description of the task. section: Get started order: 4 --- ``` Add its slug to `src/lib/content/navigation.ts` to place it in the sidebar. The search index, Markdown output and page metadata use the content registry. ## Use interactive content Import `CodeTabs`, `Callout` or `Diagram` in an article’s script. CodeTabs accepts a record of language names and code strings. Examples share a language preference; set `sync={false}` for an independent example. ## Change the visual system `src/app.css` owns the color tokens, typography and common primitives. Component styles own their layout. Keep the light, dark and glass token sets aligned rather than adding theme conditions to every control. ## Replace learning content `src/lib/content/learning.ts` defines glossary categories, terms, lab units and sequence exercises. Browser progress references stable identifiers. Change the storage version deliberately when you replace those identities. ## Connect an assistant Without configuration, Ask OSA finds matching passages from local documentation. To connect a model, set `DOCS_AI_BASE_URL`, `DOCS_AI_KEY` and `DOCS_AI_MODEL` on the server. The base URL should expose an OpenAI-compatible `/chat/completions` endpoint. Keys never go into browser code. The response identifies whether it came from the configured model or the local document finder. If a service request fails, the panel offers a retry and keeps the question visible. ## Build and run ```bash npm install npm run check npm run build node build ``` Use the Node adapter for the API and assistant routes. A purely static export would need those endpoints moved to another service. --- # Changelog Changes to this local documentation reconstruction. ## November 9, 2026 ### Documentation foundation Added a responsive SvelteKit documentation shell, MDsveX content, shared language examples, code copying, a live table of contents and five appearance choices. ### Learning workspace Added glossary practice, category checks, seven interactive lab units and browser-local progress. Video lessons remain explicitly unavailable until real material is supplied. ### Developer surfaces Added a working example sandbox API, Scalar reference, Markdown exports and a documentation finder with an optional server-side model connection. ## What this release does not connect This is an independent local study project. It does not authenticate to MIOSA, grant account credits or operate real cloud resources.