Multi-Server Script Execution
Run one script across many servers at once with parallel or sequential execution, and inspect per-server results in a single view.
Multi-Server Script Execution
Multi-Server Execution lets you run the same script against a list of servers in one operation. Devpilot creates a single parent run that tracks the whole operation and one child result per server, so you can audit the fleet-wide outcome at a glance and drill into individual server output when you need to.
Typical uses:
- Roll out a config change to every app server in an environment.
- Run the same health check across an entire fleet and compare outputs.
- Apply a security patch to a group of hosts with an abort-on-first-failure policy.
Multi-server execution pushes the same script content to every target. You pick the script once, Devpilot resolves its body, and each server runs an identical command — no per-server branching required.
What Devpilot Tracks For You
Every multi-server run is recorded as a single parent job plus one row per target server. The parent job shows a name (defaults to the script name, editable), the execution mode and failure strategy you picked, the overall status (Running, Completed, or Failed), and live counters for total, completed, and failed servers so you can see progress at a glance.
Each per-server row captures which server produced the result, its own status (Running, Completed, or Failed), the final output, exit code, duration, and any error text if the run didn't succeed. Every row links to the full single-server execution record where you can see the complete streamed output, stdout, stderr, and everything else you'd see from a manual run.
Running a Script on Many Servers
Open the script
Navigate to the script you want to run and click Run on Multiple Servers.
Pick target servers
Tick the servers you want the script to run on. The search box filters by name, and at least one server must be selected. Only servers in the current workspace are eligible.
Choose an Execution Mode
- Parallel — Devpilot starts the script on every server at once. Fastest option.
- Sequential — Servers are processed one after another, in the order you picked them. Use this when ordering matters, for example rolling restarts behind a load balancer.
Choose an On Failure strategy
- Continue on error — Keep going even if a server fails. Failures are still recorded and counted.
- Stop on first failure — Abort the remaining servers the moment any server fails. Servers already running are allowed to finish.
Launch and monitor
Devpilot creates the parent run, dispatches to each server, and fills in per-server results as they come in. The modal updates live, and you can open any row to jump into that server's streamed output.
Execution Modes
All servers start immediately. Total wall-clock time is roughly the duration of the slowest server. Best for reads, health checks, idempotent state-applies, or any operation where the order between servers doesn't matter.
Servers run one at a time, in the order you selected. Total wall-clock time is the sum of per-server durations. Best for rolling updates where each server should finish before the next starts — for example, draining and restarting one app server at a time behind a load balancer.
Failure Strategies
Devpilot records each failure, bumps the failure counter, and still attempts the remaining servers. Good for fleet-wide diagnostics where one broken host shouldn't hide the state of the rest.
The moment a server fails, Devpilot stops dispatching further servers. Anything already running continues to completion, but nothing new is queued. Good for rollouts where a single failure means "don't make this worse."
Inspecting Results
Open any multi-execution run to see:
- Summary line — Total servers, completed, and failed counts.
- Per-server rows — Each target's status, duration, and exit code at a glance.
- Drill-down — Click a server to jump into its single-server execution record. You get the same full streamed output, stdout/stderr, and rerun controls you'd have after a manual run.
Every per-server result is a full single-server execution under the hood. Logs, exit codes, and durations behave exactly the same as if you had run the script manually on each server — you can even re-run a single server from its execution record if it failed.
Real-World Example
Imagine a rolling restart across three web servers. You'd pick the restart script, select the three servers in the order you want them drained (primary, secondary, tertiary), choose Sequential mode, and pick Stop on first failure.
With that configuration, Devpilot runs the script on the first server, waits for it to succeed, and only then dispatches to the second. If any server fails, it stops — so the load balancer still has healthy backends behind it. The parent run's live counters tell you how far along the rollout is at any point.
Limits and Constraints
- At least one target server must be selected.
- Every server you pick must belong to the same workspace. Servers that don't are recorded as failed with an access-denied error and the run moves on (or stops, depending on the failure strategy).
- Final parent status is derived from the per-server outcomes — any server failing marks the parent as Failed under "stop on first failure", or the overall run as Completed when every server finished successfully.
Troubleshooting
| Problem | Likely cause |
|---|---|
| "Server not found or access denied" on a row | The server isn't in the current workspace, or has been deleted. |
| Parallel run stays in Running long after launch | One of the per-server executions hasn't reported completion. Open that row's detail page. |
| Sequential run stopped partway through | Expected with "Stop on first failure" when a server fails. Check the failed row's error. |
| Different servers produced different output | They have different installed software, file paths, or secret values. See Script Secrets. |
| Counts show failures but you can't tell which ones | Scroll the per-server rows — every failure has its own status and error message. |
Secrets are scoped per server. If you use server-scoped Script Secrets, each target resolves its own values — a key missing on one server can produce an inconsistent run. Prefer workspace-wide secrets for fleet-wide scripts.
Next Steps
Scripts and Automation
Build and test the single-server script first, then scale it out.
Script Workflows
For ordered multi-step rollouts on one server, use a workflow instead.
Script Secrets
Make sure shared credentials resolve consistently across the fleet.
Script Webhooks
Kick off a fleet-wide run from an external trigger with a webhook.