Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 13 · LESSON 13.3

Manage configuration as a versioned resource

Publish configuration with known precedence and apply timing.

Lesson 76 of 86 · FabrCore 2.0

Overview

A Cloud Server serves a versioned effective document to each Host. Separate the document's publication, the Host's download and each setting consumer's application timing.

The Host consumes an envelope, not an editor form

GET /fabrcore-cloud/v1/configuration returns the effective model configuration plus optional settings and blueprints. A Cloud Server may merge base/environment documents, but layering policy is server-owned; the Host receives the final result. The version/ETag must change whenever that result changes. If unchanged, 304 lets the Host retain its current snapshot.

Published and applied are different states

Cloud settings sit above appsettings files but below environment variables and command-line overrides. Some consumers can apply changes live; startup-only settings require restart. The server cannot make a consumer reload simply by saving a value. Insights-style history/rollback can publish an earlier body under a new version; a custom implementation should define its own equally clear version policy.

Publish an effective configuration version

  1. Construct the effective envelope for the target cluster/environment. The example below shows a supported settings map; retain the required model configuration for your enabled features.
  2. Publish through your Cloud Server's own authenticated storage/editor and change configurationVersion/ETag when the effective resource changes.
  3. Inspect the Host-reported version and apply/restart state. Roll back by publishing a compatible prior effective body as a new version, rather than pretending a version string resets the running process.
Effective response · Cloud Server to Host 
{
  "schemaVersion": 1,
  "configurationVersion": "ops-development-2",
  "configuration": {
    "modelConfigurations": [
      {
        "name": "default",
        "provider": "OpenAI",
        "model": "<your-model>",
        "apiKeyAlias": "model-key"
      }
    ],
    "apiKeys": [
      {
        "alias": "model-key",
        "value": "<resolved-secret>"
      }
    ]
  },
  "settings": {
    "FabrCore:Host:WebSocketPath": "/ws"
  }
}
Conditional pull · unchanged resource returns HTTP 304 
GET /fabrcore-cloud/v1/configuration
Authorization: Bearer <cluster-key>
X-FabrCore-Cluster-Id: operations-desk
X-FabrCore-Environment: Development
If-None-Match: "ops-development-2"
Inspect the Host’s effective/apply status 
GET /fabrcoreapi/admin/v1/settings/catalog
Authorization: Bearer <administration-credential>

Compare served, effective and applied values

  1. Publish a harmless supported setting/model change with a new effective version. Request the configuration endpoint using the Host's cluster/environment and inspect the returned envelope/ETag.
  2. Observe the Host's next reported version and apply status. If a local environment override wins or the consumer needs restart, explain that state rather than displaying “applied” from the publish response.
  3. Request again with the current If-None-Match. Expect 304 when unchanged. Change the effective document and verify the next request receives 200 with a new version.

This verifies configuration delivery and its application boundary. The open Host-facing protocol does not prescribe a universal POST /publish API for every Cloud Server editor.

If the result is different

Publishing never restarts an instance automatically. A persisted new value is not evidence that a singleton/startup consumer has reloaded it.

Go deeper

Explore the related documentation.