Migrating from miosa-sandbox

The standalone sandbox packages are deprecated compatibility wrappers. Each one now delegates to the canonical MIOSA SDK, so the fastest migration is often to install the canonical package and change one import.

Deprecated packageCanonical replacement
@miosa/sandbox (JavaScript)@miosa/sdk
miosa-sandbox (Python)miosa
sandboxes-go (Go)github.com/Miosa-osa/miosa-go/v2

JavaScript

npm install @miosa/sdk
// Before
import { MIOSA } from '@miosa/sandbox';
const client = new MIOSA({ apiKey: process.env.MIOSA_API_KEY! });

// After
import { Miosa } from '@miosa/sdk';
const client = new Miosa({ apiKey: process.env.MIOSA_API_KEY! });

@miosa/sandbox re-exports the canonical client, so it keeps installing while you migrate, but new code should import @miosa/sdk directly. The renamed classes map as:

Old importCanonical replacement
MIOSAMiosa
SandboxClientSandboxes
ComputerClientComputers
CreateSandboxOptionsSandboxCreateParams
CreateComputerOptionsComputerCreateParams

Python

pip install miosa
# Before
from miosa_sandbox import MIOSA
with MIOSA(api_key="msk_...") as client:
    with client.sandboxes.create() as sandbox:
        print(sandbox.exec("python3 -c 'print(1 + 1)'").stdout)

# After
from miosa import Miosa
with Miosa(api_key="msk_...") as client:
    with client.sandboxes.create() as sandbox:
        print(sandbox.exec("python3 -c 'print(1 + 1)'").stdout)

MIOSA and AsyncMIOSA are preserved in the compatibility package and return the canonical miosa resource classes; the async class becomes AsyncMiosa.

Go

go get github.com/Miosa-osa/miosa-go/v2
// Before
import sandboxes "github.com/miosa-ai/sandboxes-go"
client, _ := sandboxes.New(sandboxes.Config{APIKey: os.Getenv("MIOSA_API_KEY")})

// After
import miosa "github.com/Miosa-osa/miosa-go/v2"
client := miosa.NewClient("msk_...")

Behavior differences to expect

  • One client, one surface. In the canonical SDKs, sandboxes live on the client (client.sandboxes) alongside computers, files, snapshots, and agent runs. Code that reached for a separate sandbox client now goes through the single client.
  • Ownership selectors are first-class. workspace_id, project_id, and external_user_id can be passed directly on create, and are exposed on the returned handle.
  • size and resource_contract. When no size is supplied, the compatibility packages request the canonical small contract: 2 vCPU, 4096 MiB memory, and 10240 MiB disk. The response exposes size, resource_contract, and usage() on both sync and async handles.
  • Canonical names. Use client.sandboxes with the miosa-sandbox template, client.computers with miosa-desktop, and client.dockerDeploy for the App Engine appliance. computer is the user-facing product name; miosa-desktop is the template it boots from.

Verify the migration

The compatibility packages and the canonical SDKs hit the same API, so the check is behavioral:

from miosa import Miosa

with Miosa(api_key="msk_...") as client:
    sbx = client.sandboxes.create(template_id="miosa-sandbox", size="small")
    print(sbx.state, sbx.resource_contract)
    print(sbx.exec("python3 -c 'print(1 + 1)'").stdout)   # 2
    sbx.destroy()

If that prints 2 and a small contract, the migration is complete.

See also

Was this page helpful?