Runtime Fabric
Runtime Fabric is the control plane M3 Forge uses to turn individual gateways into stable deployment targets. Instead of treating every gateway as a one-off destination, you organize compatible gateways into fabric groups, validate that they behave the same way, and publish or execute against the group.
What Runtime Fabric Means in M3 Forge
Runtime Fabric is intentionally group-first:
| Term | Meaning in M3 Forge |
|---|---|
| Runtime Fabric | The overall managed execution layer in Studio |
| Fabric Group | A homogeneous deployment target containing one or more gateways |
| Gateway | An individual execution endpoint used for low-level connectivity and diagnostics |
Runtime Fabric
-> Fabric Group: production-east
-> Gateway: primary-us-east-1
-> Gateway: worker-us-east-2This model lets Studio keep gateway-specific tools where they still matter, while moving deployment targeting, validation, and rollout intent to the group level.
Why Runtime Fabric Exists
- Safer deployment targets by grouping gateways that should share version and capability expectations
- Cleaner rollout intent because query plans can target a fabric group instead of one machine at a time
- Better operational visibility through group health, template drift, and scheduler fan-out results
- A migration path away from gateway-only operations without breaking existing infrastructure tools
Runtime Fabric is additive in the current Marie Studio implementation. Gateway-specific flows such as terminal access, SSH-style diagnostics, and low-level debugging still operate on individual gateways.
Runtime Fabric vs Gateways
Use Runtime Fabric when you are deciding where work should go. Use individual gateways when you need to inspect or troubleshoot a specific runtime endpoint.
| Use case | Best surface |
|---|---|
| Define deployment targets | Runtime Fabric |
| Validate version and capability consistency | Runtime Fabric |
| Publish a query plan to an environment target | Runtime Fabric |
| Execute a plan against a deployment target | Runtime Fabric |
| Inspect one machine’s URL, token, or runtime state | Gateway |
| Run gateway-specific diagnostics | Gateway |
Core Operating Model
Group-first targeting
Fabric groups are the unit that Studio uses for deployment targeting. A group can carry:
- Environment such as production, staging, development, or unknown
- Region for geographic or topology hints
- Version for expected runtime alignment
- Capabilities that describe what every gateway in the group should support
- Minimum and maximum gateways for capacity and availability expectations
Gateway compatibility
Gateways remain first-class objects, but Runtime Fabric adds group metadata on top of them. That gives Studio enough context to:
- assign gateways to a default environment group
- validate whether a group is homogeneous
- prefer group-aware publish and execution flows
- keep event attribution and troubleshooting tied to the concrete gateway that handled the work
Default groups
Studio creates system default groups per environment so that gateways always have a safe home during migration and reassignment:
default-productiondefault-stagingdefault-developmentdefault-unknown
If you delete a non-system group, Studio reassigns its gateways to the default group for that environment.
How Runtime Fabric Works in Practice
Open Infrastructure -> Runtime Fabric
Use the Runtime Fabric page to review group health, create new groups, and inspect the gateways already assigned to each group.
Create a fabric group
Define the group metadata that describes the deployment target:
- Name and Group ID
- Environment
- Region
- Description
- Capabilities
- Min/Max gateways
- Enabled state
Assign gateways to the group
Move existing gateways into the group and set the gateway service type when needed:
READ_WRITEREAD_ONLYINGESTION
Validate homogeneity
Run validation after assignment or after runtime changes. Studio compares gateway runtime metadata and capabilities to the expectations for the group.
Target publish and execution flows
Use Runtime Fabric aware surfaces such as the query plan publish and execution dialogs to target the group instead of selecting a single gateway.
Check drift and scheduler fan-out
Use group-level drift checks to compare intended published state with actual gateway state, and use pause/resume actions to fan scheduler commands out across the group’s enabled gateways.
Health, Drift, and Fan-Out
The Runtime Fabric page reports group status with four main states:
| Status | Meaning |
|---|---|
| healthy | Gateways match the expected runtime shape |
| mismatched | One or more gateways diverge on version or capabilities |
| unknown | Validation has not run yet or a gateway could not be inspected |
| degraded | The group has only partial availability |
Health details
Health details summarize how many gateways are healthy or degraded inside the selected group and when the last check completed.
Template drift
Drift checks compare group publish intent with what is actually materialized on each gateway. Use drift results to spot:
- missing templates
- version mismatches
- gateway-specific publication failures
Scheduler fan-out
Pause and resume actions run against every enabled gateway in the selected group and return an aggregate success or failure summary. This keeps group control simple without hiding per-gateway outcomes.
Shared Responsibility
The Runtime Fabric model works best when Studio and gateway operators have clear boundaries.
Studio owns
- group metadata and default-group behavior
- group-aware publish and execution targeting
- homogeneity validation and health states
- drift checks and scheduler fan-out orchestration
Gateway operators own
- runtime version consistency across the actual gateways
- capability exposure through gateway runtime endpoints
- connectivity, auth, and network reachability
- the underlying compute and workload behavior of each gateway
Current Migration Notes
Marie Studio is intentionally running a staged migration toward Runtime Fabric. In the current implementation:
- group-aware targeting exists alongside gateway-specific tooling
- service type is advisory and used for better routing and visibility
- execution records keep both the requested fabric group and the resolved gateway
- gateway APIs remain compatible while group metadata is added on top
Runtime Fabric is not a cosmetic rename of gateways. It is a control-plane layer above gateways, but low-level operational tooling has not been collapsed into group abstractions.
Best Practices
- Design groups around deployment targets, not team names or temporary ownership labels
- Keep groups homogeneous by version and capability whenever possible
- Use default groups as safety rails, then create more specific groups only when routing intent is clear
- Validate after moving gateways so mismatches are visible before you publish or execute
- Run drift checks after publication to confirm every gateway in the group received the intended planner state
- Keep gateway-level diagnostics separate from group-level rollout decisions