Delivery channels

Delivery is an ownership decision. modelARch can hand you portable artifacts, publish them into your source-control workflow, or operate a managed application. The model revision and generation evidence should remain identifiable in every channel.

Channel comparison

Channel	Best for	modelARch owns	You own
ZIP export	Inspection, portability, custom pipelines	Generation until download	Source, deployment, runtime, data
GitHub handoff	Team review and existing CI/CD	Generated commit/branch or PR handoff	Repository policy, merge, deployment
Managed deployment	Fast operated delivery	Build, machine, routing, volume, release state	Product decisions and app-level use

ZIP export

The export is the clearest anti-lock-in boundary. It should contain the generated application plus portable model/design summaries and evolution metadata relevant to the target.

After export, modelARch does not observe manual changes or operate the destination. Preserve the evolution bundle if you plan to generate the next revision through modelARch.

GitHub handoff

Connect the modelARch GitHub App, select an authorized repository and branch strategy, then publish the generated result. Depending on repository state, the handoff can create or update a branch and open a pull request.

Review generated changes like any other supply-chain artifact:

• verify the model and generator identifiers;
• inspect dependency and migration changes;
• run repository CI;
• do not mix unrelated manual edits into managed paths;
• keep extension-owned paths outside overwrite rules.

Publishing source does not deploy it unless your repository workflow does so.

Managed deployment

Managed deployment builds a candidate, attaches durable storage, starts it in isolation, verifies readiness, and exposes it under a managed application address. The release ledger records the fly delivery channel and current deployment state.

Managed customer applications and ephemeral previews use separate infrastructure and lifecycle rules. Published data is never subject to preview cleanup.

Choose deliberately

Use ZIP or GitHub when you need:

• a custom cloud or network boundary;
• an existing platform engineering workflow;
• source review before every delivery;
• unsupported runtime topology;
• full operational ownership.

Use managed deployment when the supported topology fits and the speed of an integrated release is more valuable than custom infrastructure.

Common contract

Whichever channel you choose, preserve:

• revision and generator provenance;
• configuration requirements without values;
• schema evolution history;
• artifact integrity;
• the explicit boundary between managed output and user extensions.

Continue with Managed deployment or Generated code and extensions.