Skip to main content

Thresh 1.7.0: Stack Orchestration — Multi-Service Deployments

· 4 min read
thresh Team
thresh Team
thresh Development Team

Release Date: April 8, 2026
Release Type: Feature Release — Phase 1.7

Thresh 1.7.0 introduces stack orchestration — deploy multi-service applications from a single JSON definition file. Define your services, dependencies, networking, and environment variables, then bring the entire stack up with one command. Rolling updates, automatic Traefik reverse-proxy injection, and dependency ordering come built-in.

🚀 What's New in 1.7.0​

  • 📦 Stack Definitions — Declare multi-service stacks in JSON with images, ports, volumes, and environment variables
  • 🔗 Dependency Ordering — depends_on ensures services start in the correct order
  • 🔄 Rolling Updates — Update individual service images without redeploying the entire stack
  • 🌐 Traefik Auto-Deploy — Automatic reverse-proxy injection when traefik: true is set
  • 📊 Per-Service Status — thresh stack info shows status for every service in a stack
  • 🖧 Hub Integration — All stack commands support --hub for remote orchestration via Thresh Hub
  • 🔒 Mid-Tier Key Auth — Tightened API key authentication with dedicated thresh_mid_* keys

📦 Stack Definitions​

A stack definition is a JSON file that describes all the services in your application:

{
  "name": "my-app",
  "services": [
    {
      "name": "postgres",
      "image": "postgres:16",
      "ports": ["5432:5432"],
      "volumes": ["pg-data:/var/lib/postgresql/data"],
      "env": {
        "POSTGRES_PASSWORD": "secret",
        "POSTGRES_DB": "mydb"
      }
    },
    {
      "name": "api",
      "image": "myregistry/api:latest",
      "ports": ["8080:8080"],
      "depends_on": ["postgres"],
      "env": {
        "DATABASE_URL": "postgres://postgres:secret@postgres:5432/mydb"
      }
    },
    {
      "name": "web",
      "image": "myregistry/web:latest",
      "ports": ["3000:3000"],
      "depends_on": ["api"],
      "traefik": true
    }
  ]
}

Services start in dependency order — postgres first, then api, then web. Traefik reverse-proxy is automatically injected for the web service.

⚡ Getting Started with Stacks​

1. Deploy a Stack​

thresh stack up my-app.json

This reads the JSON definition, resolves dependencies, pulls images, and starts all services in order.

2. Check Stack Status​

thresh stack list
Name       Services   Status    Created
─────────────────────────────────────────────
my-app     3          Running   2 minutes ago

3. Get Per-Service Detail​

thresh stack info my-app
Stack: my-app
─────────────────────────────────────────────
Service     Image                  Status     Ports
postgres    postgres:16            Running    5432:5432
api         myregistry/api:latest  Running    8080:8080
web         myregistry/web:latest  Running    3000:3000

4. Rolling Update​

Update a single service's image without touching the rest of the stack:

thresh stack update my-app --service api --image myregistry/api:v2.1

The old container is stopped and replaced with the new image. Other services remain untouched.

5. Stop and Clean Up​

# Stop the stack (keeps volumes for next time)
thresh stack down my-app

# Or destroy everything including volumes
thresh stack destroy my-app --yes

🖧 Hub Integration​

All stack commands support the --hub flag for remote orchestration through Thresh Hub:

# Deploy a stack via Hub
thresh stack up my-app.json --hub https://your-hub:7200

# List stacks across your fleet
thresh stack list --hub https://your-hub:7200

# Rolling update through Hub
thresh stack update my-app --service api --image myregistry/api:v2.1 --hub https://your-hub:7200

When using --hub, the command is routed through the Hub's mid-tier to the target node. The agent on the node executes the stack operation and reports status back.

🔗 Dependency Ordering​

The depends_on field in a service definition ensures services start in the correct order. Thresh performs a topological sort on the dependency graph:

In this example, postgres and redis start first (no dependencies), then api (depends on both), then web (depends on api).

Circular dependencies are detected and rejected with a clear error message.

🔒 Mid-Tier Key Authentication​

v1.7.0 tightens the API key model. The Hub now issues two key types:

Key PrefixPurposeScope
thresh_live_*Agent connectionsNode → Hub
thresh_mid_*Mid-tier operationsMid-tier → Hub

Mid-tier endpoints (including stack orchestration) require a thresh_mid_* key. Agent keys cannot call mid-tier APIs, and vice versa. This prevents a compromised agent from escalating to management operations.

🔧 Additional Improvements​

  • Config-driven TLS — Kestrel:DisableHttps flag allows Hub to run behind a reverse proxy without hardcoded UseHttps() (fixes container deployment crash)
  • Stale agent cleanup — Hub automatically prunes agents that haven't reported in over 24 hours
  • Metrics batching — Mid-tier batches agent metrics for efficient Hub delivery

⬆️ Upgrade​

Linux / macOS​

curl -fsSL https://thresh.sh/install.sh | bash

Windows (Scoop)​

scoop update thresh

Windows (Chocolatey)​

choco upgrade thresh

Verify​

thresh version

📚 Documentation​

🔜 What's Next​

v2.0 is the next major milestone — stay tuned for the roadmap. We're planning significant enhancements to the Hub UI, stack templates, and multi-node scheduling.

Happy stacking! 🎉