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 ephemeral. Runtime instances are ephemeral. Data is not.

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 injects different credentials based on the environment the runtime instance boots into:

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

You ship one environment variable name; MIOSA resolves the right value. See Environments.

Quick example

How data services attach

How it fits together

Project
  ├── Sandbox (ephemeral compute)
  │     └── DATABASE_URL injected at boot ──────────────────┐
  │                                                          ▼
  └── Data Services (durable)                         Managed Postgres
        ├── Postgres  ←─────────────────────────────── same DB, always
        ├── Storage   ←── STORAGE_BUCKET env var
        ├── Redis     ←── REDIS_URL env var
        └── Auth      ←── AUTH_URL + AUTH_JWT_SECRET env vars

Your application code is unaware of the infrastructure. It reads standard environment variables, opens connections, and runs. MIOSA operates everything underneath.

Next