mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-10 02:41:14 +00:00
docs: comprehensive review and refresh of all documentation (#374)
* docs: comprehensive review and refresh of all documentation pages Reviewed every doc page against the current app state after the v0.38 dashboard redesign. Updated content, fixed inaccuracies, and refreshed all screenshots at 1920x1080. Pages updated: - introduction: expanded feature list to 25 items across 6 subsections - quickstart: fixed docker run command (Docker Hub, auto JWT, COMPOSE_DIR) - configuration: replaced personal paths with generic /home/user/docker - sso-quickstart: fixed Settings navigation reference - sso: added SSO_LDAP_DISPLAY_NAME env var - overview: added 8 missing feature sections (labels, API tokens, schedules, etc.) - dashboard: complete rewrite for new health bar, gauges, stack health table - stack-management: updated for UP/DN indicators, rollback button, split actions - editor: rewritten for two-column layout, inline stats, embedded terminal - resources: updated Quick Clean docs, added network topology and inspect - app-store: updated categories, deploy sheet details, permission gate, settings - openapi.yaml: fixed YAML parsing error on line 1831 Screenshots refreshed: 14 images across 6 feature areas. * docs: review and update observability, console, multi-node, and compatibility pages - Global Observability: fix log format fields, add download button docs, split display limits into memory buffer vs rendered rows, correct settings labels - Host Console: remove internal implementation details per security docs policy, add stack directory behavior, expand header bar docs, remove unverified scrollback claim - Multi-Node: add Compose Directory field, document connection test details panel, fix edit/delete node behavior, simplify token security section, remove internal details - Node Compatibility: add missing self-update capability, remove internal endpoint paths and cache TTL, move from Features to Reference group in navigation - Refresh all screenshots for the redesigned UI (7 images) * docs: review and refresh fleet, remote updates, labels, alerts, routing, and webhooks pages - Fleet View: added node updates modal, container detail, version/update/critical badges, Tags filter - Remote Updates: removed internal details, added capability cross-link, fast polling - Stack Labels: three creation methods, two assignment methods, 10 colors, bulk actions screenshot - Alerts & Notifications: fixed metric labels, added notification popover detail, status banner - Notification Routing: HTTPS requirement, rule card layout, channel terminology fix - Webhooks: corrected license tier to Admiral, matched action labels to UI, removed internal security details, added local-only note - Troubleshooting: centralized entries from remote-updates, stack-labels, notification-routing - Refreshed all screenshots at 1920x1080, removed 11 orphaned images * docs: review and refresh RBAC, user management, and atomic deployments pages - RBAC: added missing Auditor role (5th role), updated permission matrix, fixed license tier references, documented username/password validation rules, self-deletion protection - Atomic Deployments: added "Which operations are protected" section covering webhooks/schedules/app store, removed internal backup path, fixed license tier to Skipper/Admiral - Screenshots: cropped to dialog element per updated strategic cropping guideline, removed 2 orphaned images * docs: review and refresh fleet-wide backups and audit log pages Update fleet-backups page to reflect current inline create form, add scheduled snapshots section, document the detail view and restore dialog, expand RBAC table to all five roles. Update audit log page to document expanded row detail fields, pagination, refresh button, and data retention screenshot. Replace all screenshots with fresh captures at 1920x720. * docs: review and refresh API tokens and private registries pages - API Tokens: clarify Full Admin scope, add Managing tokens section with card details, document revocation confirmation dialog, add usage tracking to security model, refresh screenshot - Private Registries: add Managing registries section with card details and action buttons, document edit behavior, fix URL auto-fill description, remove encryption algorithm name per security policy, fix grammar, refresh both screenshots * docs: review and refresh auto-update policies, scheduled operations, and SSO pages - Auto-Update Policies: document all 8 table columns, expand action buttons, add "All Stacks" wildcard option, fix field labels, add CSV export and pagination details, refresh screenshots - Scheduled Operations: fix System Prune target description, add Task List table columns, restructure create dialog fields with action-specific annotations, rewrite execution history with column table, refresh screenshots - SSO: remove encryption algorithm name per security policy, add LDAP and OIDC configuration field tables, document provider card controls (Save, Test Connection, Remove, Active badge), refresh screenshots - Move SSO troubleshooting entries to centralized troubleshooting page * docs: review and refresh licensing & billing page Update upgrade card feature lists to match actual tier gating (Skipper: fleet view, webhooks, labels, atomic deployments, backups, auto-update policies; Admiral: scoped RBAC, SSO, audit log, host console, API tokens, private registries, scheduled operations). Add flex layout to align upgrade card buttons at the bottom. Replace stale screenshot with fresh community and active license captures. Add feature breakdown subsection and profile menu billing shortcut to docs. * docs: review and refresh settings reference and security advisories pages Settings Reference: add 5 missing sections (SSO, API Tokens, Registries, Labels, Routing), expand Users from 2 to 5 roles, fix System Limits and Developer field labels to match UI, restructure Developer into Streaming and Data Retention sub-tables, update App Store and Support sections, refresh overview screenshot. Security Advisories: restructure into versioned sections (v0.25.x hardening and v0.19-v0.24 CVE remediation), expand from 3 bullet points to 10 specific improvements, fix GitHub URL from SaelixCode to AnsoCode, redact internal details per security docs policy. Remove "Sencho Pro" product name from all three pages, replaced with tier names (Community, Skipper, Admiral). * docs: review and refresh troubleshooting page, remove architecture and development guides - Rewrote forgotten password section to remove exposed SQL and table names - Updated all Settings navigation paths to Profile > Settings > X - Fixed network topology from "tab" to "view mode", added Pro license note - Updated Prune Networks to current "Prune Dead Networks" label - Corrected update check cooldown from vague to 2 minutes - Consolidated two network creation error sections into one - Removed hardcoded version reference (v0.34.0) - Replaced em dashes throughout - Deleted architecture.mdx (exposes internal implementation details) - Deleted development.mdx (contributor guide belongs in repo, not public docs) - Removed both pages from docs.json navigation * docs: review and refresh operations pages (backup, upgrade, self-hosting, troubleshooting) Backup & Restore: - Added missing encryption.key to all backup/restore procedures - Added Warning about restoring db without matching encryption key - Added cross-reference to Fleet-Wide Backups for paid tiers - Removed false claim about no built-in backup scheduler - Updated cron example to include encryption key copy Upgrading Sencho: - Removed internal migration details (table names, column specs, encryption algorithm) - Replaced with high-level migration summary per security docs policy - Added encryption.key to pre-upgrade backup command - Updated version pinning example from 0.25.3 to 0.38.0 - Added Remote Updates cross-reference for Skipper/Admiral users Self-Hosting Best Practices: - Removed JWT_SECRET from env var table (auto-generated, not an env var) - Removed PORT from env var table (hardcoded to 3000, not configurable) - Added API_RATE_LIMIT to env var table (actually exists in code) - Fixed listen port description from "configurable" to "fixed" - Updated resource recommendations based on measured footprint audit - Removed su-exec reference (internal implementation detail) - Upgraded data directory Note to Warning with file names Troubleshooting: - Fixed "Pro features" heading to "Paid features" with correct tier names
This commit is contained in:
@@ -1,92 +0,0 @@
|
||||
---
|
||||
title: Architecture Overview
|
||||
description: System design, request flow, and deployment model.
|
||||
---
|
||||
|
||||
## System overview
|
||||
|
||||
Sencho is a self-contained application packaged as a single Docker container:
|
||||
|
||||
- **Frontend:** React 19 single-page application built with Vite and served as static files
|
||||
- **Backend:** Express.js (Node.js 22) REST API with WebSocket support
|
||||
- **Database:** SQLite via `better-sqlite3` — no external database required
|
||||
- **Container management:** Docker Engine API via the mounted Docker socket, plus Docker Compose CLI for stack operations
|
||||
|
||||
There are no external dependencies. No Redis, no PostgreSQL, no message queues. All state lives in a single SQLite file inside the data directory.
|
||||
|
||||
---
|
||||
|
||||
## Request flow
|
||||
|
||||
### Browser sessions
|
||||
|
||||
1. The browser loads the React SPA from the Express static file server
|
||||
2. The frontend makes API calls, including which node should handle each request
|
||||
3. The backend evaluates which node is targeted:
|
||||
- **Local node:** The request passes through authentication and hits the local route handler, which communicates with Docker via the mounted socket
|
||||
- **Remote node:** The request is securely proxied to the target Sencho instance with appropriate authentication
|
||||
4. The response flows back through the same path to the browser
|
||||
|
||||
### API token access
|
||||
|
||||
External integrations (CI/CD pipelines, scripts) authenticate with Bearer tokens instead of cookies. The same route handlers process both authentication methods — the middleware accepts JWT tokens from either cookies or the `Authorization` header.
|
||||
|
||||
---
|
||||
|
||||
## Authentication model
|
||||
|
||||
| Method | Used by | Token storage |
|
||||
|--------|---------|--------------|
|
||||
| HTTP-only cookie (JWT) | Browser sessions | Set by Express on login, sent automatically |
|
||||
| Bearer token (JWT) | API integrations, node-to-node proxy | Passed in `Authorization` header |
|
||||
|
||||
API tokens have scopes that restrict their access: `read-only`, `deploy-only`, or `full-admin`. Tokens are hashed before storage.
|
||||
|
||||
SSO is supported via LDAP, Google OIDC, GitHub OAuth, and Okta OIDC. SSO users are mapped to local accounts on first login.
|
||||
|
||||
---
|
||||
|
||||
## Database
|
||||
|
||||
Sencho stores all state in a single SQLite database — no external database required. The schema covers user identity, node configuration, automation rules, monitoring data, and security audit trails. Sensitive values (such as registry credentials and node tokens) are encrypted at rest.
|
||||
|
||||
All schema migrations run automatically on startup. See [Upgrading Sencho](/operations/upgrade#automatic-migrations) for details.
|
||||
|
||||
---
|
||||
|
||||
## Multi-node architecture
|
||||
|
||||
Sencho uses a **Distributed API** model for managing multiple hosts:
|
||||
|
||||
- **Local node:** Communicates directly with the Docker Engine via the mounted socket (`/var/run/docker.sock`)
|
||||
- **Remote nodes:** Each remote host runs its own independent Sencho instance. The primary instance acts as a transparent HTTP proxy, routing requests to remote instances using stored API URLs and long-lived JWT tokens
|
||||
|
||||
This means:
|
||||
- No SSH, SFTP, or remote Docker TCP socket connections
|
||||
- Each node is fully autonomous and can operate independently
|
||||
- The primary instance proxies both HTTP requests and WebSocket connections
|
||||
- Node routing is handled automatically by the frontend. API users can target a specific node using a request header or query parameter (see [API Overview](/api-reference/overview))
|
||||
|
||||
---
|
||||
|
||||
## WebSocket channels
|
||||
|
||||
| Path | Purpose | Auth |
|
||||
|------|---------|------|
|
||||
| `/api/stacks/{stackName}/logs` | Live container log streaming | Cookie or query param token |
|
||||
| `/ws` | Host console terminal (PTY) | Cookie-based, admin only |
|
||||
|
||||
WebSocket connections are authenticated during the upgrade handshake using the same JWT credentials as HTTP requests.
|
||||
|
||||
---
|
||||
|
||||
## Build and deployment
|
||||
|
||||
The Docker image uses a multi-stage build:
|
||||
|
||||
1. **Frontend build stage** — Compiles the React SPA with Vite
|
||||
2. **Backend build stage** — Compiles TypeScript to JavaScript
|
||||
3. **Native module stage** — Cross-compiles native dependencies (`bcrypt`, `better-sqlite3`, `node-pty`) for the target architecture
|
||||
4. **Production stage** — Alpine-based Node.js 22 runtime with Docker CLI and Docker Compose installed
|
||||
|
||||
The final image supports both `linux/amd64` and `linux/arm64` architectures and is published to [Docker Hub](https://hub.docker.com/r/saelix/sencho) as `saelix/sencho`.
|
||||
@@ -1,136 +0,0 @@
|
||||
---
|
||||
title: Development Guide
|
||||
description: Set up a local development environment and contribute to Sencho.
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **Node.js 22** or later
|
||||
- **Docker** and **Docker Compose** installed and running
|
||||
- **Git**
|
||||
|
||||
---
|
||||
|
||||
## Setup
|
||||
|
||||
```bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/AnsoCode/Sencho.git
|
||||
cd Sencho
|
||||
|
||||
# Install backend dependencies
|
||||
cd backend && npm install
|
||||
|
||||
# Install frontend dependencies
|
||||
cd ../frontend && npm install
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Running in development
|
||||
|
||||
Open two terminal windows:
|
||||
|
||||
**Terminal 1 — Backend** (Express + nodemon, port 3000):
|
||||
|
||||
```bash
|
||||
cd backend
|
||||
npm run dev
|
||||
```
|
||||
|
||||
**Terminal 2 — Frontend** (Vite dev server, port 5173):
|
||||
|
||||
```bash
|
||||
cd frontend
|
||||
npm run dev
|
||||
```
|
||||
|
||||
The Vite dev server proxies all `/api` and `/ws` requests to `localhost:3000`, so you access the app at `http://localhost:5173`.
|
||||
|
||||
On first boot, you'll see a setup screen to create an admin account.
|
||||
|
||||
<Note>
|
||||
The backend requires a Docker socket to be available. On macOS and Linux this is `/var/run/docker.sock`. On Windows, ensure Docker Desktop is running.
|
||||
</Note>
|
||||
|
||||
---
|
||||
|
||||
## Running tests
|
||||
|
||||
### Backend unit tests (Vitest)
|
||||
|
||||
```bash
|
||||
cd backend
|
||||
npm test
|
||||
```
|
||||
|
||||
Runs all test files in `src/__tests__/`. Each test file runs in an isolated forked process with its own database instance.
|
||||
|
||||
### End-to-end tests (Playwright)
|
||||
|
||||
```bash
|
||||
# From the project root
|
||||
npm run test:e2e
|
||||
```
|
||||
|
||||
E2E tests run against a live development instance (backend on port 3000, frontend on port 5173). Make sure both are running before executing tests.
|
||||
|
||||
For interactive test debugging:
|
||||
|
||||
```bash
|
||||
npm run test:e2e:ui
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Code style
|
||||
|
||||
- **TypeScript** with `strict: true` in both packages. No `any` casts or `@ts-ignore`.
|
||||
- **ESLint 9** flat config. Run `npm run lint` in both `backend/` and `frontend/` directories.
|
||||
- **Frontend styling:** Tailwind CSS with [shadcn/ui](https://ui.shadcn.com/) components. See the design system section in `CLAUDE.md` for color, typography, and component patterns.
|
||||
- **Backend patterns:** Express route handlers in `src/index.ts`, business logic in `src/services/`. All new endpoints must use `authMiddleware`. SQL must use parameterized queries.
|
||||
|
||||
---
|
||||
|
||||
## Pull request workflow
|
||||
|
||||
1. Create a branch from `main` (e.g. `feat/my-feature`, `fix/my-bug`)
|
||||
2. Use [Conventional Commits](https://www.conventionalcommits.org/) for all commit messages:
|
||||
- `feat:` — new user-facing feature (bumps minor version)
|
||||
- `fix:` — bug fix (bumps patch version)
|
||||
- `docs:` — documentation changes (no version bump)
|
||||
- `chore:`, `ci:`, `refactor:`, `test:`, `perf:` — internal changes (no version bump)
|
||||
3. Update `CHANGELOG.md` under `## [Unreleased]` for user-facing changes
|
||||
4. Update or create documentation in `/docs` if behavior changes
|
||||
5. Open a PR targeting `main`
|
||||
6. Ensure CI passes before requesting review
|
||||
|
||||
Keep PRs focused — one feature or fix per PR.
|
||||
|
||||
---
|
||||
|
||||
## Project structure
|
||||
|
||||
```
|
||||
Sencho/
|
||||
├── backend/ # Express.js API + Docker orchestration
|
||||
│ ├── src/
|
||||
│ │ ├── index.ts # Route definitions (monolithic)
|
||||
│ │ ├── services/ # Business logic (17 services)
|
||||
│ │ └── __tests__/ # Vitest unit tests
|
||||
│ └── package.json
|
||||
├── frontend/ # React 19 + Vite SPA
|
||||
│ ├── src/
|
||||
│ │ ├── components/ # UI components
|
||||
│ │ ├── context/ # React context providers
|
||||
│ │ ├── lib/ # Utilities (apiFetch, etc.)
|
||||
│ │ └── App.tsx # Root router
|
||||
│ └── package.json
|
||||
├── docs/ # Mintlify documentation site
|
||||
├── e2e/ # Playwright E2E test specs
|
||||
├── Dockerfile # Multi-stage production build
|
||||
├── docker-compose.yml # Quick-start deployment
|
||||
└── package.json # Root scripts (test, test:e2e)
|
||||
```
|
||||
|
||||
For more detail on how the components relate, see the [Architecture Overview](/reference/architecture).
|
||||
@@ -3,28 +3,61 @@ title: Security Advisories
|
||||
description: Tracked CVEs, remediation status, and dependency security notes for Sencho's Docker image.
|
||||
---
|
||||
|
||||
This page documents security-relevant changes across Sencho releases.
|
||||
This page documents security-relevant changes across Sencho releases. All fixes are applied automatically when you upgrade. No manual action is required unless stated otherwise.
|
||||
|
||||
## April 2026 — Application Security Hardening
|
||||
## April 2026 (v0.25.0 - v0.25.2) — Application Security Hardening
|
||||
|
||||
Version 0.25.2 includes application security hardening improvements:
|
||||
A comprehensive security audit was performed before the Sencho paid tiers launch. Versions 0.25.0 through 0.25.2 include the following hardening:
|
||||
|
||||
- **Stricter file permissions** on sensitive files in the data directory, with automatic correction on startup
|
||||
- **Stronger password requirements** aligned with [NIST SP 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) recommendations
|
||||
- **Reduced information disclosure** in application logs to prevent leaking sensitive details to logging aggregators
|
||||
### Input validation and path traversal
|
||||
|
||||
- **Path traversal prevention** in `env_file` resolution, preventing reads outside the compose directory
|
||||
- **Stack name validation** enforced on all routes, rejecting names with special characters or path components
|
||||
- **Global API rate limiting** to protect against brute-force and abuse
|
||||
|
||||
### Authentication and secrets
|
||||
|
||||
- **Stronger password requirements** aligned with [NIST SP 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) (minimum 8 characters, up from 6)
|
||||
- **1-year default expiry** on node proxy JWT tokens (previously issued without expiry)
|
||||
- **Stricter file permissions** (0600) on encryption key files, with automatic correction on startup
|
||||
- **NIST-recommended initialization vectors** for encryption (backward compatible with existing data)
|
||||
- **Pattern-based environment variable filtering** in the host console, blocking variables that contain sensitive keywords
|
||||
|
||||
### Information disclosure
|
||||
|
||||
- **Reduced log verbosity** to prevent leaking file paths, stack names, and admin usernames to logging aggregators
|
||||
- **CORS denied by default** when `FRONTEND_URL` is unset in production (previously allowed all origins)
|
||||
- **Webhook HMAC verification** now uses raw request bytes instead of re-serialized JSON
|
||||
|
||||
<Note>
|
||||
Users on versions prior to 0.25.2 should upgrade promptly. These improvements are applied automatically — no manual action is required.
|
||||
Users on versions prior to 0.25.0 should upgrade promptly. Existing passwords shorter than 8 characters remain valid until changed.
|
||||
</Note>
|
||||
|
||||
---
|
||||
|
||||
## March 2026 (v0.19.x - v0.24.0) — Dependency CVE Remediation
|
||||
|
||||
### Docker CLI and Compose upgrades
|
||||
|
||||
Sencho's Docker image bundles Docker CLI and Docker Compose as statically linked Go binaries. Vulnerabilities in Go's standard library or their Go dependencies surface as CVEs against the Sencho image even though Sencho itself contains no Go source code.
|
||||
|
||||
The following dependency upgrades resolved all known CVEs at time of release:
|
||||
|
||||
- **Docker CLI** upgraded to v29.3.1 (static binaries, replacing Alpine package)
|
||||
- **Docker Compose** upgraded from v2.40.3 to v5.1.1
|
||||
- **Node.js dependencies** updated via Dependabot and Docker Scout audit
|
||||
|
||||
### API token hardening (v0.19.x)
|
||||
|
||||
- **Scope enforcement** tightened on API tokens, blocking access to sensitive endpoints (license management, user administration)
|
||||
- **Token expiration** support added with configurable TTL
|
||||
|
||||
---
|
||||
|
||||
## Dependency Security
|
||||
|
||||
Sencho's Docker image bundles Docker CLI and Docker Compose as statically linked Go binaries. Vulnerabilities in Go's standard library or their Go dependencies surface as CVEs against the Sencho image even though Sencho itself contains no Go source code.
|
||||
|
||||
Sencho tracks and remediates these CVEs with each release. Dependency versions are pinned in the Dockerfile for reproducible builds and targeted remediation independent of Alpine's release cycle.
|
||||
Sencho tracks and remediates dependency CVEs with each release. Dependency versions are pinned in the Dockerfile for reproducible builds and targeted remediation independent of Alpine's release cycle.
|
||||
|
||||
<Note>
|
||||
If you need specific CVE details for compliance or audit purposes, refer to the [GitHub release notes](https://github.com/SaelixCode/sencho/releases) where each release documents dependency changes.
|
||||
If you need specific CVE details for compliance or audit purposes, refer to the [GitHub release notes](https://github.com/AnsoCode/Sencho/releases) where each release documents dependency changes.
|
||||
</Note>
|
||||
|
||||
+140
-44
@@ -3,7 +3,7 @@ title: Settings Reference
|
||||
description: Complete reference for every option in the Sencho Settings Hub.
|
||||
---
|
||||
|
||||
Open the Settings Hub by clicking the **Profile** icon in the top-right corner and selecting **Settings**. The left sidebar lists all available sections.
|
||||
Open the Settings Hub by clicking the **Profile** icon in the top bar and selecting **Settings**. The left sidebar lists all available sections. Some sections show a lock icon when they require a higher license tier.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/settings/settings-overview.png" alt="Settings Hub showing the Account tab and the full section sidebar" />
|
||||
@@ -31,25 +31,26 @@ Click **Update Password** to apply. The change takes effect immediately; existin
|
||||
|
||||
**Scope:** Global
|
||||
|
||||
Manage your Sencho Pro license from this section.
|
||||
Manage your Sencho license and subscription from this section.
|
||||
|
||||
| Element | Description |
|
||||
|---------|-------------|
|
||||
| **Current tier** | Shows whether you are on Community or Pro, with a tier badge |
|
||||
| **Current tier** | Shows your current tier (Community, Skipper, or Admiral) with a tier badge |
|
||||
| **Trial status** | If on a trial, shows remaining days |
|
||||
| **Customer / Plan / Key** | Displayed when a Pro license is active |
|
||||
| **Renews** | Next renewal date for active subscriptions |
|
||||
| **Upgrade cards** | Dynamic plan cards with feature highlights and direct Lemon Squeezy checkout links. Community users see Skipper and Admiral; Skipper users see Admiral only |
|
||||
| **Activate** | Enter a license key to activate Pro |
|
||||
| **Manage Subscription** | Opens the billing portal (active Pro only) |
|
||||
| **Deactivate License** | Reverts to Community features (active Pro only) |
|
||||
| **Upgrade cards** | Dynamic plan cards with feature highlights and checkout links. Community users see Skipper and Admiral; Skipper users see Admiral only |
|
||||
| **Activate** | Enter a license key to activate your plan (visible when no license is active) |
|
||||
| **Manage Subscription** | Opens the Lemon Squeezy billing portal (Skipper / Admiral only) |
|
||||
| **Deactivate License** | Reverts to Community features (Skipper / Admiral only) |
|
||||
|
||||
See [Licensing & Billing](/features/licensing) for the full walkthrough.
|
||||
|
||||
---
|
||||
|
||||
## Users
|
||||
|
||||
<Note>
|
||||
Users management requires a Sencho Pro license and admin role. Community Edition supports a single admin account only.
|
||||
User management requires a Sencho Skipper or Admiral license and admin role. Community supports a single admin account only.
|
||||
</Note>
|
||||
|
||||
**Scope:** Global
|
||||
@@ -58,37 +59,103 @@ Create and manage user accounts with role-based access.
|
||||
|
||||
| Action | Description |
|
||||
|--------|-------------|
|
||||
| **Create user** | Add a new account with username, password, and role (Admin or Viewer) |
|
||||
| **Create user** | Add a new account with username, password, and role |
|
||||
| **Edit user** | Change an existing user's password or role |
|
||||
| **Delete user** | Remove a user account |
|
||||
| **Delete user** | Remove a user account (you cannot delete your own account) |
|
||||
|
||||
**Available roles:**
|
||||
|
||||
| Role | Tier | Description |
|
||||
|------|------|-------------|
|
||||
| **Admin** | Skipper+ | Full access to all features |
|
||||
| **Viewer** | Skipper+ | Read-only access to stacks and nodes |
|
||||
| **Deployer** | Admiral | Can view stacks and trigger deployments |
|
||||
| **Node Admin** | Admiral | Full stack and node management, no system settings |
|
||||
| **Auditor** | Admiral | Read-only plus audit log access |
|
||||
|
||||
See [RBAC & User Management](/features/rbac) for details on what each role can access.
|
||||
|
||||
---
|
||||
|
||||
## SSO
|
||||
|
||||
<Note>
|
||||
SSO requires a Sencho Admiral license.
|
||||
</Note>
|
||||
|
||||
**Scope:** Global
|
||||
|
||||
Configure Single Sign-On providers (LDAP/AD and OIDC) for centralized authentication. Each provider type has its own configuration card with connection fields, a test button, and an active toggle.
|
||||
|
||||
See [SSO](/features/sso) for the full configuration walkthrough.
|
||||
|
||||
---
|
||||
|
||||
## API Tokens
|
||||
|
||||
<Note>
|
||||
API Tokens require a Sencho Admiral license.
|
||||
</Note>
|
||||
|
||||
**Scope:** Global
|
||||
|
||||
Create and manage long-lived API tokens for external integrations and automation. Tokens can be scoped to specific permissions.
|
||||
|
||||
See [API Tokens](/features/api-tokens) for the full walkthrough.
|
||||
|
||||
---
|
||||
|
||||
## Registries
|
||||
|
||||
<Note>
|
||||
Private Registries require a Sencho Admiral license.
|
||||
</Note>
|
||||
|
||||
**Scope:** Global
|
||||
|
||||
Configure private Docker registries so Sencho can pull images that require authentication.
|
||||
|
||||
See [Private Registries](/features/private-registries) for the full walkthrough.
|
||||
|
||||
---
|
||||
|
||||
## Labels
|
||||
|
||||
<Note>
|
||||
Stack Labels require a Sencho Skipper or Admiral license.
|
||||
</Note>
|
||||
|
||||
**Scope:** Global
|
||||
|
||||
Create, edit, and delete labels used to organize and filter stacks across your fleet. Each label has a name and one of ten available colors.
|
||||
|
||||
See [Stack Labels](/features/stack-labels) for the full walkthrough.
|
||||
|
||||
---
|
||||
|
||||
## System Limits
|
||||
|
||||
**Scope:** Per-node (applies to the currently selected node)
|
||||
|
||||
Configure resource thresholds that trigger visual warnings on the dashboard stat cards. These are display thresholds only - Sencho does not throttle or kill containers when limits are reached.
|
||||
Configure resource thresholds that trigger visual warnings on the dashboard stat cards. These are display thresholds only; Sencho does not throttle or kill containers when limits are reached. When viewing a remote node, a badge shows which node you are configuring.
|
||||
|
||||
| Setting | Range | Description |
|
||||
|---------|-------|-------------|
|
||||
| **Host CPU Limit** | 1-100% | CPU percentage above which the CPU card turns orange/red |
|
||||
| **Host RAM Limit** | 1-100% | RAM percentage above which the RAM card turns orange/red |
|
||||
| **Host Disk Limit** | 1-100% | Disk percentage above which the Disk card turns orange/red |
|
||||
| **Docker Janitor Threshold** | 0+ GB | Minimum free disk space to maintain. When free space falls below this value, a warning is shown. Set to `0` to disable. |
|
||||
| **Global Crash Alerts** | On / Off | When enabled, Sencho sends a notification whenever any managed container exits unexpectedly |
|
||||
| Setting | Default | Description |
|
||||
|---------|---------|-------------|
|
||||
| **Host CPU Alert Threshold** | 90% | CPU percentage above which the CPU card turns orange/red |
|
||||
| **Host RAM Alert Threshold** | 90% | RAM percentage above which the RAM card turns orange/red |
|
||||
| **Host Disk Alert Threshold** | 90% | Disk percentage above which the Disk card turns orange/red |
|
||||
| **Docker Janitor Storage Threshold** | 5 GB | Alert when unused Docker data (reclaimable via prune) exceeds this size. Set to `0` to disable. |
|
||||
| **Global Crash Detection** | On | Watch all containers for unexpected exits. When enabled, Sencho sends a notification whenever any managed container exits unexpectedly. |
|
||||
|
||||
Click **Save** to apply. An unsaved-changes indicator appears when you have edits pending.
|
||||
Click **Save Limits** to apply.
|
||||
|
||||
---
|
||||
|
||||
## Notifications
|
||||
|
||||
**Scope:** Global
|
||||
**Scope:** Per-node (each node has its own notification agents; remote nodes dispatch alerts through their own channels)
|
||||
|
||||
Configure external destinations for alert notifications. Three agent types are supported, each on its own sub-tab: **Discord**, **Slack**, and **Webhook**.
|
||||
Configure external destinations for alert notifications. Three agent types are available on separate tabs: **Discord**, **Slack**, and **Webhook**.
|
||||
|
||||
For each agent:
|
||||
|
||||
@@ -103,10 +170,24 @@ At least one agent must be enabled for stack alerts to deliver notifications. Se
|
||||
|
||||
---
|
||||
|
||||
## Routing
|
||||
|
||||
<Note>
|
||||
Notification Routing requires a Sencho Admiral license.
|
||||
</Note>
|
||||
|
||||
**Scope:** Global
|
||||
|
||||
Create routing rules that direct specific alert types to specific notification channels. Rules let you send critical alerts to one channel and informational alerts to another.
|
||||
|
||||
See [Notification Routing](/features/notification-routing) for the full walkthrough.
|
||||
|
||||
---
|
||||
|
||||
## Webhooks
|
||||
|
||||
<Note>
|
||||
Webhooks require a Sencho Pro license.
|
||||
Webhooks require a Sencho Skipper or Admiral license.
|
||||
</Note>
|
||||
|
||||
**Scope:** Global
|
||||
@@ -126,21 +207,29 @@ Quick reference:
|
||||
|
||||
## Developer
|
||||
|
||||
**Scope:** Per-node (applies to the currently selected node)
|
||||
**Scope:** Per-node (streaming and polling settings), Global (data retention)
|
||||
|
||||
Advanced settings for log streaming behaviour and data retention. Most users can leave these at their defaults.
|
||||
Advanced settings for log streaming behavior and data retention. Most users can leave these at their defaults.
|
||||
|
||||
### Streaming
|
||||
|
||||
| Setting | Default | Description |
|
||||
|---------|---------|-------------|
|
||||
| **Developer Mode** | Off | When on, the [Global Observability](/features/global-observability) view switches from polling to real-time Server-Sent Events streaming |
|
||||
| **Global Logs Refresh Rate** | 5s | Polling interval in standard mode. Options: `1s`, `3s`, `5s`, `10s` |
|
||||
| **Metrics Retention Hours** | 24 | How many hours of CPU/RAM history to keep for dashboard charts. Max: 8,760 (1 year) |
|
||||
| **Log Retention Days** | 30 | How many days of notification history to keep in the database. Max: 365 |
|
||||
| **Developer Mode** | Off | When on, the [Global Observability](/features/global-observability) view switches from polling to real-time SSE streaming |
|
||||
| **Standard Log Polling Rate** | 5s | Polling interval in standard mode. Options: `1s`, `3s`, `5s`, `10s`. Disabled when Developer Mode is on. |
|
||||
|
||||
Click **Save** to apply.
|
||||
### Data Retention
|
||||
|
||||
| Setting | Default | Max | Description |
|
||||
|---------|---------|-----|-------------|
|
||||
| **Container Metrics Retention** | 24 hrs | 8,760 (1 year) | How long to keep per-container CPU, RAM, and network history for dashboard charts |
|
||||
| **Notification Log Retention** | 30 days | 365 | How long to keep alert and notification history |
|
||||
| **Audit Log Retention** | 90 days | 365 | How long to keep audit trail entries (Admiral only) |
|
||||
|
||||
Click **Save Developer Settings** to apply.
|
||||
|
||||
<Note>
|
||||
Lower refresh rates (1s) increase backend CPU usage as Sencho polls Docker more frequently. Use only when actively debugging.
|
||||
Lower polling rates (1s) increase backend CPU usage as Sencho polls Docker more frequently. Use only when actively debugging.
|
||||
</Note>
|
||||
|
||||
---
|
||||
@@ -149,7 +238,7 @@ Click **Save** to apply.
|
||||
|
||||
**Scope:** Global
|
||||
|
||||
Manage connections to local and remote Sencho instances. This is the same interface as the [Multi-Node](/features/multi-node) feature - see that page for the full walkthrough.
|
||||
Manage connections to local and remote Sencho instances. This is the same interface as the [Multi-Node](/features/multi-node) feature; see that page for the full walkthrough.
|
||||
|
||||
Quick reference:
|
||||
|
||||
@@ -167,11 +256,15 @@ Quick reference:
|
||||
|
||||
**Scope:** Global
|
||||
|
||||
| Setting | Default | Description |
|
||||
|---------|---------|-------------|
|
||||
| **Template Registry URL** | LinuxServer.io registry | The URL Sencho fetches templates from. Must return a JSON array in Portainer v2 template format. Leave blank to restore the default. |
|
||||
Configure the template source used by the App Store.
|
||||
|
||||
Click **Save** to update the URL. Click **Refresh Cache** to clear the cached template list and fetch fresh data from the registry immediately.
|
||||
| Element | Description |
|
||||
|---------|-------------|
|
||||
| **Default Registry** | LinuxServer.io (used when no custom URL is set) |
|
||||
| **Custom Registry URL** | A URL pointing to a Portainer v2 compatible template JSON file. Overrides the default registry. Leave empty to use the default. |
|
||||
| **Reset to Default** | Clears the custom URL and reverts to LinuxServer.io |
|
||||
|
||||
Click **Save & Refresh** to update the URL and immediately refresh the cached template list.
|
||||
|
||||
See [App Store](/features/app-store#custom-template-registry) for more on custom registries.
|
||||
|
||||
@@ -181,24 +274,26 @@ See [App Store](/features/app-store#custom-template-registry) for more on custom
|
||||
|
||||
**Scope:** Global
|
||||
|
||||
Links to help resources available to all tiers, plus priority support channels for Pro users.
|
||||
Links to help resources, with additional channels for Skipper and Admiral users.
|
||||
|
||||
### Resources (all tiers)
|
||||
|
||||
| Resource | Description |
|
||||
|----------|-------------|
|
||||
| **Documentation** | Opens docs.sencho.io - guides, reference, and tutorials |
|
||||
| **Documentation** | Opens docs.sencho.io |
|
||||
| **GitHub Issues** | Report bugs and request features on GitHub |
|
||||
|
||||
### Pro support
|
||||
### Paid tier support
|
||||
|
||||
Pro license holders get additional support channels:
|
||||
Skipper and Admiral license holders see additional support channels:
|
||||
|
||||
| Channel | Description |
|
||||
|---------|-------------|
|
||||
| **Email Support** | Direct email support (Skipper) |
|
||||
| **Priority Email Support** | Responses within 24 hours (Admiral) |
|
||||
|
||||
Community users see an upgrade prompt with a link to the pricing page.
|
||||
|
||||
---
|
||||
|
||||
## About
|
||||
@@ -209,8 +304,9 @@ Displays instance information at a glance.
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Version** | Current Sencho version |
|
||||
| **Tier** | Community or Pro tier badge |
|
||||
| **Version** | Current Sencho version (e.g. v0.38.0) |
|
||||
| **Tier** | Community, Skipper, or Admiral badge |
|
||||
| **License Status** | Active, trial, expired, or community |
|
||||
| **Instance ID** | Unique identifier for this Sencho instance (shown when a license is active) |
|
||||
| **Changelog** | Link to the full changelog on GitHub |
|
||||
| **Instance ID** | Truncated unique identifier for this Sencho instance |
|
||||
|
||||
The **Links** section contains a link to the full changelog on GitHub.
|
||||
|
||||
Reference in New Issue
Block a user