---
title: "Deploy"
description: "A one-command single-host cluster, a real multi-node deployment, and rolling binary upgrades."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.myswift.rs/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy

> **Do not deploy the current candidate**
>
> The procedures below describe the product surfaces; they do not authorize a
> production roll. The `17adf0b…` line has G6 GREEN and G7 NOT ACCEPTED. Use
> [Upgrade and rollback](/upgrades) and the dated status before any mutation.

## Single-host (SAIO)

`swift-rust/deploy/` stands up a 4-node single-host cluster (a 3× replication
policy and an EC-4-2 policy) from prebuilt binaries — no compiler, no dependency
install.

Use this only on a disposable, isolated host after confirming its listeners,
devices, service names, and data roots are unused. Do not run the bootstrap or
the fragment-loss demo on `swift1`–`swift4`, an existing `:8080`, or any device
that contains retained data.

1. **Step 1**

   Unpack the bundle (binaries + liberasurecode `.so` family + scripts).

```sh
tar xzf swift-rust-bundle.tar.gz
cd swift-rust-bundle
```
2. **Step 2**

   Bootstrap. Idempotent; installs libs+bins, builds rings, starts the systemd
   service, runs a smoke test.

```sh
sudo bash bootstrap.sh          # prints SMOKE: PASS when live at :8080
```
3. **Step 3**

   Operate.

```sh
bash smoke.sh                       # re-run the end-to-end check
bash ec-heal-demo.sh                # destructive: scratch SAIO data only
systemctl status swift-rust-saio    # the cluster service
```

## Multi-node

A real deployment uses the same binaries with real rings and the replicators'
rsync-over-ssh mode. Two paths:

- **[swift-deploy-rs](/swift-deploy-rs)** — plan, seal, verify, and apply the
  Swift Ansible v3 topology natively, driven from its control console or the
  [swift-console](/swift-console) Deploy surface.
- **Manual** — build rings with `swift-ring-builder`, place `swift.conf` +
  rings under `SWIFT_DIR` on every node, and run the servers as systemd units.

## Rolling binary upgrade

Only formats and paths accepted by the compatibility gates may be used for a
mixed-version roll. Promote one prebuilt, hashed artifact one node at a time;
do not rebuild independently on each node. The commands below are an outline,
not an authorization or complete rollback plan:

1. **Step 1**

   Record and back up the exact current binaries and configuration on the node.

```sh
PEREGRINE_ROLLBACK_DIR="/var/lib/peregrine-rollback/$(date +%F-%H%M%S)"
sudo install -d -m 0755 "$PEREGRINE_ROLLBACK_DIR"
sudo cp -a /usr/local/bin/swift-proxy-server \
  /usr/local/bin/swift-object-server \
  /usr/local/bin/swift-container-server \
  /usr/local/bin/swift-account-server \
  "$PEREGRINE_ROLLBACK_DIR/"
sha256sum "$PEREGRINE_ROLLBACK_DIR"/*
```
2. **Step 2**

   Install the new binaries and restart the services on that node.

```sh
install -m755 target/release/swift-object-server /usr/local/bin/
systemctl restart swift-object swift-container swift-account swift-proxy
```
3. **Step 3**

   Verify the new executable SHA, health, CRUD/read-back, policy paths, and daemon
   progress, then hold and move to the next node only if the gate remains clean.

```sh
curl -s -o /dev/null -w '%{http_code}\n' http://<node>:8080/healthcheck   # 200
```

The complete prerequisites, stop conditions, and rollback evidence are in
[Upgrade and rollback](/upgrades).

> **Contabo VIP**
>
> The lab fronts proxies with Keepalived VIP `10.0.0.10:8085` (HAProxy on each
> node). Prefer that VIP for clients and gates; per-node `10.0.0.N:8085` is the
> local HAProxy. See [Lab cluster](/lab-cluster).

Source: https://docs.myswift.rs/deploy/index.mdx