Hosting — administer the installations you operate

An organisation that runs more than one MeshWeaver installation needs to know, at any moment, what each one is, what it actually runs and whether it is healthy — and it needs to change an installation's configuration without anyone editing servers by hand. Hosting is the package for that. It is meant for the operators and administrators of a set of installations, not for their end users.

Key concepts

• A deployment is a record. Every installation you operate is an ordinary mesh node: its host, namespace, database and update policy. Records are designed to be version-controlled through GitSync, so the history of every change is the history of the record.
• Records, not secrets. A deployment record carries identifiers and topology only. Where a secret is needed, the record names it in the organisation's secret store; it never holds the value.
• Recorded versus observed. What a record says an installation should be and what the installation is actually doing are kept apart. Observations — replicas, restarts, the version actually running, health — are sampled on a schedule, and every reading carries how often it is refreshed and when it stops being current, so a stale reading is shown as history rather than as the present.
• Governed changes. Configuration is changed by editing the record in an app and then applying it through a governed reconcile, so a change is reviewed, recorded and carried out by the platform rather than by a person on a server.

What ships

• Fleet Console — every installation on one page: its recorded state, the version it is really running, sampled health together with the age of the sample, and links to its logs, with the installations that need attention first. It also holds the record catalogue and the request form for a new installation. It reports; it does not command.
• Configuration apps — each binds directly to a deployment's record and applies through a governed reconcile:
  • Models — an installation's AI providers, model slots, tiers and processing-region requirement;
  • Sign-in — the identity providers an installation offers;
  • Email — the installation's system mail sender and inbound mail handling;
  • Integrations — keys an installation uses to announce its own updates, write-only with a fingerprint check.
• Deployment status — the health board across all installations, compared with the latest available version.
• Logs as nodes — windows of an installation's logs landed as mesh nodes, so they are searchable by meaning and browsable per deployment.
• Skills — assistant skills to record and inspect a deployment and to keep provisioning work inside the mesh, so an assistant can help with the same tasks under your own rights.

A typical workflow

1. Record an installation as a deployment node, or request a new one from the Fleet Console.
2. Watch it on the console: the version it actually runs, its health and the age of each reading.
3. Change its configuration in the matching app — for example give it a new AI model or a new sign-in provider — and apply the change through the governed reconcile.
4. Follow the result on the status board and in its logs until the observed state matches the record.

Access

Hosting is an administration package. Its apps and records are visible only to the people your organisation entitles to them; this page and the package's cover are the only public pages.

What you get when you subscribe

Hosting is in the Enterprise tier. Getting it adds the Fleet Console, the configuration apps, the deployment status board, log windows as nodes and the operator skills described above.