# Lifecycle

Actions on an already-created server: start and stop, reboot, auto-sleep and immediate sleep, run mode, wake, forced status refresh, and tunnel repair via the serial console. All endpoints act on a specific `:id`, and most return `{ "success": true }`.

Scope: `vibe:infra`

## Operations

- [Start server](./lifecycle/start.md) — `POST /v1/infra/servers/:id/start`
- [Stop server](./lifecycle/stop.md) — `POST /v1/infra/servers/:id/stop`
- [Reboot server](./lifecycle/reboot.md) — `POST /v1/infra/servers/:id/reboot`
- [Wake server](./lifecycle/wake.md) — `POST /v1/infra/servers/:id/wake`
- [Sleep now](./lifecycle/sleep-now.md) — `POST /v1/infra/servers/:id/sleep-now`
- [Configure auto-sleep](./lifecycle/sleep.md) — `PATCH /v1/infra/servers/:id/sleep`
- [Set the run mode](./lifecycle/run-mode.md) — `PATCH /v1/infra/servers/:id/run-mode`
- [Refresh status](./lifecycle/refresh.md) — `POST /v1/infra/servers/:id/refresh`
- [Repair tunnel](./lifecycle/repair.md) — `POST /v1/infra/servers/:id/repair`
- [Repair status](./lifecycle/repair-status.md) — `GET /v1/infra/servers/:id/repair-status`

The list above describes a dedicated virtual machine. A Galaxy app — a container on a shared host — performs some of these operations through its host, while others do not apply to it at all: the operation map with refusal codes is on the [Galaxy app](/docs/infra/galaxy) page.

## Scenarios

**Saving money on overnight idle time (BLACKHOLE):**

1. Check the idle timeout: on a new machine it is 60 minutes. To set a different value or disable auto-sleep — [`PATCH /sleep`](./lifecycle/sleep.md).
2. A call to [`/deploy`](/docs/infra/deploy/deploy) wakes the server automatically. A request to the HTTPS subdomain wakes it when the application is open to everyone or the visitor is authenticated — [wake conditions](./lifecycle/wake.md).
3. If you need to wake it ahead of time (for example, before a cron job) — [`POST /wake?wait=true`](./lifecycle/wake.md).

**Manual application restart without a full server reboot:**

1. Check that the tunnel is healthy: [`GET /v1/infra/servers/:id`](/docs/infra/servers/get) → `blackholeStatus: "CONNECTED"`.
2. Restart the service: [`POST /exec`](/docs/infra/deploy/exec) with `systemctl restart app`.

If the restart does not help — [`POST /reboot`](./lifecycle/reboot.md).

**The tunnel lost its connection (DISCONNECTED):**

1. Check: [`GET /v1/infra/servers/:id`](/docs/infra/servers/get) — `blackholeStatus: "DISCONNECTED"` on a `RUNNING` server.
2. Start the repair: [`POST /repair`](./lifecycle/repair.md).
3. Poll for progress: [`GET /repair-status`](./lifecycle/repair-status.md).
4. On completion — `blackholeStatus` returns to `CONNECTED`.

## See also

- [Servers](/docs/infra/servers)
- [Galaxy app](/docs/infra/galaxy)
- [Deploy API](/docs/infra/deploy)
- [Root section — Infrastructure](/docs/infra)