MIOSA Data services give your sandboxes and production runtime instances access to persistent storage without any external account setup. When you attach a data service to a project, MIOSA provisions the resource and injects its credentials at boot - your code reads process.env.DATABASE_URL and connects. That is the entire integration.

Phase status

Mental model

Each service fills a different role. Pick the right one for your data shape:

Data persists past your VMs

Sandboxes are persistent by default and can be paused, resumed, snapshotted, or destroyed. Deployment runtime instances are replaceable. Managed data has an independent lifecycle and is not deleted when either compute surface is replaced.

Destroying a sandbox removes the VM - the connected Postgres database is untouched. Publishing a new version does not migrate your schema. Rolling back a deployment does not roll back your database. Data services are managed independently of the compute that connects to them.

This is intentional. It is also why production stays available during deploys: the new version connects to the same database the old version was using.

How credentials are injected

MIOSA can bind different database credentials to different deployment environments:

production runtime  →  DATABASE_URL = postgres://prod-db...
staging runtime     →  DATABASE_URL = postgres://staging-db...

You ship one environment variable name and MIOSA resolves the binding for that environment. Environment isolation must be configured explicitly. Until separate development and production databases are attached, a sandbox may share the production database. See Environments.

Quick example

How data services attach

How it fits together

Project
  ├── Sandbox (persistent-by-default development compute)
  │     └── Env vars injected at boot ─────────────────────┐
  │                                                         ▼
  └── Data Services (durable)                        MIOSA Data Plane
        ├── Postgres  ←── DATABASE_URL
        ├── MySQL     ←── DATABASE_URL
        ├── Redis     ←── REDIS_URL
        ├── Qdrant    ←── QDRANT_URL
        ├── Storage   ←── STORAGE_BUCKET + STORAGE_ENDPOINT + keys
        ├── Auth      ←── AUTH_URL + AUTH_JWT_SECRET (opt-in)
        └── Volumes   ←── mount path configured per service

Your application code reads standard environment variables and opens normal client connections. The application remains responsible for schema migrations, backward compatibility, and safe handling of destructive operations.

Managed database lifecycle

Managed databases expose explicit lifecycle and recovery operations:

create -> provisioning -> running <-> stopped
                              -> restarting -> running
                              -> error

The API supports start, stop, restart, wake, resize, branch, replica creation, backup, restore, move, credentials, logs, and metrics. The current CLI exposes the common create, inspect, lifecycle, connect, backup, restore, logs, and metrics operations. See Databases API for the exact endpoints.

Next