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.

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 GraphQL docs

Customer-controlled runtime

Production environments remain in customer hands.

Pinned releases plus private instance repo

Most deployments need one private instance repo for live deployment state, consuming tagged core release artifacts.

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

Release MoveBigRocks packages Published core and extension OCI artifacts, pinned by tag from instance repos.
Release releases/latest.json Machine-readable manifest for the current CLI release.
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

Contract /docs/cli 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. Core capability arrives as tagged release artifacts, with the CLI and API contracts documented on this site. 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 instance-template/README.md Defines the private instance repo as the deployment control plane for one live installation.
Implementation instance-template/mbr.instance.yaml Canonical desired-state file showing pinned core artifacts and the instance-repo responsibility boundary.
Release MoveBigRocks packages Published core and extension OCI artifacts that instance repos pin by tag.

Canonical release surface

Tagged core releases

Core capability ships as the tagged artifact family. Inspect the CLI and GraphQL contracts through /docs/cli and /docs/graphql.

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

Release MoveBigRocks packages Published core and extension OCI artifacts, pinned by tag from instance repos.
Release releases/latest.json Machine-readable manifest for the current CLI release.
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

Contract /docs/cli 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.

Tagged core releases

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.