One artifact, several servers, all or nothing

An app group deploys a single built image across up to four of your servers at once, behind a load balancer you own. Sproobo builds once, stages that same image on every member, health-gates each node independently, and only then moves traffic — on all of them together, or on none of them. A group is the answer to "I outgrew one box" that doesn't involve deploying four times and hoping.

Why a barrier, and not four deploys

Deploying the same app to four servers one at a time gives you four chances to end up with a split fleet — some nodes on the new release, some on the old, your load balancer cheerfully sending users to both. Nothing about a per-server deploy notices that, because each one succeeded on its own terms.

A group deploy replaces that with two barriers. Every member must report a healthy staged container before any of them takes traffic; then every member must confirm its cutover. If a node fails the second barrier, the group puts every member back on its previous release rather than leaving the fleet half-moved. The measured window between "all nodes staged" and "traffic moved" is roughly three seconds.

The group also pins what gets run, not just when. Each member pulls the image by content digest — repo@sha256:… — when the build recorded one, so two nodes cannot end up on different images that happen to share a tag. Where no digest was recorded, the reference falls back to the tag.

Your load balancer, not ours

Sproobo does not run a load balancer for you, and a group does not create one. You point your own — an ALB, a Hetzner LB, Cloudflare, nginx, whatever you already trust — at the member servers. That is a deliberate boundary: the thing holding your public hostname stays yours, and Sproobo never becomes a single point of failure in front of your traffic.

It also explains the TLS requirement below. Because your load balancer terminates TLS, none of the member boxes tries to obtain a certificate for the shared hostname — which is exactly what makes running the same app on N boxes safe.

What an app needs to join

Groups cap at four members, and an app has to satisfy four conditions. The picker tells you which one is missing, per app, rather than failing the whole selection:

• TLS mode external. Your load balancer terminates TLS and forwards plain HTTP, so no member races ACME for the shared hostname. See Networking & TLS for how to set it.
• No bound Sproobo service. A managed database or cache is reachable only over its own box's private network, so members on different boxes cannot share one. Use an external managed database via environment variables instead.
• No durable local mounts. A multi-server app cannot own state that only one of its boxes can see.
• Not already in another group. An app belongs to at most one.

The leader

One member is the group's leader: the app whose repository the group actually builds from. The first app added to an empty group becomes the leader; every later one joins as a member. Removing the leader promotes the earliest-created survivor, and the group then builds from that app's repo — re-adding the removed app does not undo the promotion, so the dashboard names the successor before you confirm.

The group also carries its own repo and branch, and these are a push matcher, not a build input. When the group's auto-deploy is on, a push is matched against the repo recorded on the group — but the image is always built from the leader app's repo. Set the group's repo to the leader's. The group's Source panel shows the leader's repo and warns when the two disagree.

Auto-deploy belongs to the group, not to its members. Joining a group turns an app's own auto-deploy off and keeps it off while it stays a member — otherwise one push would fan out into N uncoordinated builds, which is the failure a group exists to prevent.

The lifecycle

When it needs a human: degraded

A group ends degraded when the rollback itself could not be completed — meaning Sproobo could not verify that every node is on the same release. Read that precisely: it is a statement about what could be confirmed, not a claim that your fleet is broken. A group can end degradedwith the nodes in fact identical, because a late-arriving report is indistinguishable from a node that never moved. The honest signal is the unverifiable one.

Two things hold while a degraded group is unacknowledged, both deliberately:

• Further group deploys are refused. Deploying onto a fleet in unknown state is how one bad release becomes two. Deploying or rolling back a single member is still allowed — that is how you repair a node.
• Every member's previous container is held from cleanup, so the thing each node was serving stays inspectable while you work out what happened.

Both holds end when an admin acknowledges the deployment, which records who took ownership. Acknowledge after you have looked at the fleet, not before — it touches no server, it records your decision, and it is what lets cleanup resume.

Editing and deleting a group

A group's repo and branch are editable from its Source panel, with the same searchable repository and branch pickers the create form uses. Clearing the repo turns the group's auto-deploy off, because a push cannot match a group with no repo — a switch that reads "on" and can never fire is worse than one that is plainly off.

Deleting a group releases its apps rather than removing them. Every member keeps its own domain, certificate, release history and its running container. No traffic moves and no server is contacted — you are dissolving a coordination unit, not tearing down infrastructure. Their auto-deploy stays off; re-enabling it is a deliberate per-app choice.

If the released apps share a repo and branch, turn auto-deploy back on for at most one of them. Enabling it on several recreates the one-push-becomes-N-builds problem the group was preventing.

Deletion is refused in two cases, and only one of them clears on its own:

• While a group deploy is in flight — the barrier counted these members when it started. Temporary: retry once the deploy settles.
• While the last deploy is degraded and unacknowledged — cleanup is still holding every member's previous container, and that hold is anchored to the deployment rather than to the group. Acknowledge first. This one does not clear by waiting.

A group's past deploys stay on record and remain readable by id through the CLI and MCP after the group is gone.

From the CLI and from an agent

Everything above is available outside the dashboard. The CLI reference covers sproobo groups — create, add-app, remove-app, set-source, deploy, status and delete — and AI & MCP connectors lists the matching tools, including which ones always require human approval.

One capability is deliberately dashboard-only: arming a group's auto-deploy. Preparing a group — its repo, branch and membership — is fully available to an agent, but deciding that every push should deploy to production unattended across your whole fleet is not something an API key can switch on.

Next

• Apps & deploys — the single-server pipeline a group fans out.
• Networking & TLS — setting external TLS mode.
• Observability & alerts — the alert a degraded group raises.