Deploying Faster with --parallel and --all

Building once, deploying everywhere

neo deploy --all

Instead of running neo deploy --to staging and neo deploy --to production separately — building the image twice — --all builds one image and transfers it to every environment defined in .neo.yml concurrently.

Why concurrency is capped

Each parallel deploy opens its own SSH connection and decompresses the image on the target server, which spikes CPU and RAM. On a small VPS (1 GB RAM, 1 vCPU), too many of those at once can make the server briefly unresponsive — including to the SSH connection doing the deploying.

neo deploy --all --parallel 1   # one at a time, for underpowered servers

The default is 3. Raise or lower it based on what your servers can actually absorb, not how many environments you have.

Server groups don't get extra concurrency for free

If an environment uses servers: (a group), each server in that group still counts against the same --parallel limit as every other target — Neo doesn't fan a group out faster than it would fan out separate environments.

What still runs sequentially

Two environments that happen to point at the same server are deployed one after another, not in parallel, regardless of --parallel. /etc/neo/state.json on that server is a single file with no locking, so two simultaneous writers would overwrite each other's app entries — targets sharing a server are grouped and queued specifically to avoid that.