Skip to main content
Jeremias Meister - Tools & Pipeline

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:

  1. Loads the graph from a file
  2. Creates an isolated execution environment
  3. Starts all triggers and actions
  4. 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

deployment-dashboard-button.png

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:

  1. Click the Execute Graph button in the work area
  2. The graph is saved and deployed immediately
  3. View the graph in the deployment dashboard

Method 2: From Deployment Dashboard

Deploy an existing saved graph:

  1. Open the Deployment Dashboard
  2. Click Deploy New Graph
  3. Select a .json graph file
  4. The graph is loaded and started
  5. 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:

  1. Edit the graph in the work area
  2. Save the changes
  3. In the deployment dashboard, click Update on the graph
  4. The old version stops atomically
  5. The new version deploys immediately
  6. 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:

  1. In the deployment dashboard, select the graph
  2. Click Stop
  3. All triggers in the active workflow are stopped and the currently running actions are stopped.
  4. 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:

  1. In the deployment dashboard
  2. Double-Click the graph
  3. The graph loads in the editor
  4. Make changes as needed
  5. Save your Graph
  6. 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:

StatusMeaningAppearance
HealthyRunning with no errorsGreen indicator
DegradedRunning but has recent errorsYellow indicator
UnhealthyStopped or tasks diedRed 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):

  1. Open Settings (gear icon)
  2. Scroll to the API Access section
  3. 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 Authorization header is present and correctly formatted
  • Verify the token is valid and not expired
  • Check that you’re using Bearer prefix (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 graph
  • UpdateGraph - Update an existing graph
  • StopGraph - Stop a deployed graph
  • ListGraphs - List all deployed graphs
  • GetGraph - Get specific graph details
  • HealthCheck - 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 workload
  • task_count: Background task count
  • uptime_seconds: Time since deployment
  • last_error: Recent error message (if any)