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.1

Understand the cloud boundary

Separate the running application from its optional cloud control service.

Lesson 74 of 86 · FabrCore 2.0

Overview

The FabrCore Host runs agents. A cloud server distributes configuration and relays administration. A user-facing client owns chat and interactive consent. Insights is Vulcan365's implementation of the cloud/operations experience; the open protocol supports your own implementation.

The Host runs work; the Cloud Server manages it

The Host executes agents and exposes application APIs. A Cloud Server returns effective configuration, records heartbeats and can relay authenticated administration. Clients still send user chat through their application/Host endpoint. Vulcan365 Insights is one Cloud Server implementation, not a required second runtime inside every lesson.

There are two open protocol paths

Configuration v1 uses Host-initiated pulls plus heartbeats. Remote administration v2 uses an outbound connection to carry privileged requests back to the Host. That connection is separate from the user WebSocket delivery stream. A company can implement the Cloud Server contract without adopting a particular operator UI; its configuration-publishing storage/editor is its own design.

Map application and management traffic

  1. Draw configuration v1 pulls, heartbeats, outbound administration v2 and application WebSocket traffic separately.
  2. Choose direct Host administration or an outbound cloud connection according to network constraints. Keep the app usable without Insights.
  3. Identify which secrets and identity proofs remain on the Host/client and which metadata the cloud can retain.
Separate protocol paths 
Application client -> Host HTTPS/WebSocket -> agent
Host -> Cloud Server configuration v1 pull and heartbeat
Host -> Cloud Server outbound administration v2 connect
Cloud operator -> authorized command -> Host administration API

Identify each request's destination

  1. Label a diagram with client → Host for chat, Host → Cloud Server for configuration/heartbeat, and the outbound administration relay for operator actions.
  2. Disconnect the Cloud Server in a development test and inspect the configured offline/startup policy. Distinguish a configuration refresh failure from a user chat transport failure.
  3. Record which endpoint and credential each arrow uses. An ordinary chat client must not need the cluster's administration credential.

The diagram explains which service is unavailable when something fails. Offline behavior depends on the Host's configured cache/startup policy; it should not be inferred from the console's appearance.

If the result is different

A cloud console is not automatically the user's consent client. Remote administration access is a privileged boundary, not ordinary agent messaging.

Go deeper

Explore the related documentation.