# Gyro Containers: scaling, publishing a new version and rollback

https://www.gyrohosting.com/en/knowledgebase/article/gyro-containers-scaling-updating-rollback

- **What you will learn**: How to raise and lower the replica count, publish a new image version without downtime, restart a service and go back to an earlier revision if something goes wrong.
- **Time**: 9 minutes
- **Who this is for**: Developers updating a live service.
- **What you need**: A running service.

## 1. Scaling (replica count)

A replica is a running instance of your service. The more replicas, the more requests the service can handle, and if one instance fails the others continue.

1. In **Services** click your service and press **Scale**.
2. Type the new replica count and confirm.

- **0 stops the service**; your settings, revisions and secrets are kept. The node and environment charge continues, though.
- The upper limit depends on the package (5/10/20) and your pool capacity: **replicas × size** cannot exceed your capacity. If it does, "Not enough capacity in your node pool" appears.
- Scaling **does not create a revision**.

```
gyro container service scale 12345 api --replicas 3
gyro container service scale 12345 api --replicas 0     # stop
```

> **Info**
> 
> There is no autoscaling; you set the replica count. If CPU or memory is constantly high on the graphs, raise the replica count or size ([Logs and graphs](https://www.gyrohosting.com/en/knowledgebase/article/gyro-containers-logs-and-graphs)).

## 2. Publishing a new version (zero downtime)

Every change except `replicas` (image, size, command, variables, a secret, a restart) creates **a new revision**. The revision is rolled out by replacing replicas **one by one**; an old replica is not stopped until a new one is ready (has passed its health check). If your pool has room for one extra replica the switch is completely seamless; if not, replicas are replaced one at a time.

1. On your service page press **New revision / settings**.
2. Type the new **Image** tag (for example `1.4.3`) and change size, port, command or health path if needed.
3. Optionally write a short **reason** (for example a commit id); it appears in the revision history.
4. Save. The status becomes **Deploying**; replicas are renewed in turn and return to **Running**. You see "New revision is being deployed (zero-downtime switch)."

```
gyro container service update 12345 api \
  --image registry.ist.gyrohosting.com/<your-code>/api:1.4.3 \
  --reason "git 3fa91c2"
```

> **Warning**
> 
> If the new revision **fails its health check**, its replicas do not become ready and the rollout does not progress; old replicas keep running. The status stays **Deploying** or **Error**; you see the cause under the row ([Common errors](https://www.gyrohosting.com/en/knowledgebase/article/gyro-containers-common-errors)).

**Restart:** to renew replicas in turn without changing any setting press **Restart** or run `gyro container service restart 12345 api`.

## 3. Revision history

The **Revisions** button shows the last **15 revisions**: revision number, image, size, variable names and (if any) the reason note.

```
gyro container service revisions 12345 api
```

## 4. Rolling back to an earlier revision

1. In the **Revisions** window find the revision you want to return to.
2. Press **Return to this revision** and confirm "Return to revision #N?".
3. The system republishes that revision's **image, size, command and variables** as a new revision ("Returning to the previous revision.").

**What does not change:** your replica count and **secrets** stay as they are.

```
gyro container service rollback 12345 api               # the previous revision
gyro container service rollback 12345 api --revision 7  # a specific revision
```

> **Warning**
> 
> A rollback works only **if the image is still reachable**. Old images unused in the Gyro registry may be cleaned up automatically; keep the images of revisions you may need to return to ([Gyro image registry](https://www.gyrohosting.com/en/knowledgebase/article/gyro-containers-image-registry)).

## 5. Safe release checklist

- Keep the image tag **fixed** (no `latest`).
- Define a **health check path**.
- If you change a database schema, make it backward compatible so it works with both the old and new revision.
- After the release check the **Logs** and **graphs**.

## 6. Frequently asked questions

**Is there downtime during a release?**

Normally not, because replicas change one by one and an old one is not stopped before a new one is ready. If you run a single replica with no spare capacity in the pool there can be a brief switch; at least two replicas are recommended.

**Does a rollback restore the replica count?**

No; the replica count stays as it is.

**I changed a secret; if I roll back does the old value return?**

No. Secrets are not kept in revision history; they do not change on rollback.

**Why do revision numbers skip?**

Every change is a new revision (variables, restarts and rollbacks included).

## Next step

- [Logs and graphs](https://www.gyrohosting.com/en/knowledgebase/article/gyro-containers-logs-and-graphs)
- [Deploy with GitHub Actions](https://www.gyrohosting.com/en/knowledgebase/article/gyro-containers-github-actions)