mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-20 23:32:19 +00:00
feat: RBAC, atomic deployments, and fleet-wide backups (Pro) (#181)
* feat: add RBAC viewer accounts, atomic deployments, and fleet-wide backups (Pro) Introduces three Pro-tier features: - RBAC: Multi-user system with admin/viewer roles, user management UI, automatic migration from single-admin credentials, viewer restrictions across the entire UI (read-only editor, hidden action buttons) - Atomic Deployments: Pre-deploy file backup to .sencho-backup/, automatic rollback on health probe failure, manual rollback button, health probes added to stack updates, webhook-triggered deploys use atomic rollback - Fleet-Wide Backups: Point-in-time snapshots of compose files across all nodes (local + remote), stored centrally in SQLite, per-stack restore with optional redeploy, graceful handling of offline nodes * fix(settings): use correct ProGate prop name in UsersSection * fix(settings): remove unused isPro prop from UsersSection * fix(auth): fetch user info after login and setup so isAdmin is set correctly
This commit is contained in:
Anso
+4
-1
@@ -37,7 +37,10 @@
|
||||
"features/multi-node",
|
||||
"features/fleet-view",
|
||||
"features/alerts-notifications",
|
||||
"features/webhooks"
|
||||
"features/webhooks",
|
||||
"features/rbac",
|
||||
"features/atomic-deployments",
|
||||
"features/fleet-backups"
|
||||
]
|
||||
},
|
||||
{
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: Atomic Deployments
|
||||
description: Zero-downtime deployments with automatic rollback for Sencho Pro users.
|
||||
---
|
||||
|
||||
<Note>
|
||||
Atomic Deployments require a Sencho Pro license. Community Edition uses standard deployments without backup or rollback.
|
||||
</Note>
|
||||
|
||||
Sencho Pro wraps every deployment in a safety net. Before applying changes, it backs up your current configuration. If the deployment fails, it automatically rolls back to the previous working state.
|
||||
|
||||
## How it works
|
||||
|
||||
1. **Backup** — Before a deploy or update, Sencho copies `compose.yaml` and `.env` files to a `.sencho-backup/` directory inside the stack folder
|
||||
2. **Deploy** — Sencho runs the requested compose operation (up, pull + recreate, etc.)
|
||||
3. **Health probe** — After deployment, Sencho checks whether any containers exited with a non-zero exit code
|
||||
4. **Auto-rollback** — If a crash is detected, Sencho restores the backed-up files and re-deploys automatically
|
||||
|
||||
This entire sequence happens transparently. You see a single deploy action — Sencho handles the safety logic behind the scenes.
|
||||
|
||||
## Manual rollback
|
||||
|
||||
Pro admins can manually roll back to the previous deployment at any time by clicking the **Rollback** button in the stack action bar. The button appears whenever a backup exists, and its tooltip shows the timestamp of the last backup.
|
||||
|
||||
Clicking Rollback restores the backed-up `compose.yaml` and `.env` files, then re-deploys the stack with the restored configuration.
|
||||
|
||||
## Webhook support
|
||||
|
||||
Deployments triggered via webhooks also use atomic rollback. Whether you deploy manually through the UI or automatically from a CI/CD pipeline, the same backup-and-recover flow applies.
|
||||
|
||||
## Community Edition behavior
|
||||
|
||||
Community users continue to use the standard deploy flow — no backup is created and no rollback is available. Upgrading to Pro enables atomic deployments immediately with no configuration required.
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: Fleet-Wide Backups
|
||||
description: Snapshot compose files across all nodes for disaster recovery and auditing.
|
||||
---
|
||||
|
||||
<Note>
|
||||
Fleet-Wide Backups require a Sencho Pro license. The feature is available to Pro admins in the Fleet View.
|
||||
</Note>
|
||||
|
||||
Create point-in-time snapshots of every `compose.yaml` and `.env` file across your entire fleet — local and remote nodes alike. Snapshots are stored centrally in Sencho's database and can be browsed, previewed, and restored at any time.
|
||||
|
||||
## Creating a snapshot
|
||||
|
||||
1. Navigate to **Fleet View** and select the **Snapshots** tab
|
||||
2. Click **Create Snapshot**
|
||||
3. Optionally enter a description (e.g. "Before v2 migration")
|
||||
4. Click **Create** — Sencho captures files from every reachable node
|
||||
|
||||
During creation, Sencho connects to each node in parallel:
|
||||
- **Local nodes** — reads files directly from the compose directory
|
||||
- **Remote nodes** — fetches files via the Distributed API proxy using the node's API token
|
||||
|
||||
If a remote node is offline or unreachable, it is **skipped gracefully**. The snapshot is still created with data from all reachable nodes, and skipped nodes are recorded with the reason for the failure.
|
||||
|
||||
## Browsing snapshots
|
||||
|
||||
The snapshot list shows:
|
||||
- **Date** — when the snapshot was taken
|
||||
- **Description** — your optional label
|
||||
- **Scope** — how many nodes and stacks were captured
|
||||
- **Warnings** — an indicator if any nodes were skipped
|
||||
|
||||
Click **View** to open the detail view, which presents a collapsible tree:
|
||||
|
||||
```
|
||||
Node A (local)
|
||||
├── traefik/
|
||||
│ ├── compose.yaml
|
||||
│ └── .env
|
||||
└── postgres/
|
||||
└── compose.yaml
|
||||
Node B (remote)
|
||||
└── grafana/
|
||||
├── compose.yaml
|
||||
└── .env
|
||||
```
|
||||
|
||||
Expand any file to preview its contents inline.
|
||||
|
||||
## Restoring from a snapshot
|
||||
|
||||
Admins can restore individual stacks from any snapshot:
|
||||
|
||||
1. Open a snapshot's detail view
|
||||
2. Find the stack you want to restore
|
||||
3. Click **Restore**
|
||||
4. Optionally check **Redeploy stack after restore** to immediately apply the restored configuration
|
||||
5. Confirm the action
|
||||
|
||||
Sencho writes the snapshot's files back to the target node:
|
||||
- **Local nodes** — files are written directly, and the current files are backed up first (creating a rollback point via the atomic deployment system)
|
||||
- **Remote nodes** — files are pushed via the Distributed API proxy
|
||||
|
||||
<Warning>
|
||||
Restoring overwrites the current compose and environment files on the target node. If atomic deployments are enabled, the current files are backed up before restoration.
|
||||
</Warning>
|
||||
|
||||
## Deleting snapshots
|
||||
|
||||
Admins can delete snapshots from the list view. Deleting a snapshot permanently removes all captured file data from the database. This action cannot be undone.
|
||||
|
||||
## Access control
|
||||
|
||||
| Action | Admin | Viewer |
|
||||
|--------|-------|--------|
|
||||
| View snapshot list | Yes | Yes |
|
||||
| Browse snapshot contents | Yes | Yes |
|
||||
| Create snapshot | Yes | No |
|
||||
| Restore from snapshot | Yes | No |
|
||||
| Delete snapshot | Yes | No |
|
||||
|
||||
## Storage
|
||||
|
||||
Snapshots are stored in Sencho's SQLite database. Compose files are typically small (under 10 KB each), so even hundreds of snapshots consume minimal disk space. For very large fleets, consider periodically deleting old snapshots to keep the database lean.
|
||||
@@ -19,6 +19,18 @@ Add remote Sencho instances as nodes. All dashboard operations — stack managem
|
||||
|
||||
Monitor your entire infrastructure from a single screen. The fleet dashboard shows all nodes with health metrics, container counts, and resource usage. Pro users unlock fleet health summary cards, container drill-down, search, sorting, filtering, and critical node detection. [Learn more →](/features/fleet-view)
|
||||
|
||||
## RBAC & user management
|
||||
|
||||
Create viewer accounts with read-only access to dashboards, logs, and file contents — while keeping deploy and edit permissions locked to admins. Sencho Pro supports two roles: Admin (full access) and Viewer (read-only). [Learn more →](/features/rbac)
|
||||
|
||||
## Atomic deployments
|
||||
|
||||
Pro users get automatic backup and rollback on every deployment. Before applying changes, Sencho snapshots your compose and environment files. If containers crash after deploy, the previous configuration is restored automatically. [Learn more →](/features/atomic-deployments)
|
||||
|
||||
## Fleet-wide backups
|
||||
|
||||
Create point-in-time snapshots of every compose file and environment file across all nodes. Snapshots are stored centrally and can be browsed by node and stack. Restore individual stacks from any snapshot with optional one-click redeploy — even to remote nodes. Offline nodes are gracefully skipped with visible warnings. [Learn more →](/features/fleet-backups)
|
||||
|
||||
## Real-time logs & stats
|
||||
|
||||
Stream container logs and resource metrics (CPU, memory, network I/O) live in the browser via WebSocket and Server-Sent Events connections. The Home dashboard shows historical CPU and RAM charts over the last 24 hours.
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: RBAC & User Management
|
||||
description: Role-based access control for Sencho Pro — create admin and viewer accounts to control who can modify your stacks.
|
||||
---
|
||||
|
||||
<Note>
|
||||
RBAC requires a Sencho Pro license. Community Edition supports a single admin account only.
|
||||
</Note>
|
||||
|
||||
Sencho Pro introduces role-based access control with two distinct roles: **Admin** and **Viewer**. This lets you give team members read-only access to your infrastructure without risking accidental changes.
|
||||
|
||||
## Roles
|
||||
|
||||
| Role | Description |
|
||||
|------|-------------|
|
||||
| **Admin** | Full access to all features — deploy, edit, manage users, configure nodes, and more |
|
||||
| **Viewer** | Read-only access to dashboards, logs, stats, and file contents |
|
||||
|
||||
### What viewers can see
|
||||
|
||||
- Dashboard and home metrics
|
||||
- Stacks list and stack detail view
|
||||
- Compose and `.env` file contents (read-only)
|
||||
- Per-container stats and logs
|
||||
- Fleet view
|
||||
- Resources hub (images, volumes, networks — read-only)
|
||||
- Global logs
|
||||
- Notifications
|
||||
|
||||
### What viewers cannot do
|
||||
|
||||
- Edit compose or environment files
|
||||
- Deploy, restart, stop, or start stacks
|
||||
- Create or delete stacks
|
||||
- Manage users, nodes, webhooks, or alerts
|
||||
- Access the host console
|
||||
- Prune resources
|
||||
- Change settings
|
||||
|
||||
## Managing users
|
||||
|
||||
Admins can manage accounts in **Settings → Users**. From there you can:
|
||||
|
||||
- **Create** a new user with a username, password, and role (Admin or Viewer)
|
||||
- **Edit** an existing user's password or role
|
||||
- **Delete** a user account
|
||||
|
||||
## Migration from single-admin setup
|
||||
|
||||
When you upgrade to Sencho Pro, your existing single-admin credentials are automatically migrated to the new users table. No manual action is required — your login continues to work as before, and your account is assigned the Admin role.
|
||||
|
||||
## License tiers
|
||||
|
||||
| Tier | Admin accounts | Viewer accounts |
|
||||
|------|---------------|-----------------|
|
||||
| **Community** | 1 | 0 |
|
||||
| **Personal Pro** | 1 | 1 |
|
||||
| **Team Pro** | Unlimited | Unlimited |
|
||||
Reference in New Issue
Block a user