# The Deployment System

> Initiative QL-04. The Apogee Blockchain-Native Deployment System, a portal and toolchain that take an application from source to a running blockchain-native environment.

QL-04 Apogee Blockchain-Native Deployment System Status: active development

Version 1.0.0 gives a builder a repository, its tools and this manual. Everything between a proved guest and a live application, from keys and ceremonies to verifier contracts, bridges and operations, is still the builder's to assemble. The **Apogee Blockchain-Native Deployment System** is the second half of the leap: a portal and a toolchain that turn a guest program into a running blockchain-native environment, and keep it running.

## The modules

- **One place for every deployment resource**: Programs and their identities, heights and parameters, verifying keys, decider keys and their ceremonies, verifier contracts and the networks they live on, organized per application and per release.

- **Canonical on-chain contracts**: Reusable templates for what every application rebuilds today: a state-root registry driven by proofs, deposit and withdrawal bridges, upgrade paths that move from one program identity to the next.

- **An application's vital signs**: Proofs produced and settled, cycles per request, proving latency and cost, shard and family profiles, gas spent on verification, and the history of the application's state roots.

- **A door for your own AI**: An interface through which a developer's local AI agent can inspect an application, query its telemetry, propose and run changes through the deployment pipeline, and read every result back, under the developer's control.

- **Applications that start from a working shape**: Guest projects outside the repository, with the profiles, linker settings and vendored crates already right, and the AI Companion already in place.

- **Ceremonies as a service, not a chore**: Coordination of the decider key's phase-2 contributions, each verifiable against the circuit and the ceremony file, so that a deployment's key has the honest contributors its soundness needs.

## Why a system, and not more tools

The thesis behind Apogee is one optimized environment per economic application. That multiplies the number of environments, and with it the operational surface: every one has its program, its keys, its ceremony, its contracts and its metrics. An approach that asks each team to assemble that surface by hand does not scale to the many environments the thesis needs. The Deployment System makes each one routine, so the hard part of launching a blockchain-native application is the application.

The Gateway follows from the same reasoning. Builders already work alongside AI models, and the [AI Companion](https://apogee.gweb3networks.com/docs/launch/ai-companion) briefs those models on writing guests. The Gateway gives them, under the developer's control, a way to act on what they write: deploy, observe, and iterate.

Back to the [mission brief](https://apogee.gweb3networks.com/docs/quantum-leap).