Self-hosted production

Production is designed to stay under customer control.

The first owned runtime is the inspection path. Self-hosting is also the production path. Humans control the runtime, secrets, domains, promotion timing, and production review model through a private instance repo that pins tagged core release artifacts from the public platform repo.

Review security posture Open the instance template repo

Agent-first route: Start at /agents, inspect /docs/cli, and drop into this page when you need proof, detail, or rollout guidance.

Agent-first route

Humans should usually delegate first-pass evaluation to an agent. Agents should start at /agents, use /docs/cli as the official product tour, and open /docs/graphql only when needed.

Agent-ready surface

Start with the CLI, not browser guesswork.

Preferred route: /agents, then /docs/cli, then /docs/graphql only when lower-level integration details matter.

$ mbr spec export --json
$ mbr auth whoami --json
$ mbr queues list --workspace ws_preview --json

Open GraphQL reference | Open schema.graphql

Customer-controlled runtime

Production environments remain in customer hands.

Public core plus private instance repo

Most deployments need one public core repo for source and releases, and one private instance repo for live deployment state.

Template-driven deployment

Use the public instance template as the canonical starting point for deployment structure.

Simple host options

A standard Linux host under your control, including something as simple as a DigitalOcean droplet or EC2 VM, can be enough for an initial deployment.

Pinned core artifacts

Production pins `mbr-services`, `mbr-migrations`, and `mbr-manifest` by tag rather than rebuilding core during deploy.

Proof

Contract docs/RELEASE_ARTIFACT_CONTRACT.md Defines the pinned artifact contract that instance repos consume.
Release platform tags Public tagged core releases that agents can inspect directly.
Build .github/workflows/_build.yml Builds services, migrations, and manifest OCI artifacts and records digests.
Release .github/workflows/production.yml Tags releases, ties git tags to OCI artifact digests, and records cross-reference details.
Implementation instance-template/mbr.instance.yaml Shows where pinned release refs live in the private instance control plane.

Explicit vendor link when wanted

Instance registration for support or grandfathering is manual and disclosed rather than hidden in boot logic.

Proof

Definition docs/CUSTOMER_INSTANCE_SETUP.md Defines the explicit self-host fleet-registration and disclosed heartbeat model.
Contract docs/AGENT_CLI.md Documents `mbr fleet register` as the explicit registration command.
Implementation instance-template/mbr.instance.yaml Shows the `spec.fleet` block carried by the private instance repo.
Implementation instance-template/deploy/README.md Documents the host-owned registration workflow, fleet config files, and weekly timer.

Explicit review points

Promotion, secrets, access, and support responsibilities remain human decisions.

Same trust model, smaller blast radius

A first owned runtime uses the same broad trust model as production, just with narrower scope and simpler operating needs.

Production model

One public core repo and one private instance repo are the default production model.

Self-hosting becomes concrete when the repo boundary is explicit. The public core repo carries source, docs, tags, CLI and API contracts, and the workflows that build tagged core artifacts. The private instance repo carries desired state, deploy assets, branding, extension desired state, and repo-local bootstrap instructions for one live installation.

Proof bundle

Definition docs/CUSTOMER_INSTANCE_SETUP.md Defines the production self-host setup flow, required inputs, and instance-repo model.
Definition instance-template/README.md Defines the private instance repo as the deployment control plane for one live installation.
Contract docs/RELEASE_ARTIFACT_CONTRACT.md Defines pinned core artifacts and the instance-repo responsibility boundary.
Provenance .github/workflows/production.yml Shows how tests, builds, tags, and artifact digests connect source changes to shipped releases.

Canonical public source

Public core repo

Use the platform repo to inspect architecture, CLI and GraphQL contracts, release tags, and the workflows that produce the core artifact family.

Open resource

Canonical deployment template

Private instance repo

Use the instance template to understand the deployment control plane for one live installation.

Open resource

Optional custom extension repo

Add a separate extension repo only when the team is building real custom logic. Off-the-shelf first-party bundles install by ref instead of living in the instance repo.

