mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-10 18:45:53 +00:00
0c91799e0f
Checksum and SSHSIG verification prove the downloaded artifact matches what was published, not that it can run on this host or is the version the user approved. The apply pipeline previously swapped the binary and exited, relying on systemd to restart into an unproven executable; a wrong-arch fallback asset or unstamped build would take Pulse down with the backup left unused. ApplyUpdate now locates the extracted binary and probes it with --version before the backup and swap stages, failing the update with zero changes applied when the probe fails or reports a version other than the apply target. Same pattern the agent updater already uses. Pinned in the deployment-installability contract with internal/updates/selftest_test.go as the owned proof surface.
160 lines
5.7 KiB
Markdown
160 lines
5.7 KiB
Markdown
# Automatic Updates
|
|
|
|
Pulse supports one-click updates for supported deployment types, making it easy to keep your monitoring system up to date.
|
|
|
|
## Supported Deployment Types
|
|
|
|
| Deployment | Auto-Update | Method |
|
|
|------------|-------------|--------|
|
|
| **ProxmoxVE LXC** | ✅ Yes | In-app update button |
|
|
| **Systemd Service** | ✅ Yes | In-app update button |
|
|
| **Docker** | ❌ Manual | Pull new image |
|
|
| **Source Build** | ❌ Manual | Git pull + rebuild |
|
|
|
|
## Using One-Click Updates
|
|
|
|
### When an Update is Available
|
|
|
|
1. Navigate to **Settings → System → Updates**
|
|
2. If an update is available, you'll see an **"Install Update"** button
|
|
3. Click the button to open the confirmation dialog
|
|
4. Review the update details:
|
|
- Current version → New version
|
|
- Estimated time
|
|
- Changelog highlights
|
|
5. Click **"Install Update"** to begin
|
|
|
|
### Update Process
|
|
|
|
1. **Download**: New version is downloaded, its signature and checksum are verified
|
|
2. **Validate**: The new binary is executed with `--version` to prove it runs on this host and reports the expected version, before anything is touched
|
|
3. **Backup**: Current installation is backed up
|
|
4. **Apply**: Files are updated
|
|
5. **Restart**: Service restarts automatically
|
|
6. **Verify**: Health check confirms success
|
|
|
|
### Progress Tracking
|
|
|
|
A real-time progress modal shows:
|
|
- Current step
|
|
- Download progress
|
|
- Any warnings or errors
|
|
- Automatic page reload on success
|
|
|
|
## Configuration
|
|
|
|
### Update Preferences
|
|
|
|
In **Settings → System → Updates**:
|
|
|
|
| Setting | Description |
|
|
|---------|-------------|
|
|
| **Update Channel** | Stable (recommended for production) or Pre-release (opt-in preview) |
|
|
| **Auto-Check** | Background update check interval (hours); `0` disables |
|
|
|
|
### Stored Settings (system.json)
|
|
|
|
Auto-update preferences are stored in `system.json` and edited via the UI.
|
|
|
|
```json
|
|
{
|
|
"autoUpdateEnabled": false,
|
|
"updateChannel": "stable",
|
|
"autoUpdateCheckInterval": 24,
|
|
"autoUpdateTime": "03:00"
|
|
}
|
|
```
|
|
|
|
**Note:** `autoUpdateTime` is stored for UI reference. The systemd timer still runs on its own schedule (02:00 + jitter). Background update checks follow `autoUpdateCheckInterval`.
|
|
|
|
**Channel policy note:** `stable` is the default and only recommended channel for paid or production environments. `rc` remains the internal channel key, but the user-facing meaning is an explicit pre-release preview path. In v6, unattended systemd auto-updates remain `stable`-only even if `updateChannel` is set to `rc`.
|
|
|
|
## Manual Update Methods
|
|
|
|
### Docker
|
|
|
|
```bash
|
|
# Pull latest image
|
|
docker pull rcourtman/pulse:vX.Y.Z
|
|
|
|
# Restart container
|
|
docker compose down && docker compose up -d
|
|
```
|
|
|
|
If you use the legacy `docker-compose` binary, replace `docker compose` with `docker-compose`.
|
|
|
|
### ProxmoxVE LXC (Manual)
|
|
|
|
```bash
|
|
sudo /bin/update
|
|
```
|
|
|
|
`/bin/update` is installed by the supported Pulse server installer and preserves the signed-installer trust chain. If your host does not have it yet, use the signed server-installer flow in [INSTALL.md](INSTALL.md). Agent updates still use the `/install.sh` command generated in **Settings → Infrastructure → Install on a host**.
|
|
|
|
### Systemd Service (Manual)
|
|
|
|
```bash
|
|
sudo /bin/update
|
|
```
|
|
|
|
`/bin/update` is installed by the supported Pulse server installer and preserves the signed-installer trust chain. If your host does not have it yet, use the signed server-installer flow in [INSTALL.md](INSTALL.md). Agent updates still use the `/install.sh` command generated in **Settings → Infrastructure → Install on a host**.
|
|
|
|
### Source Build
|
|
|
|
```bash
|
|
cd /path/to/pulse
|
|
git pull
|
|
make build
|
|
sudo systemctl restart pulse
|
|
```
|
|
|
|
## Rollback
|
|
|
|
If an update causes issues:
|
|
|
|
### Automatic Rollback
|
|
Pulse creates a backup before updating. If the update fails:
|
|
1. The previous version is automatically restored
|
|
2. Service restarts with the old version
|
|
3. Error details are logged
|
|
|
|
### Manual Rollback
|
|
Update backups created by in-app updates are stored as `backup-<timestamp>/` folders inside the Pulse data directory (`/etc/pulse` or `/data`). If that directory does not have enough free space, Pulse falls back to `/tmp/pulse-backup-<timestamp>`. Pulse keeps the most recent three in-app rollback snapshots and prunes older ones from retention.
|
|
There is no rollback UI. To revert, stop Pulse, restore the backup contents to `/opt/pulse`, then restart.
|
|
|
|
Example (systemd/LXC):
|
|
```bash
|
|
sudo systemctl stop pulse
|
|
sudo cp -a /etc/pulse/backup-<timestamp>/pulse /opt/pulse/pulse
|
|
sudo cp -a /etc/pulse/backup-<timestamp>/VERSION /opt/pulse/VERSION
|
|
sudo rm -rf /opt/pulse/data /opt/pulse/config
|
|
sudo cp -a /etc/pulse/backup-<timestamp>/data /opt/pulse/data
|
|
sudo cp -a /etc/pulse/backup-<timestamp>/config /opt/pulse/config
|
|
sudo cp -a /etc/pulse/backup-<timestamp>/.env /opt/pulse/.env
|
|
sudo systemctl start pulse
|
|
```
|
|
|
|
## Update History
|
|
|
|
History entries are stored in `update-history.jsonl` under the Pulse data directory (`/etc/pulse` or `/data`), and exposed via `GET /api/updates/history` (admin auth required).
|
|
|
|
Systemd/LXC update runs write detailed logs to `/var/log/pulse/update-<timestamp>.log`.
|
|
|
|
## Troubleshooting
|
|
|
|
### Update button not showing
|
|
1. Check if your deployment supports auto-update
|
|
2. Verify an update is actually available
|
|
3. Ensure you have the latest frontend loaded (hard refresh)
|
|
|
|
### Update failed
|
|
1. Check the error message in the progress modal
|
|
2. Review logs: `journalctl -u pulse -n 100` or `/var/log/pulse/update-<timestamp>.log`
|
|
3. Verify disk space is available for both the extracted release payload and a rollback snapshot of your current install
|
|
4. Check network connectivity to GitHub
|
|
|
|
### Service won't restart after update
|
|
1. Check systemd status: `systemctl status pulse`
|
|
2. View recent logs: `journalctl -u pulse -f`
|
|
3. Manually restore from backup if needed
|