Managed deployment

Managed deployment publishes a generated application onto modelARch-operated Fly.io infrastructure. It is distinct from the ephemeral preview service: a published application can hold customer data and is never cleaned up automatically.

Current topology

Each published application receives:

• one application machine;
• one durable volume mounted for database data;
• an immutable per-revision image;
• a stable subdomain under app.modelarch.io;
• TLS through the managed wildcard certificate;
• deployment state recorded by modelARch and runtime state recorded by Fly.io.

The runtime image contains the application stack needed by the currently supported managed target. Application and preview infrastructure use separate host apps, tokens, certificates, and cleanup policies.

Deployment flow

1. Resolve an acquired generation and release plan.
2. Build an immutable application image.
3. Create or reuse the app’s durable volume.
4. Start the candidate machine with its declared configuration.
5. Run database startup and migration checks.
6. Wait for application readiness.
7. Route the stable application address to the candidate.
8. Record deployment result in the release ledger.

An error before readiness leaves the prior deployment record and data volume intact.

Current schema-evolution limit

Managed redeploy currently refuses a revision whose physical schema differs from the deployed revision. The generator can materialize a forward migration chain, but the managed promotion path does not yet execute that chain end to end. Refusal is deliberate: running new code against an unchanged live schema would risk customer-facing failures.

Initial deployment and compatible same-schema redeploys remain the current managed contract. Use an owned delivery channel for schema-changing releases until managed forward evolution is enabled and verified.

Backups and restore

Managed apps use daily Fly volume snapshots with configured retention. The product can list snapshots, request an on-demand snapshot, and restore by creating a new volume from a selected snapshot.

Two safety properties matter:

• destructive app removal waits until the requested snapshot is actually usable;
• restore keeps the replaced volume so a mistaken recovery choice does not destroy the prior state.

Volume snapshots restore a whole volume. They are not a substitute for logical, table-level exports.

Reconciliation

modelARch’s database records ownership and intended deployment state; Fly records what is actually running. Startup reconciliation compares them and reports divergence. It does not delete resources automatically.

This is especially important for published data: an orphaned preview is waste, but an apparently orphaned volume may be a customer’s only durable copy.

Operational boundaries

Managed deployment does not mean the Evolutionary Model contains live data or secrets. The deployment service operates releases, machines, routing, and volumes; model revisions continue to own product intent.

See Configuration and secrets, Releases and rollback, and Troubleshooting.