Build a Lovable-style app

What you’re building: a prompt-to-app builder. A user describes an app, an agent writes it into a sandbox, the app previews live, and one click publishes it.

Primitives you’ll use: Organization, Sandboxes, Agents, Deployments, Custom domains

What you’re building

The shape is the one Lovable popularized: a chat box on the left, a live app on the right. The agent never touches the user’s machine. It writes files into a per-project sandbox that already has Node and pnpm, runs the dev server, and streams its work to your UI. When the user is happy, the same workspace publishes to an immutable deployment behind a stable URL.

MIOSA gives you the whole backend for that loop: the sandbox, the file API, the preview, and the deploy. Your product supplies the model, the UI, and the billing.

The end-to-end version of this loop, with snapshots and forked experiments, is in Agent builds an app.

What you need on MIOSA

Architecture

Step 1: Create an account and an API key

Install the CLI, sign in, and mint a key for your product. The secret is printed once; store it as an environment variable, never in code.

npm i -g @miosa/cli
miosa login
miosa whoami
miosa api-key create prompt-app-key --preset agent     # prints the secret once
export MIOSA_API_KEY="msk_u_..."

Both SDKs read MIOSA_API_KEY from the environment, so a server or a worker needs nothing else. See API keys for scopes and how to create keys in the console.

Step 2: Create the resources

Reuse a project’s sandbox on later turns with client.sandboxes.getOrCreate({ name }) instead of creating a new one each time.

Step 3: Wire the agent loop

Ask the model for a file set, then write it in one call and run the build.

sandbox.prompt runs an agent against the workspace; sandbox.exec.stream gives you command output as it happens. Wire both into your event stream so the user watches the app being built.

Step 4: Preview

A Preview is a throwaway public URL for a port inside the machine. Start the app as a background process so it survives the CLI disconnecting, then expose its port.

Open the exact Preview URL MIOSA returns.

Step 5: Deploy

Publish the machine to an immutable Deployment. Give it the source machine, the path the app lives at inside it, and the command that serves it.

Publishing the same deployment name again creates a new immutable version and keeps the same URL. Roll back with miosa deploy rollback prompt-app --to <version-id>, and inspect a live app with miosa deploy logs prompt-app -n 100. See Publishing and Rollback.

Step 6: Custom domain

Attach a domain your customer owns to the deployment. The platform URL keeps working while DNS propagates.

miosa deploy domain-add prompt-app app.example.com
miosa deploy domains prompt-app          # shows the DNS record and verification target
miosa deploy domain-verify prompt-app <domain-id>

Copy the exact DNS record MIOSA shows into the customer’s DNS provider; for a subdomain it is normally a CNAME. Once verified and TLS is active, MIOSA routes the domain to the deployment’s active version. In code, read the URL from the publish response instead of building it: the SDK method is miosa.deployments.domains.add(deploymentId, { domain }) (TypeScript) or miosa.deployments.domains(deployment_id).add(domain=...) (Python). See Domains.

Costs and limits

Everything bills while it runs: machines (sandboxes and computers) by the second, managed databases while running, and deployments when they serve. Pausing a machine stops compute billing but keeps disk. Set an --idle-timeout or a --ttl so a forgotten machine cannot run forever, and cap spend with rate limits and per-workspace quotas.

• Pricing - plans, the published rate card, and the free Developer grant.
• Sizing and limits - machine sizes and what each costs to run.
• Timeouts and auto-stop - --ttl, --idle-timeout, and pause/resume.

Next steps