Graph Deployment
Graph deployment allows you to run multiple pipeline graphs simultaneously in isolated environments. This feature enables production-ready automation, scheduled workflows, and scalable pipeline management.
What is Graph Deployment?
When you deploy a graph, Project Succession:
- Loads the graph from a file
- Creates an isolated execution environment
- Starts all triggers and actions
- Monitors execution in the background
Why Deploy Graphs?
Use Cases
Production Pipelines
- Deploy automated workflows that run 24/7
- Monitor file systems, webhooks, and scheduled tasks
Multiple Projects
- Run pipelines for different projects and workflow simultaneously
- Isolate execution environments for different teams
Scheduled Automation
Deployment Dashboard
Access the deployment dashboard through:
- Pressing the button “Deployment Dashboard” in the header

The dashboard displays:
- All deployed graphs
- Current status (Running, Stopped, Error)
- Deployment time and last update
- Active workflow count
- Health indicators
Deploying a Graph
Method 1: From Work Area
When you have a graph open in the work area:
- Click the Execute Graph button in the work area
- The graph is saved and deployed immediately
- View the graph in the deployment dashboard
Method 2: From Deployment Dashboard
Deploy an existing saved graph:
- Open the Deployment Dashboard
- Click Deploy New Graph
- Select a
.jsongraph file - The graph is loaded and started
- Monitor status in the dashboard
What Happens During Deployment
When you deploy a graph:
- File is loaded: Graph structure and configuration are read
- Validation: Nodes and connections are validated
- Execution starts: All triggers begin monitoring for events
- Isolation: Graph runs in its own environment
- Status tracking: Real-time updates are sent to the dashboard
Managing Deployed Graphs
Viewing Graph Details
A deployed graph in the dashboard shows:
- Graph name
- Deployment time
- Last update time
- Current status
- Active workflow count
Updating a Deployed Graph
To update a running graph with changes:
- Edit the graph in the work area
- Save the changes
- In the deployment dashboard, click Update on the graph
- The old version stops atomically
- The new version deploys immediately
- Deployment time is preserved
Atomic Updates: Updates are atomic - the old graph stops completely before the new one starts, preventing conflicts.
Stopping a Deployed Graph
To stop a running graph:
- In the deployment dashboard, select the graph
- Click Stop
- All triggers in the active workflow are stopped and the currently running actions are stopped.
- The graph is removed from the dashboard
Note: Stopping a graph cannot be undone. To run it again, you must redeploy.
Opening a Deployed Graph
To view or edit a deployed graph:
- In the deployment dashboard
- Double-Click the graph
- The graph loads in the editor
- Make changes as needed
- Save your Graph
- Use Update in the deployment dashboard to deploy the changes
Important: Opening a deployed graph in the work area does not stop it. It continues running independently.
Health Monitoring
Health Status Indicators
Each deployed graph shows a health status:
| Status | Meaning | Appearance |
|---|---|---|
| Healthy | Running with no errors | Green indicator |
| Degraded | Running but has recent errors | Yellow indicator |
| Unhealthy | Stopped or tasks died | Red indicator |
Health Checks
The system automatically monitors:
- Active workflows: Number of currently executing workflows
- Uptime: How long the graph has been running
- Error tracking: Recent errors and failure messages
- Task health: Status of background tasks
Multi-Graph Management
Running Multiple Graphs
You can deploy and run multiple graphs simultaneously:
Independent Execution
- Each graph has its own triggers and actions
- Graphs don’t interfere with each other
- Resources are isolated per graph
Shared Resources
- All graphs share the same secrets vault
- Backend settings apply to all graphs
- DCC tool integrations are shared
Performance Considerations
- Each graph consumes system resources
- Monitor health dashboard for performance issues
- Consider resource-intensive actions when deploying many graphs
Troubleshooting
Graph Won’t Deploy
Error: “Graph already deployed”
- Stop the existing graph first, or
- Use Update to atomically redeploy
Error: “File not found”
- Check that the file path is correct
- Use absolute paths instead of relative paths
- Ensure the graph file exists and is readable
Error: “Invalid graph format”
- The graph file may be corrupted
- Open the file in work area to validate structure
- Re-save the graph and try again
Graph Shows Unhealthy
Degraded status
- Check the last error message
- Open graph in work area to debug
- Review console logs for details
- Fix issues and use Update to redeploy
Unhealthy status
- Graph execution has stopped unexpectedly
- Check console logs for crash information
- Stop the graph and redeploy
- Consider reducing resource-intensive operations
Updates Not Appearing
Dashboard not updating
- Check WebSocket connection status
- Refresh the dashboard
- Restart the application
Graph changes not taking effect
- Ensure you saved the graph file
- Use Update to redeploy changes
- Verify file path matches deployed graph
Performance Issues
High resource usage
- Too many graphs deployed simultaneously
- Resource-intensive actions running frequently
- Consider stopping non-critical graphs
- Increase interval timing for scheduled tasks
Lagging updates
- WebSocket channel may be overwhelmed
- Check console for “lagged” warnings
- Reduce update frequency in graphs (less log event nodes)
- Stop some deployed graphs
CLI Integration
For Business plan users, the CLI provides full graph deployment management:
# Deploy a graph from CLI
succession deploy-graph /path/to/pipeline.json
# Update a deployed graph
succession update-graph /path/to/pipeline.json
# List all deployed graphs
succession list-graphs
# Check health of all graphs
succession health-check
# Check health of specific graph
succession health-check /path/to/pipeline.json
# Stop a deployed graph
succession stop-graph /path/to/pipeline.json
See CLI Reference for complete CLI documentation.
Advanced Topics
API Authentication
All API endpoints require authentication using a Bearer token. This ensures that only authorized clients can manage your pipeline graphs.
Token Generation
Automatic Generation: On first startup, Project Succession automatically generates an API token and stores it securely in your system’s keyring (Windows Credential Manager, macOS Keychain, or Linux Secret Service). No manual setup is required.
Manual Management: Business+ license users can view, regenerate, or delete tokens through the Settings modal in the Tauri app under the “API Access” section.
Using Tokens with HTTP Requests
All HTTP requests to protected endpoints (/graph_command) must include the token in the Authorization header:
curl -X POST http://localhost:3000/graph_command \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-d '{"action":"ListGraphs"}'
Using Tokens with WebSocket Connections
WebSocket connections (/graph_ws) authenticate via a query parameter:
ws://localhost:3000/graph_ws?token=YOUR_API_TOKEN
Retrieving Your Token
From the Tauri App (Business+ license):
- Open Settings (gear icon)
- Scroll to the API Access section
- Your token is displayed and can be copied
From the CLI:
succession get-token
Programmatically (from Tauri frontend):
import { invoke } from '@tauri-apps/api/core';
const token = await invoke<string>('ensure_api_token');
Token Security
- Tokens are stored securely in your operating system’s credential manager
- Tokens do not expire by default (unlimited duration)
- Regenerating a token invalidates the previous token immediately
- Keep your token confidential - anyone with the token can manage your pipelines
Troubleshooting Authentication
Error: “Unauthorized” (401)
- Ensure the
Authorizationheader is present and correctly formatted - Verify the token is valid and not expired
- Check that you’re using
Bearerprefix (with space)
Error: “Token not found”
- The token may have been deleted
- Restart the application to auto-generate a new token
- Or regenerate manually in Settings
API Integration
Graphs can be managed programmatically via HTTP API:
Endpoint: POST http://localhost:3000/graph_command
Available Commands:
DeployGraph- Deploy a new graphUpdateGraph- Update an existing graphStopGraph- Stop a deployed graphListGraphs- List all deployed graphsGetGraph- Get specific graph detailsHealthCheck- Check health status
Example Request:
curl -X POST http://localhost:3000/graph_command \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-d '{
"action": "DeployGraph",
"params": {
"file_path": "/path/to/pipeline.json"
}
}'
Example Response:
{
"file_path": "/path/to/pipeline.json",
"graph_name": "My Pipeline",
"status": "Running",
"active_workflows": 0
}
WebSocket Updates
Real-time graph updates via WebSocket:
Endpoint: ws://localhost:3000/graph_ws?token=YOUR_API_TOKEN
Note: Authentication is required via the token query parameter.
Message Format:
{
"graph_file_path": "/path/to/pipeline.json",
"node_update": {
"node_id": "node_123",
"status": "running",
"workflow_id": "workflow_456",
"originating_trigger": "trigger_789"
}
}
Filter updates by graph_file_path to track specific graphs.
Headless Deployment
For production servers without a GUI:
# Start the backend service
succession start-service
# Deploy graphs via CLI
succession deploy-graph /pipelines/production.json
# Monitor via health checks
succession health-check
# No GUI required
Automated Deployment
Script deployment workflows for CI/CD, example script:
#!/bin/bash
# deploy-pipelines.sh
set -e # Exit on error
# Start service if not running
succession status || succession start-service
# Deploy all pipelines
for pipeline in /pipelines/*.json; do
echo "Deploying $pipeline..."
succession deploy-graph "$pipeline"
done
# Verify all are healthy
succession health-check
# Show final status
succession list-graphs
Health Monitoring Integration
Integrate with monitoring systems (Prometheus, Datadog, etc.):
# Health check endpoint for monitoring
curl -X POST http://localhost:3000/graph_command \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-d '{"action":"HealthCheck","params":{}}'
Parse JSON response to extract health metrics:
status: “Healthy”, “Degraded”, or “Unhealthy”active_workflows: Current workloadtask_count: Background task countuptime_seconds: Time since deploymentlast_error: Recent error message (if any)
Related Topics
- Working with Nodes - Creating and configuring graphs
- CLI Reference - Command-line graph management
- Settings - Backend and service configuration
- Interface Overview - Understanding the UI