Rings¶

Manifest Platform organizes deployment environments into rings — isolated stages that a solution passes through on its way to production. Each ring has its own infrastructure, configuration overrides, health monitoring, and access controls, enabling teams to validate changes incrementally before they reach end users.

Ring-Based Rollout Strategy¶

The platform ships with three built-in rings. Solutions progress from left to right, and each transition requires the previous ring to be healthy.

graph LR
    DEV["Dev Ring<br/><i>Build & iterate</i>"]
    STG["Staging Ring<br/><i>Validate & test</i>"]
    PRD["Production Ring<br/><i>Serve users</i>"]

    DEV -->|"Promote"| STG
    STG -->|"Promote"| PRD

Ring	Purpose	Audience	Typical Scale
Dev	Rapid iteration and debugging. Deployments happen automatically on code push.	Solution builders and engineers	Single replica, relaxed resource limits
Staging	Integration testing, performance benchmarking, and stakeholder review.	QA, team leads, preview users	Mirrors production topology at reduced scale
Production	Serves real user traffic with full redundancy and monitoring.	All end users	Auto-scaled, multi-replica, high availability

Custom rings

Organizations on the Enterprise plan can define additional rings (e.g., canary, uat, regional-eu) with custom promotion rules. Contact your account team or configure them in Deployments > Rings.

Ring Configuration¶

Each ring carries its own configuration layer. Values set at a more specific ring override those from a less specific one, following a merge hierarchy:

Organization defaults  <  Workspace defaults  <  Solution defaults  <  Ring overrides

Environment Variables¶

Define ring-specific environment variables that are injected into every component at runtime.

Platform UISolution Manifest

Navigate to Solution > Settings > Rings, select a ring, and edit the Environment Variables section.

# flow-solution.yaml
rings:
  dev:
    env:
      DATABASE_URL: postgres://dev-db:5432/app
      LOG_LEVEL: debug
      FEATURE_NEW_SEARCH: "true"
  staging:
    env:
      DATABASE_URL: postgres://staging-db:5432/app
      LOG_LEVEL: info
      FEATURE_NEW_SEARCH: "true"
  production:
    env:
      DATABASE_URL: postgres://prod-db:5432/app
      LOG_LEVEL: warning
      FEATURE_NEW_SEARCH: "false"

Resource Limits¶

Control the compute resources allocated to components in each ring.

Setting	Dev Default	Staging Default	Production Default
CPU	0.25 vCPU	0.5 vCPU	1.0 vCPU
Memory	512 MB	1 GB	2 GB
Replicas	1	2	3 (auto-scaled)
Timeout	300s	120s	60s
Concurrency	10	50	200

Override defaults per ring in the solution manifest:

rings:
  production:
    resources:
      cpu: "2.0"
      memory: "4Gi"
      min_replicas: 3
      max_replicas: 20
      concurrency: 500

Feature Flags¶

Feature flags can be toggled per ring, allowing you to enable experimental capabilities in dev and staging without affecting production.

Flag	Dev	Staging	Production
`new-vector-index`	On	Off	Off
`streaming-responses`	On	On	Off
`v2-auth-flow`	On	On	On

Ring-Specific Connector Instances¶

Connectors often need different credentials or endpoints per environment. Manifest Platform supports ring-scoped connector instances so your dev ring talks to sandbox APIs while production uses live credentials.

connectors:
  salesforce:
    dev:
      instance_url: https://mycompany--sandbox.salesforce.com
      credential: salesforce-sandbox-cred
    staging:
      instance_url: https://mycompany--uat.salesforce.com
      credential: salesforce-uat-cred
    production:
      instance_url: https://mycompany.salesforce.com
      credential: salesforce-prod-cred

Never share production credentials with lower rings

The platform enforces credential isolation between rings by default. A connector instance bound to production cannot be referenced from dev or staging unless explicitly overridden by an organization admin.

Ring Health Monitoring¶

Each ring runs continuous health checks to ensure the active deployment is functioning correctly. If health degrades below the configured threshold, the platform triggers alerts and can initiate automatic rollback.

Health Check Types¶

Check	What It Validates	Frequency
Liveness	The component process is running and responsive	Every 10s
Readiness	The component can accept and process requests	Every 15s
Startup	The component has completed initialization (checked once)	On deploy
Custom	User-defined HTTP endpoint returns 200	Configurable

Configuring Health Checks¶

rings:
  production:
    health:
      liveness:
        path: /healthz
        interval: 10s
        threshold: 3        # failures before restart
      readiness:
        path: /ready
        interval: 15s
        threshold: 2        # failures before removing from routing
      custom:
        - name: database-connectivity
          path: /health/db
          interval: 30s
          threshold: 5

Health Dashboard¶

The ring health dashboard provides a real-time view of deployment status across all rings for your solution. Access it from Solution > Deployments > Health in the Platform UI.

Integrate with your alerting stack

Ring health events are emitted to the observability subsystem. Configure alert rules to notify your team via Slack, PagerDuty, or email when a ring transitions to an unhealthy state. See Observability Specs for details.

Ring Access Control¶

Access to each ring is governed by role-based permissions. This prevents accidental production deployments and restricts who can view sensitive environment configuration.

Action	Dev	Staging	Production
View deployments	All solution members	All solution members	All solution members
Deploy	Solution builders	Solution builders	Admins only
Promote	Solution builders	Admins + approvers	Admins + approvers
View environment variables	Solution builders	Admins only	Admins only
Modify configuration	Solution builders	Admins only	Admins only
Rollback	Solution builders	Admins only	Admins only

Customize ring permissions

Organization admins can adjust ring access controls in Deployments > Rings. For example, you might grant a QA team deploy access to staging without giving them access to production configuration.

Rings API¶

Manage rings programmatically. All paths are under /orgs/{org_id}/workspaces/{workspace_id}/deployments/rings.

Method	Path	Description
`POST`	`/deployments/rings`	Create a deployment ring
`GET`	`/deployments/rings`	List all rings in the workspace
`GET`	`/deployments/rings/{ring_id}`	Get ring details
`PUT`	`/deployments/rings/{ring_id}`	Update ring configuration
`DELETE`	`/deployments/rings/{ring_id}`	Delete a ring

SDK Example¶

Coming Soon

The Python SDK for local development is not yet publicly available.

from flow_sdk.cli_client import CLIClient

client = CLIClient(config)

# Create a canary ring
ring = client.rings.create({
    "name": "Canary",
    "description": "5% traffic slice for canary testing",
})

print(f"Created ring: {ring['id']}")

# List rings
rings = client.rings.list()
for r in rings:
    print(f"  {r['name']} ({r['id']})")

# Update ring configuration
client.rings.update(ring["id"], {
    "description": "10% traffic slice for canary testing",
})

# Delete ring
client.rings.delete(ring["id"])

Health check configuration

Ring-level health check settings (liveness, readiness, custom probes) are configured via the solution manifest or the Platform UI. REST endpoints for health check configuration are not yet exposed separately.