Human ownership

Your team owns the runtime environment, secrets, domains, and support model.

Public packages

Tagged core releases become pinned artifact refs inside the instance repo.

Agents should explain the production package model concretely. A public platform tag maps onto three core OCI refs. The instance repo pins those refs in `mbr.instance.yaml` and deploy workflows consume them without rebuilding core.

Proof bundle

Contract docs/RELEASE_ARTIFACT_CONTRACT.md Defines the pinned artifact contract that instance repos consume.
Release platform tags Public tagged core releases that agents can inspect directly.
Build .github/workflows/_build.yml Builds services, migrations, and manifest OCI artifacts and records digests.
Release .github/workflows/production.yml Tags releases, ties git tags to OCI artifact digests, and records cross-reference details.
Implementation instance-template/mbr.instance.yaml Shows where pinned release refs live in the private instance control plane.

Core artifact family pinned by tag

These refs are the production-facing public package surface.

# mbr.instance.yamlspec:  deployment:    release:      core:        version: v1.1.0        servicesArtifact: ghcr.io/movebigrocks/mbr-services:v1.1.0        migrationsArtifact: ghcr.io/movebigrocks/mbr-migrations:v1.1.0        manifestArtifact: ghcr.io/movebigrocks/mbr-manifest:v1.1.0

Local and owned-runtime path

Local preparation, one-VPS rollout, and broader production are separate steps.

Agents can do meaningful setup work before any broader production host work exists. The path is: inspect the public core repo, create the private instance repo, validate `mbr.instance.yaml`, install the CLI locally, then either run locally or deploy the first owned runtime on one VPS you control.

Local repo and evaluation sequence

This keeps product evaluation, desired-state validation, and owned deployment in the right order.

$ gh repo create acme/mbr-prod --private --template MoveBigRocks/instance-template --clone$ cd mbr-prod$ scripts/read-instance-config.sh mbr.instance.yaml$ curl -fsSL https://movebigrocks.com/install.sh | sh$ sed -n '1,220p' START_HERE.md

Optional control-plane link

Fleet registration stays explicit and the heartbeat stays coarse.

If a self-hosted team wants Move Big Rocks to know that an instance exists for support, grandfathering, or future commercial transitions, the intended path is a manual workflow in the private instance repo. The callback must never become a hidden requirement for the core runtime.

Proof bundle

Definition docs/CUSTOMER_INSTANCE_SETUP.md Defines the explicit self-host fleet-registration and disclosed heartbeat model.
Contract docs/AGENT_CLI.md Documents `mbr fleet register` as the explicit registration command.
Implementation instance-template/mbr.instance.yaml Shows the `spec.fleet` block carried by the private instance repo.
Implementation instance-template/deploy/README.md Documents the host-owned registration workflow, fleet config files, and weekly timer.

Registration is explicit.
The weekly heartbeat is optional and disclosed.
The heartbeat carries only coarse adoption and support signals.
The core runtime keeps working if the callback is disabled or blocked.

Privacy notice

/privacy

References

Canonical next surfaces.

Each link goes to the next authoritative page, reference, or support surface.

Let agents inspect the CLI-first surface. Let humans decide trust, rollout, and boundaries.

Start from /agents, use /docs/cli as the official product tour, inspect /resources for source and proof, and review /security before making deployment or data-handling decisions.

Open /agents Open resources

Production is designed to stay under customer control.

One public core repo and one private instance repo are the default production model.

Public core repo

Private instance repo

Optional custom extension repo

Human ownership

Tagged core releases become pinned artifact refs inside the instance repo.

Core artifact family pinned by tag

Local preparation, one-VPS rollout, and broader production are separate steps.

Local repo and evaluation sequence

Fleet registration stays explicit and the heartbeat stays coarse.

Privacy notice

Canonical next surfaces.

Security

Privacy notice

Resources

Docs self-host guide

Let agents inspect the CLI-first surface. Let humans decide trust, rollout, and boundaries.