mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-26 11:49:16 +00:00
865d792874
* feat(pricing): collapse to two tiers (Community + Admiral) Collapse Sencho's pricing from three tiers (Community / Skipper / Admiral) to two: a generous free Community tier and a single paid Admiral tier. The Skipper tier is removed. Now free in Community: auto-heal, auto-update, scheduled operations, webhooks, notification routing, Fleet Actions and bulk operations, SSO preset providers (Google / GitHub / Okta), unlimited users with admin and viewer roles, and deploy safety (atomic deploys, auto-rollback, and one-click rollback). Admiral (paid) is focused on running and governing a fleet: blueprints, Fleet Secrets, deploy enforcement, vulnerability report export, audit log, host console, private registries, mesh networking, node cordon, managed cloud backup, LDAP / Active Directory SSO, and the advanced RBAC roles (deployer, node-admin, auditor) with per-resource scoped assignments. Internally the license variant distinction is removed so tier is binary (community / paid). License validation still verifies the Lemon Squeezy store and product before granting paid status. Docs and the contributor guide are updated to the two-tier model. * docs(pricing): correct licensing page to two-tier pricing and tidy stale tier wording The licensing docs page kept the old Admiral pricing plus a Founder Lifetime column and an Enterprise paragraph after the two-tier collapse. Update it to $12/month or $99/year, drop the lifetime and Enterprise content, and link to the pricing page for current pricing. Also fix stale "Skipper" wording in CLA.md, SUPPORT.md, one test title, and three test comments. Historical CHANGELOG entries and the retired-Skipper license-guard test are intentionally left as-is. * docs: align licensing and SSO pages with the two-tier model Correct the SSO overview so the Google, GitHub, and Okta presets read as available on every tier, matching the provider table; only LDAP and Active Directory require Sencho Admiral. Remove the lifetime-plan references from the licensing, settings, and troubleshooting pages so they reflect subscription-only Admiral pricing. * fix(rbac): omit scoped permissions from /me on the Community tier Scoped role assignments only take effect on the paid tier, but GET /api/permissions/me returned them unconditionally, so a downgraded instance with leftover assignments rendered per-resource affordances the API then rejected with 403. The endpoint now mirrors the permission middleware and includes scoped permissions only on the paid tier. Adds a regression test covering the downgrade case. * docs: use custom-pricing wording on the contact page The two-tier model has no Enterprise tier; reword the contact page's enterprise pricing/deals to custom pricing/deals so it does not imply a tier that no longer exists.
150 lines
5.1 KiB
Plaintext
150 lines
5.1 KiB
Plaintext
---
|
|
title: Backup & Restore
|
|
description: What to back up, how to restore it, and how to migrate Sencho to a new host.
|
|
---
|
|
|
|
Sencho stores all its state in two places: the **data directory** (SQLite database and encryption key) and your **compose directory** (your actual stack files). Both need to be backed up for a complete recovery.
|
|
|
|
<Note>
|
|
Every tier also has access to [Fleet-Wide Backups](/features/fleet-backups), which snapshot compose files across all nodes directly from the dashboard. This page covers lower-level backup of the Sencho instance itself.
|
|
</Note>
|
|
|
|
---
|
|
|
|
## What to back up
|
|
|
|
### 1. Data directory (`DATA_DIR`)
|
|
|
|
Default path: `/app/data` inside the container, mapped to wherever you mounted it on the host (e.g. `./sencho-data`).
|
|
|
|
Contains:
|
|
- `sencho.db` - SQLite database with all settings, users, nodes, alerts, metrics history, and notification config
|
|
- `encryption.key` - Key used to encrypt sensitive values (registry credentials, node API tokens) stored in the database
|
|
|
|
<Warning>
|
|
Both files are required for a full restore. If you restore `sencho.db` without the matching `encryption.key`, any encrypted values in the database will be unreadable and you will need to re-enter registry credentials and re-generate node API tokens.
|
|
</Warning>
|
|
|
|
### 2. Compose directory (`COMPOSE_DIR`)
|
|
|
|
The directory containing your stack subdirectories: your `compose.yaml` files, `.env` files, and any bind-mounted config files stored there.
|
|
|
|
This is your actual application data. It lives entirely outside Sencho and you almost certainly already back it up on a schedule, but include it in any Sencho backup plan.
|
|
|
|
---
|
|
|
|
## Backing up
|
|
|
|
### Simple file copy
|
|
|
|
```bash
|
|
# Stop Sencho to ensure no active transactions (recommended but not strictly required)
|
|
docker stop sencho
|
|
|
|
# Copy the data directory (includes both sencho.db and encryption.key)
|
|
cp -r /path/to/sencho-data /path/to/backup/sencho-data-$(date +%Y%m%d)
|
|
|
|
# Copy compose stacks
|
|
cp -r /opt/compose /path/to/backup/compose-$(date +%Y%m%d)
|
|
|
|
# Restart
|
|
docker start sencho
|
|
```
|
|
|
|
<Note>
|
|
Sencho uses SQLite's default journal mode (not WAL), so you will not see `-wal` or `-shm` sidecar files alongside `sencho.db`. If a `-journal` file exists when you copy, it indicates an interrupted write. SQLite will automatically resolve it the next time the database is opened.
|
|
</Note>
|
|
|
|
### SQLite online backup (without stopping)
|
|
|
|
SQLite supports hot backups via its `.backup` command. This is safe to run while Sencho is running:
|
|
|
|
```bash
|
|
sqlite3 /path/to/sencho-data/sencho.db ".backup '/path/to/backup/sencho.db'"
|
|
```
|
|
|
|
Remember to also copy `encryption.key` from the same directory.
|
|
|
|
### Automated daily backup (cron example)
|
|
|
|
```cron
|
|
0 3 * * * cp /path/to/sencho-data/encryption.key /backups/encryption.key && sqlite3 /path/to/sencho-data/sencho.db ".backup '/backups/sencho-$(date +\%Y\%m\%d).db'" && find /backups -name "sencho-*.db" -mtime +30 -delete
|
|
```
|
|
|
|
This copies the encryption key, backs up the database at 3 AM daily, and deletes database backups older than 30 days.
|
|
|
|
---
|
|
|
|
## Restoring
|
|
|
|
### Restore from backup
|
|
|
|
1. Stop Sencho:
|
|
```bash
|
|
docker stop sencho
|
|
```
|
|
|
|
2. Replace the data directory with your backup:
|
|
```bash
|
|
rm -rf /path/to/sencho-data/*
|
|
cp /path/to/backup/sencho.db /path/to/sencho-data/sencho.db
|
|
cp /path/to/backup/encryption.key /path/to/sencho-data/encryption.key
|
|
```
|
|
|
|
3. Restore your compose directory if needed:
|
|
```bash
|
|
cp -r /path/to/backup/compose /opt/compose
|
|
```
|
|
|
|
4. Start Sencho:
|
|
```bash
|
|
docker start sencho
|
|
```
|
|
|
|
Sencho will read the restored database and resume with all your previous settings, nodes, and alert rules intact.
|
|
|
|
---
|
|
|
|
## Migrating to a new host
|
|
|
|
### Step 1: Prepare the new host
|
|
|
|
Install Docker and Docker Compose on the new machine. Create the same directory structure you use for your compose files, following the [1:1 path rule](/getting-started/configuration#compose-directory-the-11-path-rule).
|
|
|
|
### Step 2: Copy data
|
|
|
|
Transfer your backup files to the new host:
|
|
|
|
```bash
|
|
scp -r /path/to/sencho-data newhost:/path/to/sencho-data
|
|
scp -r /opt/compose newhost:/opt/compose
|
|
```
|
|
|
|
### Step 3: Deploy Sencho on the new host
|
|
|
|
Use the same `docker-compose.yml` you used on the old host (with the same `COMPOSE_DIR` and `DATA_DIR` paths):
|
|
|
|
```bash
|
|
docker compose up -d
|
|
```
|
|
|
|
### Step 4: Update remote node references
|
|
|
|
If other Sencho instances were pointing to your old host as a remote node, update their node config to use the new host's IP or hostname. Generate a new API token on the restored instance and distribute it.
|
|
|
|
### Step 5: Verify
|
|
|
|
- Log in and confirm your stacks, nodes, and alerts are all present
|
|
- Check that at least one stack deploys correctly
|
|
- Verify the node switcher shows the expected nodes with green status
|
|
|
|
---
|
|
|
|
## What is NOT backed up by this process
|
|
|
|
| Item | Location | Notes |
|
|
|------|----------|-------|
|
|
| Container data volumes | Wherever each stack's volumes are mounted on the host | Back these up separately per-application |
|
|
| Actual container images | Docker image cache | These are re-pulled on next deploy; no backup needed |
|
|
| Sencho logs (docker logs) | Container stdout | Not persisted beyond container lifetime |
|