mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-26 11:49:16 +00:00
docs: v1 docs refresh (#966)
* docs(introduction): rewrite intro page and refresh screenshots
Rewrite the Getting Started introduction to reflect the current product:
adds the Mesh, Blueprints, Pilot, Fleet, Resources concepts up front;
restructures capability sections around Stacks, Fleet (now including
Fleet Actions), Mesh, Blueprints, Monitoring, Resources, Security,
Automation, and Pilot/Remote ops; cross-links every claim to the
matching feature page.
Replaces the dashboard hero shot with a fresh capture against the
redesigned cockpit chrome and adds three inline shots (running stack
with anatomy and logs, fleet command deck, resources hub with
reclaim header). All screenshots taken at 1920x900, dark theme,
with node names, usernames, IPs, and home paths neutralized.
Drops outdated claims: stale "190+ templates" count, the
"viewer accounts" RBAC summary, and the "atomic" deployment label
that did not match the actual rollback mechanism.
* docs(introduction): add Federation and Fleet Secrets
Federation has shipped (Admiral) with cordon and pin policy as
operator overrides on the blueprint reconciler. Fleet Secrets is
landing as a Skipper+ tab for versioned env-var bundles encrypted
at rest, with diff preview and target push.
Mirror those in the Run-one-machine-or-many bullet list and in the
Tiers paragraph so the introduction matches the current product.
* docs(introduction): re-shoot screenshots against v0.72.0 production
Re-capture all four introduction screenshots from the upgraded
production node so the fleet view shows the current full tab strip
(Overview / Snapshots / Status / Deployments / Traffic / Federation
/ Fleet Actions / Secrets) instead of the older Overview / Snapshots
/ Status only. Same 1920x900 dark-theme capture and the same PII
scrub applied (node names, usernames, IPs, home paths neutralized).
* docs(quickstart): rewrite around v0.72.0 cockpit and add screenshots
Replaces the bare install snippet with a five-minute walkthrough that
matches the redesigned UI. Leads with a docker-compose.yml block (the
bare docker run command is collapsed in an Accordion), keeps the 1:1
path rule, and adds two new sections that show the user what happens
on first boot.
Adds two screenshots at 1920x900 dark theme:
- setup-cold-start.png: the Cold start card with Username, Password,
Confirm password fields, and the Initialize console button.
- dashboard.png: the post-sign-in dashboard captured against v0.72.0
with the full top nav (Home, Fleet, Resources, App Store, Logs,
Auto-Update, Console, Audit, Schedules) and the populated Stack
health table sorted by load.
Where-to-next now uses CardGroup cols=2 to match the introduction
page's pattern.
* docs(configuration): align env var reference with current backend
Bring docs/getting-started/configuration.mdx up to date with the
v0.72.0 backend:
- Remove PORT from the optional env vars table. The listen port is
hardcoded to 1852 in backend/src/helpers/constants.ts and is never
read from the environment. Replace it with a Listen port section
that explains the fixed port and host-port remapping.
- Document API_RATE_LIMIT (default 200) and API_POLLING_RATE_LIMIT
(default 300), both applied in production only.
- Note the /app/compose fallback default for COMPOSE_DIR while still
pointing readers at the 1:1 path rule.
- Point the SSO env var section at the new SSO Quickstart page and
keep the SSO feature reference as the deeper dive.
- Tighten First boot and cross-link to Quickstart so the screenshot
is not duplicated.
- Add a Where to next CardGroup matching the refreshed Introduction
and Quickstart pages.
Drop stale PORT=1852 and JWT_SECRET=your-secure-jwt-secret-here
lines from .env.example so the example no longer contradicts the
docs (PORT is hardcoded, JWT_SECRET is auto-generated and persisted
to the database during initial setup).
* docs(configuration): replace em-dash-substitute hyphens in prose
Three sentences used ` - ` (space-hyphen-space) as an em-dash
substitute. Replaced with the punctuation that fits each case:
- "How Sencho organizes your compose directory": semicolon between
the two related clauses.
- Data directory Warning: parentheses around the parenthetical
insertion.
- 1:1 path rule explanation: comma before the contrastive clause.
Heading slugs and YAML code-block comments are unchanged.
* docs(sso): refresh setup guide and drop misleading "one-click" wording
Brings the SSO Setup Guide in line with how SSO actually works in the
current build, and corrects misleading copy across both SSO docs pages.
- Setup Guide: explains the env-var-seeds-once / DB-is-authoritative
config model up front, replacing per-section "Restart Sencho"
wording that implied a restart was always required.
- Setup Guide: promotes the per-provider Test Connection button out
of the LDAP-only paragraph into a generic intro callout, and adds
a self-signed LDAPS tip.
- Setup Guide: notes that all OIDC providers accept a *_DISPLAY_NAME
override for the login button label, and adds a commented LDAP TLS
toggle to the full compose example.
- Setup Guide: adds two screenshots of the redesigned Settings > SSO
panel (overview + LDAP card expanded with form).
- Both pages: replaces "one-click presets" / "one-click configuration"
with "preset providers". The Skipper-tier presets still require an
OAuth app provisioned in the provider's console; what they actually
buy is provider-aware defaults and a branded login button. The old
wording overpromised.
* docs(features-overview): regroup catalog and add 17 missing features
Restructure the Features Overview into the same six groups the docs
sidebar uses (Stacks & Deployments, Observability, Fleet & Multi-Node,
Security & Identity, Automation, Platform) plus a short Reference tail.
Add catalog entries for 17 shipped features that the previous overview
never mentioned: Stack Activity, Stack File Explorer, Deploy Progress,
Deploy Enforcement, Blueprints, Git Sources, Global Search, Pilot Agent,
Sencho Mesh, Fleet Federation, Fleet Actions, Fleet Sync, Fleet Secrets,
Two-Factor Authentication, CVE Suppressions, Auto-Heal Policies, Stack
Sidebar.
Fix two factual inaccuracies:
- Fleet View blurb wrongly gated search, sort, filter, and stack
drill-down behind Skipper. The deep-dive is explicit that those are
available on every tier; only the bulk Update All action inside the
Node Updates modal is paid.
- Auto-update entry was titled and described as a scheduling system.
The deep-dive page is the Auto-Update Readiness board (risk tags,
changelog previews, rollback targets); the scheduler lives under
Scheduled Operations.
Add three hero screenshots captured from production at 1920x900,
illustrating the redesigned cockpit visual language: Home dashboard,
stack anatomy, and fleet topology.
* docs(stack-management): refresh page around v0.72.0 cockpit and add screenshots
Updates the Stack Management page to match the current UI: sidebar with
filter chips and label groups, bulk mode, restructured kebab menu,
two-tab anatomy panel, and three-source New stack dialog (Empty, From
Git, From Docker Run).
Adds sections for Filter chips, Pinned and label groups, and Bulk mode.
Restructures the Stack context menu around the inspect, organize,
lifecycle, and destructive groups with their keyboard shortcuts.
Documents the From Git tab and cross-links Git Sources for the full
sync flow.
Replaces every existing screenshot with fresh captures from the current
UI and adds eight new captures for the new sections. Cross-links Stack
Activity, Stack Labels, Stack File Explorer, Compose Editor, Atomic
Deployments, Scheduled Operations, Auto-Heal Policies, Auto-Update
Policies, and Alerts and Notifications for features documented on
their own pages.
* docs(stack-activity): refresh page around v1 cockpit and recapture screenshots
Realign the page with the current Anatomy panel tab strip and the
StackActivityTimeline component:
- Frame the Activity tab as a sibling of Anatomy under the right-hand
panel, with files/edit actions belonging to the strip.
- Expand the category guidance: list the five iconized categories and
call out that other stack-scoped notifications (deploy failure,
available image updates, auto-heal triggers, monitor alerts, scan
findings) flow into the timeline with a generic icon.
- Tighten the actor-attribution rule to match the component: omitted
for events without an actor and for system-driven events.
- Add the day-format example to the relative-time row.
- Recapture both screenshots from a populated stack (Today + Yesterday
+ Earlier with three distinct icons) and an empty stack.
- Convert troubleshooting blurbs to H3 for anchor links and consistency
with the v1-refresh sibling pages.
* docs(stack-activity): wrap troubleshooting entries in Accordion blocks
Match the foldable troubleshooting pattern established by
docs/features/deploy-progress.mdx so the page stays compact and
readers can scan to their issue. This is the canonical formatting
for the /features section's troubleshooting blurbs going forward.
* docs(editor): refresh page around v1 cockpit and recapture screenshots
Rewrites the page around the dual-mode right panel (Anatomy by default,
Monaco when the user clicks edit), the redesigned Command Center action
bar, the new container row layout with status badges and live stats, the
Structured / Raw terminal logs toggle, the Git Source toolbar button, and
the opt-in diff preview. Drops the obsolete persistent embedded terminal
section. Preserves the #diff-preview-before-save and #log-viewer anchors
referenced from settings.mdx and global-observability.mdx. Replaces
editor-overview.png and container-exec-modal.png with fresh captures
against v0.72.0 production at 1920x900 dark theme; renames container
-actions.png to containers-list.png; adds command-center.png and
editor-edit-mode.png. PII scrubbed (host paths normalized) and the
compose-diff-preview/diff-modal.png shared asset is left untouched after
visual diff against the live UI showed no chrome change.
* docs(features): wrap troubleshooting accordions in AccordionGroup
Wraps the loose <Accordion> blocks in editor.mdx and stack-activity.mdx
in a single <AccordionGroup> to match the troubleshooting design used
by fleet-federation.mdx. Structural only; no content changes.
* docs(stack-file-explorer): refresh page around v1 explorer and add screenshots
Full rewrite to match the live two-pane Files tab. Replaces the false
'Edit' toolbar flow with the read-only chip + always-on Save model,
fixes the protected-files list (5 names) and dedicated-tab redirect
list (3 names), drops the fabricated 100 MB download cap, and corrects
the upload claim to single file at a time.
Adds sections for New File, Rename, Permissions, the type-to-confirm
protected-file delete flow, the non-empty folder delete confirmation,
the 500-entry tree display cap, and the symlink rendering. Restructures
troubleshooting around <AccordionGroup> + <Accordion> to match
fleet-federation.mdx, and adds two new entries (display cap, 403 on
Community admin write).
Ships nine screenshots captured against v0.72.0 production at 1920x900
in dark theme: overview, two-pane layout, protected-tree-marker,
viewer-edit-mode, new-file-dialog, context-menu-folder, context-menu-file,
permissions-dialog, delete-protected-confirm.
* docs(deploy-progress): rewrite around current modal + capture v1 screenshots
Aligns the page with the v0.72.0 implementation and standardizes the
troubleshooting layout with the rest of the docs refresh.
Setting and gating
- Renames the Settings field to "Deploy progress modal" and quotes the
current helper text verbatim. Documents that the toggle is off by
default, lives under Settings > Appearance > Display, is stored in
localStorage, and syncs across tabs in the same browser.
Modal anatomy
- Names every visible UI string: header verbs, status indicator (with
the "closes in <n>s" countdown that was previously undocumented),
empty-body strings, footer toggle that flips between "Raw output" and
"Hide raw", and the destructive border on ERR rows vs the softer warn
tint on WARN rows.
- Replaces the vague "after a few seconds" with the actual 4-second
auto-close timer; documents hover-to-pause and the
leave-hover-restarts-the-countdown behavior.
- Documents the truncated error message in the failed-state header and
the manual close-only requirement.
- Notes that the pill is portal-mounted and survives navigation.
Stage badges
- Keeps the 9-badge table but adds an honest note that most lines render
as LOG because the badges are gated on Compose's "[+]" progress
prefix, which Compose only emits in TTY mode and Sencho spawns it
without one.
Entry points
- Splits the supported actions into the four that produce a populated
structured-log body (Deploy, Update, Install, Git Apply) and the two
that bypass compose and finish with 0 lines (Restart, Stop). Drops the
"Down" claim from the user-facing list since no UI control currently
triggers it; mentions the down route as an automation surface only.
Troubleshooting
- Wraps the existing accordions in an <AccordionGroup> matching the
pattern used by the editor and stack-activity refreshes. Adds two new
entries: one explaining the Restart/Stop "0 lines" outcome, one
explaining the LOG-everywhere case for non-TTY compose output.
Screenshots (six PNGs in docs/images/deploy-progress/, 1920x900, dark
theme, captured against the upgraded production node)
- setting-toggle.png: the Display section with the toggle enabled.
- modal-streaming.png: a real update in flight at 19s, 554 lines.
- modal-succeeded.png: succeeded state with the live closes-in
countdown visible.
- modal-raw-output.png: structured rows with the Raw output panel
expanded beneath.
- pill.png: minimized pill anchored bottom-center on a stack editor
view.
- modal-failed.png: failed state with the truncated error in the
header and ERR rows highlighted.
* docs(resources): refresh Resources Hub page for v1 redesign and feature additions
Rewrite the page to match the shipping UI and replace stale screenshots
with fresh captures of the redesigned chrome.
- Document the admin-only Reclaim hero and clarify the per-tile Sencho-only
vs. All Docker (includes external) split in Quick Clean.
- Add coverage of the Scan history toolbar button and the per-row severity
badge plus shield-icon scan dropdown in the Images tab; cross-link to the
vulnerability scanning page.
- Correct the Volumes column list (no Size column; size lives on the Largest
5 landing card) and call out admin gates on browse and delete.
- Spell out the List/Topology view-mode toggle and that Create Network is
admin-only and List-mode only.
- Rewrite the Unmanaged tab section around the project-grouped layout, the
Select all + Purge Selected (N) admin-only multi-select, and the empty
state copy.
- Replace screenshots: resources-reclaim, networks-list, create-network,
network-inspect, network-topology, network-topology-toggle. Add fresh
resources-volumes-tab and resources-unmanaged-tab captures.
* docs(app-store): refresh page around v1 deploy sheet, scan integration, and registry settings
Rewrites the App Store reference to match the current cockpit:
- Documents the weekly-rotated featured banner picked from the top-5 by GitHub stars and the star-descending grid sort.
- Adds the deploy-sheet structure (breadcrumb, meta line, About panel with Read more) and splits the Advanced tab into Ports, Volumes, Environment variables, Custom variables, and Security subsections.
- Documents the Trivy-gated Security checkbox, atomic vs non-atomic deploys by tier, and the rollback semantics driven by error class.
- Adds a Watching the deploy section linking to the deploy-progress modal.
- Rewrites the Custom registry section against the new two-panel settings layout (Default + Custom) with the URL validation rule and the using default / using custom hint.
- Adds a four-entry Accordion troubleshooting block in the house style.
- Replaces three screenshots and adds two (Advanced tab, Settings registry panel) captured against the production node.
Permissions wording aligns with current backend (admin only); the broader stack:create gate will land in a follow-up fix branch.
* docs(app-store): describe inline port-conflict messaging on deploy sheet
Update the deploy-sheet section to match the visible port-conflict
behavior: the Essentials tab surfaces a Port-conflict warning that
replaces the defaults hint when any default port is already bound, and
the Advanced tab shows an inline "in use by {stack}" message next to
the container port instead of a hover-only tooltip. Refresh the
screenshot alt-text and the troubleshooting Accordion to match.
* docs(app-store): align permissions note with stack:create gate
Pairs with the backend gate swap in fix/templates-deploy-rbac (#986)
which moves POST /api/templates/deploy from requireAdmin to
requirePermission('stack:create'). Updates the Note block under
'Watching the deploy' so the docs match the new behavior: admin and
node-admin can deploy templates from the App Store; viewer, deployer,
and auditor cannot.
This commit is contained in:
Anso
@@ -1,15 +1,9 @@
|
||||
# Sencho Configuration
|
||||
# Copy this file to .env and update the values for production
|
||||
|
||||
# JWT secret - generate a secure random string for production
|
||||
JWT_SECRET=your-secure-jwt-secret-here
|
||||
|
||||
# Directory containing docker-compose files
|
||||
COMPOSE_DIR=/path/to/your/compose/files
|
||||
|
||||
# HTTP server port (default: 1852)
|
||||
PORT=1852
|
||||
|
||||
# Database and state directory inside the container (default: /app/data)
|
||||
DATA_DIR=/app/data
|
||||
|
||||
|
||||
+105
-55
@@ -1,107 +1,157 @@
|
||||
---
|
||||
title: App Store
|
||||
description: Browse and deploy pre-configured application templates in one click.
|
||||
description: Browse a curated catalogue of Docker Compose templates and deploy any of them as a new stack with one click.
|
||||
---
|
||||
|
||||
The **App Store** tab lets you browse a curated catalogue of Docker Compose templates and deploy any of them as a new stack with environment-specific configuration, no YAML required.
|
||||
The **App Store** is a browseable catalogue of Docker Compose templates. Each template is a turn-key recipe with sensible defaults for ports, volumes, and environment variables, so you can stand up a new stack without writing YAML. Pick a tile, fill in a name, click **Deploy** and Sencho creates the directory, generates `compose.yaml` and `.env`, runs `docker compose up -d`, and switches you to the editor for the new stack.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/app-store/app-store-hero.png" alt="App Store with a category sidebar, a featured template hero banner, and editorial tiles with security scan badges" />
|
||||
<img src="/images/app-store/app-store-hero.png" alt="App Store with the categories rail on the left, a featured template hero pinned at the top, and a grid of editorial tiles with per-tile scan badges" />
|
||||
</Frame>
|
||||
|
||||
## Browsing templates
|
||||
|
||||
Templates are loaded from a remote registry (configurable in **Settings > App Store**). The default registry is LinuxServer.io. A live count of available apps is shown in the top right of the view.
|
||||
Templates load from a remote registry. The default registry is **LinuxServer.io**; you can point Sencho at any [Portainer v2 compatible JSON catalogue](#custom-template-registry) instead.
|
||||
|
||||
**Search:** Type in the search bar to filter templates by name, description, or category in real-time.
|
||||
### Search and counts
|
||||
|
||||
**Category sidebar:** The left rail lists every category with its count. Click a category to narrow the grid. The active category is highlighted with a cyan rail and tinted background.
|
||||
The search bar at the top filters tiles by name, description, or category in real time. The chip on the right shows the number of templates currently visible (for example, `201 apps`).
|
||||
|
||||
**Featured hero:** A featured template is pinned at the top of the grid with its logo, title, description, and a primary **Deploy** button. The hero disappears while you have an active search query.
|
||||
### Categories rail
|
||||
|
||||
The left rail lists every category the registry exposes, plus an **All** entry, with a count for each. The active category gets a brand-coloured rail and tinted background. The rail appears once at least one template has loaded.
|
||||
|
||||
### Featured template
|
||||
|
||||
A single template is pinned to the top of the grid in a wide editorial banner. Sencho rotates the featured pick **weekly** through the five most-starred templates in the registry, so the catalogue stays fresh without you doing anything. The banner disappears whenever you have a search query active.
|
||||
|
||||
### Tiles
|
||||
|
||||
Each tile shows:
|
||||
- A brand-tinted logo square (falls back to the first letter of the template name)
|
||||
- Name and first-sentence pitch
|
||||
- GitHub star count and primary category
|
||||
- A **security scan badge** on the right: `CLEAN` (no CVEs detected), `{n} CVE(s)` (amber, open vulnerabilities), or `UNSCANNED` (no scan recorded yet)
|
||||
|
||||
- A brand-tinted logo (falls back to a generic icon when the registry has no artwork)
|
||||
- The template name and the first sentence of its description
|
||||
- A GitHub star count (when the registry provides one)
|
||||
- The primary category
|
||||
- A **scan badge** on the right, derived from Sencho's vulnerability scanner:
|
||||
- **Clean** (no CVEs detected on the most recent scan)
|
||||
- **{N} CVE** or **{N} CVEs** (the count of open vulnerabilities, in amber)
|
||||
- **Unscanned** (no scan has been recorded for this image yet)
|
||||
|
||||
Tiles are sorted by GitHub star count, descending. Click any tile to open the deployment sheet on the right.
|
||||
|
||||
## Deploying a template
|
||||
|
||||
Click any tile to open the **deployment sheet** on the right side of the screen. The sheet splits configuration into two tabs: **Essentials** for a fast one-click deploy and **Advanced** for full control over ports, volumes, and environment.
|
||||
The deployment sheet slides in from the right. The header carries a breadcrumb (`App store › <template>`), the template name in the cockpit display face, and a meta line that combines the supported architectures, the GitHub star count, and the target node name when you are deploying to a remote node.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/app-store/deploy-sheet-essentials.png" alt="Deployment sheet opened on the Essentials tab, showing the stack name field and a deploy-with-defaults hint" />
|
||||
</Frame>
|
||||
### About
|
||||
|
||||
The sheet header displays the app logo, title, and a truncated description with a **Read more** / **Read less** toggle. Below the description you may see:
|
||||
|
||||
- **Architecture badges** (e.g. `amd64`, `arm64`) when the template declares supported platforms
|
||||
- **GitHub stars** count
|
||||
- **Source** link to the GitHub repository
|
||||
- **Docs** link to the official documentation
|
||||
|
||||
When deploying to a remote node, a badge at the top of the sheet shows the target node name.
|
||||
The first section is a description block with the template logo, the full description, a **Read more** / **Read less** toggle, and a row of secondary metadata: architecture chips (for example `amd64`, `arm64`), GitHub stars, a **Source** link to the template's repository, and a **Docs** link to the project's official documentation when the registry provides one.
|
||||
|
||||
### Essentials tab
|
||||
|
||||
The **Essentials** tab has a single field (the stack name) plus a hint that the template's recommended ports, volumes, and environment variables will be used as-is. Click **Deploy {template}** to ship it in one click. For anything more nuanced, switch to **Advanced**.
|
||||
The **Essentials** tab is intentionally minimal: a single **Stack Name** field and a hint that the template's defaults will be used as-is. Click **Deploy {template}** to ship it.
|
||||
|
||||
### Stack name
|
||||
<Frame>
|
||||
<img src="/images/app-store/deploy-sheet-essentials.png" alt="Deployment sheet open on the Essentials tab, showing the App store breadcrumb, the template hero, an About panel with Read more, the Stack Name field pre-filled with the template slug, and the Deploy with defaults hint card" />
|
||||
</Frame>
|
||||
|
||||
Pre-filled with the template name in lowercase. You can change it; the same [naming rules](/features/stack-management#creating-a-stack) apply (lowercase, hyphens, no spaces).
|
||||
The stack name pre-fills with the template slug (lowercased, hyphens, no spaces). You can change it; the same [naming rules](/features/stack-management#creating-a-stack) apply.
|
||||
|
||||
If any of the template's default ports are already bound on the active node, the Essentials hint card is replaced by a **Port conflict** warning that lists each conflicting port and the application using it, with a pulsating amber accent. Switch to **Advanced** to remap the host port before deploying.
|
||||
|
||||
For anything beyond the defaults, switch to **Advanced**.
|
||||
|
||||
### Advanced tab
|
||||
|
||||
The **Advanced** tab exposes every knob the template declares: port mappings, volumes, environment variables, custom key/value pairs, and the post-deploy vulnerability scan toggle. Fields on this tab are pre-populated with the template's defaults, so customizing is additive rather than required.
|
||||
|
||||
### Ports
|
||||
|
||||
For each exposed port, the sheet shows an editable **host port** field (left side) and the fixed **container port** (right side). Edit the host port to avoid conflicts with other services on the same machine. Ports must be in the valid range (1 to 65535); invalid values are highlighted and block deployment.
|
||||
|
||||
If a host port is already in use by a running container, a pulsating warning dot appears next to the port. Hover over the dot to see which application is using the port. If the application is managed by Sencho, the stack name is shown; otherwise the indicator reads "used by an external app".
|
||||
The **Advanced** tab exposes every knob the template declares. Every field is pre-populated with the template's recommended value, so customisation is additive rather than required.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/app-store/app-store-port-conflict.png" alt="Port conflict indicator showing port 8080 is used by heimdall" />
|
||||
<img src="/images/app-store/deploy-sheet-advanced.png" alt="Deployment sheet on the Advanced tab for radarr, showing Ports with a host port input, Volumes with three container mount points and editable host paths, and Environment Variables with PUID and PGID defaults" />
|
||||
</Frame>
|
||||
|
||||
### Volumes
|
||||
#### Ports
|
||||
|
||||
For each container mount point, enter the **host path** where that data should be stored. Suggested defaults (e.g. `./config`, `./data`) are pre-filled.
|
||||
Each declared port shows an editable **host port** on the left and the fixed **container port** on the right. Host ports must be integers between 1 and 65535; invalid values are highlighted and block deployment.
|
||||
|
||||
When the host port you typed is already in use somewhere on the active node, an inline amber **`in use by {stack}`** message appears next to the container port, alongside a pulsating amber dot. The message names the offending stack when Sencho manages it, or reads `in use by an external app` when the binding belongs to a process outside Sencho.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/app-store/app-store-port-conflict.png" alt="Port conflict indicator on the radarr deploy sheet: an inline amber message names the stack already using port 7878, next to a pulsating warning dot" />
|
||||
</Frame>
|
||||
|
||||
#### Volumes
|
||||
|
||||
For each container mount point the template declares, type the **host path** where that data should live. Sencho pre-fills sensible defaults like `./config` or `./data`.
|
||||
|
||||
<Note>
|
||||
Relative paths like `./config` are resolved relative to the stack directory inside your `COMPOSE_DIR`. Absolute paths map directly to the host filesystem.
|
||||
Relative paths such as `./config` resolve against the new stack's directory inside `COMPOSE_DIR`. Absolute paths map directly onto the host filesystem.
|
||||
</Note>
|
||||
|
||||
### Environment variables
|
||||
#### Environment variables
|
||||
|
||||
Each template declares the variables it needs. Sencho pre-fills sensible defaults where available (e.g. `PUID=1000`, `PGID=1000`, `TZ` from your browser locale). Edit any value before deploying.
|
||||
Each template declares the variables it expects. Sencho pre-fills sensible defaults where it can, and adds three baseline LinuxServer.io conventions automatically when the template does not already define them: **PUID** (`1000`), **PGID** (`1000`), and **TZ**, seeded from your browser's reported timezone.
|
||||
|
||||
### Custom variables
|
||||
#### Custom variables
|
||||
|
||||
Below the template variables, an **Add Custom Variable** section lets you define arbitrary key-value pairs not declared by the template. Type a key and value, then click **+** to add it. If you add a key that already exists in the template defaults, a warning will let you know your custom value will override the default.
|
||||
The **Custom variables** block lets you add arbitrary key/value pairs that the template did not declare. Type a key and value, then click **+** to add it. If you add a key that already exists in the template defaults, a toast warns you that your custom value will override the default (`"{KEY}" already exists in template defaults. The custom value will override it.`).
|
||||
|
||||
### What happens on Deploy
|
||||
#### Security
|
||||
|
||||
1. Sencho creates a new stack directory in `COMPOSE_DIR`
|
||||
2. Writes the generated `compose.yaml` (and `.env` file if environment variables are configured)
|
||||
3. Runs `docker compose up -d`
|
||||
4. On success: switches you to the Editor view for that stack
|
||||
5. On failure: rolls back by running `docker compose down` and deleting the stack directory
|
||||
When [vulnerability scanning](/features/vulnerability-scanning) is configured on the active node, a **Security** section appears at the bottom of the Advanced tab with a single checkbox: **Scan images for vulnerabilities after deploy**. The checkbox is on by default. Leave it on to queue a Trivy scan against every image the new stack pulls. The scan runs in the background once the stack is up; results land on the per-image severity badges in the [Resources Hub](/features/resources) and open the [scan results drawer](/features/vulnerability-scanning#the-scan-results-drawer) when clicked.
|
||||
|
||||
A toast notification confirms success or shows the error message. Large images may take a few minutes to pull.
|
||||
The Security section is hidden entirely when Trivy is not available on the node.
|
||||
|
||||
If a previous stack with the same name was removed outside of Sencho (for example, through the Docker CLI or Docker Desktop), the leftover directory is cleaned up automatically and the deploy proceeds as normal.
|
||||
## What happens on Deploy
|
||||
|
||||
Clicking **Deploy** runs the following sequence:
|
||||
|
||||
1. **Pre-flight name check.** Sencho asks the active node whether a stack of that name already exists. If it does, you get an immediate error toast and nothing else happens.
|
||||
2. **Directory creation.** A new directory is created under `COMPOSE_DIR/<stack-name>` on the active node.
|
||||
3. **File generation.** Sencho writes `compose.yaml` (rendered from the template, with your port and volume overrides) and a `.env` file (when you configured environment variables).
|
||||
4. **Policy gate.** Any [deploy-enforcement policies](/features/deploy-enforcement) configured on the node run against the generated compose. If a rule blocks the deploy, the directory is cleaned up and you get the rule's reason.
|
||||
5. **`docker compose up -d`.** On Skipper and Admiral the deploy is **atomic**: any container that fails to start triggers an automatic rollback to the previous state. On Community the deploy is non-atomic.
|
||||
6. **Outcome.**
|
||||
- On success, you are switched to the editor for the new stack and a success toast confirms the deploy.
|
||||
- On failure, Sencho parses the error. Most failures (image pull, port collision, volume permission, compose validation) trigger a clean rollback: the stack is brought down and the directory is removed. A small set of failures that point to live containers (for example, a startup that crashes after the container is running) leave the stack on disk so you can inspect it. The error toast tells you which.
|
||||
|
||||
## Watching the deploy
|
||||
|
||||
Sencho can stream the live `docker compose` output for every template install. Open **Settings › Appearance › Display** and enable **Deploy progress modal**; from then on, every App Store deploy opens a structured log modal you can minimise to a pill that follows you across navigation. See [Deploy Progress Modal](/features/deploy-progress) for the full reference.
|
||||
|
||||
<Note>
|
||||
Deploying a template requires the `stack:create` permission. Users without this permission will see the Deploy button disabled.
|
||||
Deploying a template requires the `stack:create` permission on the target node, which **admin** and **node-admin** roles hold by default. The Deploy button stays disabled when your account does not have it.
|
||||
</Note>
|
||||
|
||||
## Custom template registry
|
||||
|
||||
By default Sencho uses the LinuxServer.io template registry. To use your own:
|
||||
By default Sencho uses LinuxServer.io's hosted catalogue. To point at your own:
|
||||
|
||||
1. Open **Settings > App Store**
|
||||
2. Enter your registry URL (must serve a JSON array of template objects in Portainer v2 format)
|
||||
3. Click **Save & Refresh**
|
||||
<Frame>
|
||||
<img src="/images/app-store/app-store-settings-registry.png" alt="Settings · Advanced · App Store with two panels: Default registry showing LinuxServer.io and the api.linuxserver.io/api/v1/images URL, and Custom registry with a Registry URL input, a 'using default' hint, and Reset to default and Save & refresh buttons" />
|
||||
</Frame>
|
||||
|
||||
Sencho saves the new URL and automatically refreshes the template cache from the new source. To revert to the default registry, click **Reset to Default**.
|
||||
1. Open **Settings › Advanced › App Store**.
|
||||
2. Type your catalogue URL into **Registry URL**. The URL must start with `http://` or `https://` and serve a JSON array of template objects in the [Portainer v2 template format](https://documentation.portainer.io/v2.0-be/api/templates/).
|
||||
3. Click **Save & refresh**. Sencho persists the new URL and immediately invalidates the template cache so the App Store reloads from the new source.
|
||||
|
||||
A small chip under the input reads **using custom registry** when an override is set and **using default** when the field is empty. Click **Reset to default** to clear the override and fall back to LinuxServer.io.
|
||||
|
||||
The default registry display at the top of the page is informational only; you cannot remove the LinuxServer.io fallback, and Sencho uses it whenever the custom field is empty.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="No tiles appear">
|
||||
Sencho fetches templates from the configured registry on demand. If the grid stays empty and the loading spinner is gone, the registry returned an empty list or the request failed before parsing. Open **Settings › Advanced › App Store** and confirm the **Registry URL** is reachable from the node (try the URL in a browser tab); a custom catalogue served from a private host will not load if the Sencho container cannot resolve or reach it. Click **Save & refresh** to invalidate the cache and try again. If you switched to a custom registry by mistake, click **Reset to default**.
|
||||
</Accordion>
|
||||
<Accordion title="The port-conflict warning will not clear">
|
||||
The conflict indicator is computed against a snapshot of the node's bound ports taken when you opened the deployment sheet. If you freed the port from another stack while the sheet was open, the warning does not refresh on its own. Close the sheet and reopen it to recompute, or pick a different host port. The message `in use by an external app` means a process outside Sencho holds the binding (often the host's reverse proxy or a system service); changing the host port is usually faster than tracking down the offender.
|
||||
</Accordion>
|
||||
<Accordion title="Deploy failed but the stack directory remains">
|
||||
Sencho rolls back the directory only when the failure points cleanly at template generation, image pull, or first-time container creation. Failures that involve a container that did manage to start (for example, a crashloop after Compose returned success, or a healthcheck that flapped) leave the stack on disk so you can read the logs and decide whether to fix forward. The error toast tells you which path was taken; the response also carries a `rolledBack` flag and a `ruleId` you can search for in the [audit log](/features/audit-log). Use the editor to repair the compose, or delete the stack from the cockpit if you want to retry from scratch.
|
||||
</Accordion>
|
||||
<Accordion title="The Security checkbox is missing from the Advanced tab">
|
||||
The **Scan images for vulnerabilities after deploy** checkbox renders only when the active node reports that Trivy is installed. Configure scanning per the [Vulnerability Scanning](/features/vulnerability-scanning) page, then reopen the deployment sheet. Even with the checkbox missing, the rest of the Advanced tab works exactly the same; you just lose the post-deploy scan trigger.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@@ -3,77 +3,111 @@ title: Deploy Progress Modal
|
||||
description: Stream live output from stack deploy, install, update, restart, and stop operations in a structured log view.
|
||||
---
|
||||
|
||||
When you trigger a stack action (Deploy, Install, Update, Stop, Restart, or Down), an optional progress modal opens and streams structured output from `docker compose` in real time. Each line is parsed into a timestamped row with a stage badge (PULL, BUILD, CREATE, START, STOP, etc.) so you can track the deployment lifecycle as it runs.
|
||||
When you trigger a stack action that runs through `docker compose` (Deploy, Update, Install from the App Store, Apply with deploy from a Git Source), an optional progress modal opens and streams the output in real time. Each line is parsed into a timestamped row with a stage badge so you can track the deployment lifecycle as it runs. The modal can be minimized to a small pill that follows you across navigation, so you can leave the App Store mid-install and still see the status from any screen.
|
||||
|
||||
## Enabling deploy progress
|
||||
|
||||
The modal is opt-in. Go to **Settings > Appearance** and enable **Show deploy progress modal**. The setting is saved per browser and takes effect immediately without a reload.
|
||||
The modal is opt-in. Open **Settings > Appearance > Display** and enable **Deploy progress modal**. The setting is **off by default**, saved to the current browser only, and synced across tabs in the same browser without a reload.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/deploy-progress/setting-toggle.png" alt="Settings · Identity · Appearance panel with the Deploy progress modal field toggled to Enabled and the helper text 'Stream live output for deploy, restart, update, install, and Git operations.'" />
|
||||
</Frame>
|
||||
|
||||
## Using the modal
|
||||
|
||||
The modal opens automatically when you trigger an action. It stays centered on screen and does not block access to the rest of the UI.
|
||||
The modal opens automatically when you trigger an action. It floats centered in the viewport and does not block access to the rest of the UI.
|
||||
|
||||
### What the modal shows
|
||||
|
||||
- A **header** with the action name, stack name, and elapsed time
|
||||
- A **status indicator** showing the current state (Connecting, streaming line count, Succeeded, or the error message)
|
||||
- A **structured log body** with one row per output line, each tagged with a stage badge and timestamp
|
||||
- A **footer** with a "Raw output" toggle and minimize/close controls
|
||||
- **Header**: the action verb (Deploying, Updating, Installing, Restarting, Stopping), the stack name in monospace truncated at 200 px, and an elapsed-time chip that appears once the connection moves past the initial **Connecting...** state.
|
||||
- **Status indicator** in the upper right: one of `Connecting...` while the stream attaches, a live `<n> lines` counter while output is flowing, `Succeeded · closes in <n>s` after a clean finish, or the failure message itself when the run errors out.
|
||||
- **Structured log body**: one row per output line. Each row carries a timestamp, a fixed-width stage badge, and the log message. Error rows have a destructive left border and tinted background so they stand out without scanning.
|
||||
- **Footer**: a `Raw output` / `Hide raw` toggle on the left, with **Minimize** and **Close** buttons on the right.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/deploy-progress/modal-streaming.png" alt="Deploy progress modal mid-flight, showing the elapsed timer, a live line count in the header, and a populated body of timestamped LOG rows from a docker compose pull" />
|
||||
</Frame>
|
||||
|
||||
### Stage badges
|
||||
|
||||
Each log row carries a badge indicating what phase of the operation it came from:
|
||||
Each log row is classified by content. Most lines render as **LOG** because the badges are gated on Docker Compose's `[+] Pulling` / `[+] Creating` / `[+] Starting` progress prefixes, which only appear when Compose is run in TTY mode. The full set of badges Sencho can render:
|
||||
|
||||
| Badge | Meaning |
|
||||
|-------|---------|
|
||||
| PULL | Image layer being fetched from a registry |
|
||||
| BUILD | Image build step running |
|
||||
| CREATE | Container being created |
|
||||
| START | Container starting |
|
||||
| STOP | Container stopping |
|
||||
| DOWN | Container or network being removed |
|
||||
| WARN | Warning from Docker or compose |
|
||||
| ERR | Error line |
|
||||
| LOG | General output |
|
||||
| PULL | Image layer being fetched (`[+] Pulling` or `Pulling from`) |
|
||||
| BUILD | Image build step (`[+] Building`) |
|
||||
| CREATE | Container being created (`[+] Creating`) |
|
||||
| START | Container starting (`[+] Starting`) |
|
||||
| STOP | Container stopping (`[+] Stopping` / `[+] Stopped`) |
|
||||
| DOWN | Container or network being removed (`[+] Removing` / `[+] Removed`) |
|
||||
| WARN | Daemon warning line (prefix `WARN[`) |
|
||||
| ERR | Error line (`Error response from daemon` or text starting with `error`) |
|
||||
| LOG | Default for any line that does not match the patterns above |
|
||||
|
||||
Error rows have a rose left border and a tinted background so they stand out without requiring a full scan of the log.
|
||||
**ERR** rows pick up the destructive left border and the tinted background. **WARN** rows use a softer warning tint without the border.
|
||||
|
||||
### Raw output toggle
|
||||
|
||||
Click **Raw output** in the footer to reveal the raw terminal view alongside the structured rows. This is useful when you want to see the full unprocessed Docker output, including progress bars and multi-line build steps that the parser collapses to single rows.
|
||||
Click **Raw output** in the footer to expand a 200 px raw terminal panel beneath the structured rows. The raw view shows the unprocessed compose stream, including the progress bars and ANSI-formatted output that the structured parser does not render. Clicking the toggle a second time (now labelled **Hide raw**) collapses the panel.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/deploy-progress/modal-raw-output.png" alt="Deploy progress modal with the Raw output panel expanded, showing structured rows above and the green-on-black raw terminal stream below" />
|
||||
</Frame>
|
||||
|
||||
### Auto-close on success
|
||||
|
||||
When an action completes successfully, the modal closes automatically after a few seconds. Hover over the modal to pause the timer. Click the close button to dismiss it immediately.
|
||||
When an action completes successfully, the status indicator switches to `Succeeded · closes in <n>s` and a 4-second countdown begins. Hover anywhere over the modal to pause the countdown; moving the cursor away restarts a fresh 4 seconds. Clicking **Close** dismisses the modal immediately.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/deploy-progress/modal-succeeded.png" alt="Deploy progress modal in the succeeded state with a green checkmark, the text 'Succeeded' and 'closes in 2s' in the header, and the full structured log body visible beneath" />
|
||||
</Frame>
|
||||
|
||||
### On failure
|
||||
|
||||
If the action fails, the modal stays open and highlights the error row in the log. The status indicator shows the error message. The modal remains open until you close it manually.
|
||||
If the action fails, the modal stays open. The status indicator switches to a destructive icon and shows the error message itself, truncated to 200 px in the header with the full text available on hover. Error rows in the body pick up the destructive left border so they are easy to find when scrolling. The modal stays open until you click **Close**.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/deploy-progress/modal-failed.png" alt="Deploy progress modal in the failed state, with the truncated error message visible in the header and several ERR rows highlighted with a destructive border in the body" />
|
||||
</Frame>
|
||||
|
||||
### Minimize to pill
|
||||
|
||||
Click **Minimize** to collapse the modal to a small status pill anchored at the bottom center of the screen. The pill shows the action and stack name with a color-coded status dot (cyan pulse for in-progress, green for success, rose for error). Click the pill to expand the modal back.
|
||||
Click **Minimize** to collapse the modal to a small status pill anchored at the bottom center of the viewport. The pill shows the action verb, the stack name in monospace, and a status dot that animates while the run is in flight (brand color, pulsing) and goes solid green or red at completion. Click the pill to expand the modal back.
|
||||
|
||||
The pill survives navigation, so you can leave the App Store page mid-install and still see the status from any screen.
|
||||
The pill is mounted as a portal, so it persists across navigation: leave the App Store mid-install and the pill follows you to the dashboard, the editor, or any other view.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/deploy-progress/pill.png" alt="Minimized deploy progress pill anchored at the bottom center of a stack editor view, showing the brand-colored pulsing dot and the text 'Updating docs-demo'" />
|
||||
</Frame>
|
||||
|
||||
## Supported entry points
|
||||
|
||||
The progress modal fires for the following actions:
|
||||
The modal opens for the following actions:
|
||||
|
||||
- Stack **Deploy**, **Update**, **Restart**, **Stop**, and **Down** from the stack editor
|
||||
- **Install** from the App Store
|
||||
- **Apply** from a Git Source panel (when the apply includes a deploy)
|
||||
- **Deploy**, **Update**, **Restart**, **Stop** from the stack editor's action bar.
|
||||
- **Install** from the App Store.
|
||||
- **Apply** from a Git Source panel when the apply request includes a deploy.
|
||||
|
||||
Of those, **Deploy**, **Update**, **Install**, and Git **Apply** route through `docker compose up` and produce a populated structured-log body. **Restart** and **Stop** call the Docker Engine directly to act on existing containers; they bypass compose, so the modal opens, registers `0 lines`, and finishes. Useful as a confirmation surface for those actions, but with no log content.
|
||||
|
||||
The HTTP API also exposes a `down` action (compose-level teardown) that streams its output the same way Deploy and Update do, but no UI control currently triggers it; the `down` endpoint is reachable from automation and from Sencho's own internal cleanup paths.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
<Accordion title="The modal shows 'Connecting...' and no rows appear">
|
||||
Check that the WebSocket connection to Sencho is not blocked by an upstream proxy or firewall. Sencho uses a WebSocket on the same port and path as the main API. If you are running behind nginx or a reverse proxy, ensure `proxy_set_header Upgrade $http_upgrade;` and `proxy_set_header Connection "upgrade";` are configured. See the [configuration guide](/getting-started/configuration) for a complete nginx example.
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="The structured rows are empty but raw output shows content">
|
||||
Some compose wrappers or custom Docker plugins emit non-standard output. The parser falls back to `LOG` rows for lines it cannot classify. If the structured view is empty, open Raw output to see the full stream.
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="I toggled the setting but nothing changed">
|
||||
The setting is read from localStorage and updates in the current tab without a reload. If the change did not take effect, try refreshing the page.
|
||||
</Accordion>
|
||||
<AccordionGroup>
|
||||
<Accordion title="The modal shows 'Connecting...' and no rows appear">
|
||||
The modal opens a WebSocket to the same host and port as the rest of the API and registers itself as the recipient of compose output. If the connection cannot upgrade, the status stays at **Connecting...** indefinitely. Check that an upstream proxy or firewall is not blocking WebSocket upgrades. For nginx, ensure `proxy_set_header Upgrade $http_upgrade;` and `proxy_set_header Connection "upgrade";` are configured. See the [configuration guide](/getting-started/configuration#reverse-proxy-setup) for a full nginx example.
|
||||
</Accordion>
|
||||
<Accordion title="Restart or Stop opens the modal but shows 0 lines">
|
||||
Restart and Stop hit the Docker Engine directly to act on the existing containers; they do not invoke `docker compose`, so there is no compose stream to render. The modal still opens to confirm the action and to surface a failure if one occurs. For a fully populated structured log, use **Deploy** or **Update** instead.
|
||||
</Accordion>
|
||||
<Accordion title="The structured rows are all LOG and I don't see PULL or CREATE badges">
|
||||
The badges are matched on Docker Compose's `[+] Pulling`, `[+] Creating`, and `[+] Starting` progress prefixes, which Compose only emits when it detects an interactive TTY. Sencho spawns `docker compose` without a TTY, so most output falls back to the **LOG** badge. The structured row, the timestamp, the message, and the destructive styling for **ERR** rows all still apply; only the colored stage chip is missing.
|
||||
</Accordion>
|
||||
<Accordion title="The structured rows are empty but raw output shows content">
|
||||
Some compose wrappers and Docker plugins emit non-standard output. The parser falls back to a **LOG** row for any line it cannot classify, but if a line is consumed entirely by ANSI control sequences it can drop out of the structured view. Toggle **Raw output** to see the full stream.
|
||||
</Accordion>
|
||||
<Accordion title="I toggled the setting but the modal does not appear">
|
||||
The setting is stored in `localStorage` under `sencho.deploy-feedback.enabled` and applies to the current tab without a reload. Other tabs in the same browser pick up the change through a `storage` event. If a tab still does not honour the setting, refresh that tab. The setting does not sync across browsers or devices; each one carries its own choice.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
+164
-85
@@ -1,121 +1,200 @@
|
||||
---
|
||||
title: Editor
|
||||
description: Edit compose files and environment variables, and manage containers directly from the dashboard.
|
||||
description: The per-stack cockpit. Run, restart, update, and update compose files; stream logs; exec into a container.
|
||||
---
|
||||
|
||||
Selecting a stack opens the editor view, a two-column layout. The left column shows the command center (stack controls, containers, and an embedded terminal). The right column holds the Monaco code editor.
|
||||
Selecting a stack in the sidebar opens the editor cockpit, a two-column workspace for everything you do to a single stack. The left column is the **Command Center** with the stack's identity, action bar, container list, and log stream. The right column starts on the **Anatomy panel**, a read-only summary of the compose file; clicking **edit** swaps it for the Monaco editor with `compose.yaml`, `.env`, and **Files** tabs.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/editor/editor-overview.png" alt="Editor view showing command center on the left and Monaco editor on the right" />
|
||||
<img src="/images/editor/editor-overview.png" alt="Editor cockpit showing the Command Center and live logs on the left and the Anatomy panel on the right" />
|
||||
</Frame>
|
||||
|
||||
## Files tab
|
||||
## Command Center
|
||||
|
||||
The **Files** tab gives you a browseable directory tree for everything inside the stack's folder. Community users can view text files in read-only mode. Skipper and above can upload, download, edit and save, create folders, and delete files. Protected files (`compose.yaml`, `.env`, and their variants) redirect to their dedicated editor tabs when clicked.
|
||||
The top card on the left holds the stack's identity and primary controls.
|
||||
|
||||
For full details on permissions, viewing limits, upload caps, and troubleshooting, see the [Stack File Explorer](/features/stack-file-explorer) guide.
|
||||
<Frame>
|
||||
<img src="/images/editor/command-center.png" alt="Command Center card with breadcrumb, stack title, running status pill, image and digest, action bar, and the plex container row with live stats" />
|
||||
</Frame>
|
||||
|
||||
## Compose file editor
|
||||
| Element | What it shows |
|
||||
|---------|--------------|
|
||||
| **Breadcrumb** | `<node> › stacks › <stack>` rendered in caps. Confirms which node the stack lives on. |
|
||||
| **Stack title** | The stack name in display italic. |
|
||||
| **Status pill** | Aggregate state: `running · healthy`, `running · starting`, `running · unhealthy`, plain `running` (no healthcheck defined), or `exited` (any non-running state, including stopped, created, and paused). The dot pulses while the stack is running. |
|
||||
| **Image and digest** | First container's image and the leading 12 characters of its image digest, with a copy button for the full SHA. |
|
||||
|
||||
The right panel shows your `compose.yaml` with full syntax highlighting. By default the editor is **read-only** to prevent accidental changes.
|
||||
### Stack action bar
|
||||
|
||||
Click **Edit** to enter edit mode. Your changes are unsaved until you explicitly save them.
|
||||
The action bar runs every state transition for the whole stack. It is hidden for roles without the `stack:deploy` permission.
|
||||
|
||||
| Button | Behavior |
|
||||
|--------|----------|
|
||||
| **Start** / **Restart** | A single button that becomes **Restart** when at least one container is running and **Start** otherwise. |
|
||||
| **Stop** | Stops every container in the stack. Hidden when nothing is running. |
|
||||
| **Update** | Pulls fresh images and reapplies the compose file. |
|
||||
| **More actions** (`⋮`) | Opens a dropdown with secondary actions. |
|
||||
|
||||
The kebab dropdown carries:
|
||||
|
||||
- **Rollback `<timestamp>`** restores the previous deployment using the stored snapshot. Visible only when a backup exists. Skipper or Admiral.
|
||||
- **Scan config** runs Trivy against the compose configuration and surfaces misconfigurations inline. Visible only when Trivy is reachable. Admin role required. Skipper or Admiral.
|
||||
- **Delete** stops the stack and removes its compose directory. Always available to the deploy role.
|
||||
|
||||
## Containers list
|
||||
|
||||
Below the action bar, the **CONTAINERS** section lists every container the stack defines. Each row carries a status badge, identity, port mapping, action buttons, and live stats.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/editor/containers-list.png" alt="Container row showing the green check status badge, container name, uptime, port mapping with an inline open link, action buttons, and CPU MEM and NET I/O stats with sparklines" />
|
||||
</Frame>
|
||||
|
||||
| Element | Detail |
|
||||
|---------|--------|
|
||||
| **Status badge** | `✓` (green, healthy or running), `✗` (red, exited or unhealthy), `…` (yellow, starting). |
|
||||
| **Name** | The Docker container name; falls back to the first 12 characters of the container ID. |
|
||||
| **Uptime / state** | `up 2h 15m` for running containers, the raw state for everything else. |
|
||||
| **Healthcheck label** | `healthcheck passing`, `healthcheck failing`, or `healthcheck starting`, only when a healthcheck is defined. |
|
||||
| **Port mapping** | The first detected web-UI port, formatted `host → container/proto`, with an inline **open** link that launches `http://<node-host>:<host-port>` in a new tab. |
|
||||
| **Action buttons** | **View logs**, **Open bash shell** (admin only), **Service actions**. |
|
||||
| **Live stats** | CPU, memory, and net I/O with rolling sparklines. Only rendered while the container is running. Stats refresh on the same 1500 ms cadence as the dashboard. |
|
||||
|
||||
### Service actions
|
||||
|
||||
When the container has a compose service name attached, an extra `⋮` button appears at the right of the row. It opens **Restart service**, **Stop service**, or **Start service** depending on the current state. Service actions affect a single service; for full-stack operations use the action bar above.
|
||||
|
||||
## Anatomy panel
|
||||
|
||||
The right column shows the **Anatomy panel** by default: a read-only summary of the compose file with a tab for the stack's activity timeline.
|
||||
|
||||
The header strip carries two tabs (**Anatomy** and **Activity**) plus shortcuts to open the **files** tab and enter **edit** mode. The shortcuts belong to the strip itself and remain available regardless of which tab is active.
|
||||
|
||||
The Anatomy tab lists:
|
||||
|
||||
- **services** as chips
|
||||
- **ports** in `host → container/proto` rows, grouped by service when the stack defines more than one
|
||||
- **volumes** in `host → container` rows
|
||||
- **restart** policy
|
||||
- **env_file** paths and a count of variables defined in each
|
||||
- **network** and its driver
|
||||
- **source** with `git · <host>/<repo>#<branch>` when the stack is linked to a Git repository, or `local` when it is not. Clicking the row opens the Git source dialog. A pulsing brand-color dot means an upstream change is queued.
|
||||
|
||||
When an image update is available, an inline banner appears at the top of the panel. Its tone follows the version-bump severity: `safe to apply` (patch), `review recommended` (minor), `breaking changes possible` (major), or `review required` when the bump cannot be classified. The banner has an inline **apply** button that runs the same operation as the action bar's **Update**; it is hidden for roles that lack the `stack:edit` permission and when the bump is flagged as blocked.
|
||||
|
||||
The **Activity** tab streams every operational event scoped to this stack. See [Stack Activity](/features/stack-activity) for the full event catalog and attribution rules.
|
||||
|
||||
## Editor mode
|
||||
|
||||
Clicking **edit** in the Anatomy strip swaps the right column for the Monaco editor card.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/editor/editor-edit-mode.png" alt="Editor in edit mode with the compose.yaml tab selected, the Git Source button, the Save and Deploy split button, and the close button visible" />
|
||||
</Frame>
|
||||
|
||||
The editor card has three tabs:
|
||||
|
||||
| Tab | Purpose |
|
||||
|-----|---------|
|
||||
| `compose.yaml` | YAML editor with syntax highlighting. Always available. |
|
||||
| `.env` | Plaintext editor for the discovered env file. Disabled when the stack has no env file. |
|
||||
| **Files** | Browseable directory tree for the stack folder. See the dedicated [Stack File Explorer](/features/stack-file-explorer) page for permissions, upload caps, and protected-file behavior. |
|
||||
|
||||
Above the editor area, the toolbar carries:
|
||||
|
||||
- **Git Source** opens the Git source dialog. A pulsing brand-color dot appears next to it when an upstream change is waiting to be applied.
|
||||
- **Edit** (when read-only) flips the editor into write mode. Replaced by the save split-button while editing.
|
||||
- **Close editor** (`X`) returns the right column to the Anatomy panel.
|
||||
|
||||
When you switch to the `.env` tab and the stack defines more than one env file, a dropdown appears next to the tab strip so you can pick which file to edit. Sencho discovers env files from the `env_file:` entries in `compose.yaml`; if none are declared, it falls back to a `.env` in the stack directory.
|
||||
|
||||
The `.env` editor renders a teal banner above the textarea reminding you that variables defined there are available for substitution in `compose.yaml` (`${VAR}`), and that passing them into containers requires an `env_file:` entry on the service.
|
||||
|
||||
### Save options
|
||||
|
||||
The primary action button is **Save & Deploy**, which writes the file to disk and immediately runs `docker compose up -d`. A dropdown arrow next to it reveals additional options:
|
||||
In edit mode the toolbar shows a split button. The primary action is **Save & Deploy**; the dropdown chevron reveals two more.
|
||||
|
||||
| Action | What it does |
|
||||
|--------|--------------|
|
||||
| **Save & Deploy** | Writes the file, then runs `docker compose up -d` to apply changes immediately. |
|
||||
| **Save Only** | Writes the file to disk without restarting any containers. |
|
||||
| **Discard Changes** | Reverts the editor to the last saved version. Unsaved changes are lost. |
|
||||
| Action | Effect |
|
||||
|--------|--------|
|
||||
| **Save & Deploy** | Writes the file to disk, then runs `docker compose up -d` to apply changes. |
|
||||
| **Save Only** | Writes the file to disk without restarting any containers. Changes take effect on the next deploy. |
|
||||
| **Discard Changes** | Reverts the editor to the last saved version. Unsaved edits are lost. |
|
||||
|
||||
## Environment file editor
|
||||
|
||||
Click the **.env** tab to switch to the environment file editor. If your `compose.yaml` references multiple env files (via `env_file:`), a dropdown lets you select which file to edit.
|
||||
|
||||
The `.env` editor has the same save/discard controls as the compose editor. Changes take effect the next time the stack is deployed.
|
||||
|
||||
<Note>
|
||||
Sencho reads the `env_file:` paths from your `compose.yaml` to discover available env files. If no `env_file:` is declared, a default `.env` in the stack directory is used.
|
||||
</Note>
|
||||
The same controls apply to the `compose.yaml` and `.env` editors.
|
||||
|
||||
## Diff preview before save
|
||||
|
||||
When the **Diff preview before save** toggle is enabled in **Settings → Appearance**, clicking **Save & Deploy** or **Save Only** opens a side-by-side diff modal before anything is written to disk. The left pane shows the current on-disk content; the right pane shows your unsaved edits, with additions highlighted in green.
|
||||
When **Diff preview before save** is enabled in **Settings → Appearance**, clicking **Save & Deploy** or **Save Only** opens a side-by-side diff modal before anything is written to disk. The left pane is the on-disk content; the right pane is your unsaved edits with additions highlighted in green. The footer reads `ON DISK → UNSAVED` so the panes are unambiguous.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/compose-diff-preview/diff-modal.png" alt="Diff preview modal showing side-by-side YAML diff with a new comment line highlighted in green on the right" />
|
||||
<img src="/images/compose-diff-preview/diff-modal.png" alt="Diff preview modal showing side-by-side YAML diff with the unsaved version on the right and an ON DISK to UNSAVED legend in the footer" />
|
||||
</Frame>
|
||||
|
||||
Review the diff, then:
|
||||
|
||||
- Click **Save & deploy** (or **Save**) to confirm and write the changes to disk.
|
||||
- Click the primary button (**Save & deploy** when triggered from **Save & Deploy**, or **Save** when triggered from **Save Only**) to confirm and write the changes.
|
||||
- Click **Cancel** to return to the editor without saving.
|
||||
|
||||
If there are no unsaved changes the modal is skipped and the save proceeds directly.
|
||||
If there are no unsaved changes the modal is skipped and the save proceeds directly. The toggle is off by default and stored per browser, so each device remembers its own setting.
|
||||
|
||||
The toggle is off by default and saved per browser. Each device remembers its own setting independently. Enable it in **Settings → Appearance → Diff preview before save**.
|
||||
## Logs
|
||||
|
||||
## Container panel
|
||||
Below the Command Center the left column reserves the rest of its height for the **Logs** stream. Two modes are available, toggled by the buttons at the top right of the section.
|
||||
|
||||
The left column lists all containers that belong to the selected stack under the **CONTAINERS** heading. Each container shows:
|
||||
| Mode | What it shows |
|
||||
|------|--------------|
|
||||
| **Structured** | Parses each line for an ISO 8601 timestamp and severity (info, warn, err) and renders rows with filter chips (`all`, `info`, `warn`, `err`) and a counter on the active level. Strips ANSI control codes and auto-follows new lines while you stay at the bottom; scrolling up reveals a **resume follow** button. The buffer is capped at 10,000 lines and the **Download logs** button writes the current buffer to a `.txt` file. |
|
||||
| **Raw terminal** | A full xterm.js terminal that streams the combined container output verbatim with ANSI color preserved. Press `Ctrl+F` to open the inline find bar. The scrollback is 10,000 lines and a download button is available in the toolbar. |
|
||||
|
||||
- **Status badge** - `running`, `exited`, `starting`, or `unhealthy` (hover for detailed status text)
|
||||
- **Live stats** - CPU %, RAM usage, and network I/O displayed inline, updated every few seconds
|
||||
|
||||
### Container actions
|
||||
|
||||
Each container row has action buttons on the right side:
|
||||
|
||||
| Button | What it does |
|
||||
|--------|--------------|
|
||||
| **Open App** | Opens the container's web UI in a new tab (uses the detected web port). Only shown when a port is mapped. |
|
||||
| **View Live Logs** | Opens a live log stream modal for that container. Only available when the container is running. |
|
||||
| **Open Bash Terminal** | Opens an interactive bash session inside the container. Admin only, only available when running. |
|
||||
|
||||
<Frame>
|
||||
<img src="/images/editor/container-actions.png" alt="Container row showing status badge, live stats, and action buttons" />
|
||||
</Frame>
|
||||
|
||||
## Embedded terminal
|
||||
|
||||
Below the container list, an embedded terminal streams the combined output from the stack's containers. This provides a persistent view of container logs without opening a separate modal.
|
||||
|
||||
The terminal supports search (find text within the log output) and export (download the current log buffer).
|
||||
|
||||
### Container terminal (exec)
|
||||
|
||||
The terminal modal from the container action buttons gives you an interactive bash shell inside a running container, equivalent to `docker exec -it <id> bash`. It uses a full terminal emulator with colour support, tab completion, and automatic resizing when you resize the browser window.
|
||||
|
||||
#### Access requirements
|
||||
|
||||
- **Admin role required.** Only admin users see the terminal button in the container actions. Non-admin users cannot open a shell session.
|
||||
- **Container must be running.** The button is disabled for stopped containers, and the backend will reject exec attempts against non-running containers.
|
||||
- **API token restrictions.** API tokens with `read-only` or `deploy-only` scope cannot open exec sessions. Only `full-admin` API tokens are permitted.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/editor/container-exec-modal.png" alt="Container exec modal showing a connected bash session with a root shell prompt" />
|
||||
</Frame>
|
||||
|
||||
#### Shell selection
|
||||
|
||||
Sencho tries `/bin/bash` first. If bash is not available inside the container, it automatically falls back to `/bin/sh`. This happens transparently; no user action is needed.
|
||||
|
||||
<Warning>
|
||||
The container terminal requires the container to have `bash` or `sh` installed. Minimal base images (e.g. `scratch`, `distroless`) that ship no shell will not work with container exec.
|
||||
</Warning>
|
||||
|
||||
#### Troubleshooting
|
||||
|
||||
| Symptom | Cause | Resolution |
|
||||
|---------|-------|------------|
|
||||
| "Container is not running" error | The container stopped between clicking the button and the exec starting | Start the container and try again |
|
||||
| "Failed to start shell" error | The container image has no shell binary (`/bin/bash` or `/bin/sh`) | Use an image that includes a shell, or install one in your Dockerfile |
|
||||
| Terminal connects but immediately shows "Session ended" | The shell process inside the container exited immediately | Check the container logs for errors; the container's entrypoint may be overriding the shell |
|
||||
| Terminal is unresponsive | WebSocket connection dropped silently | Close the modal and reopen it to establish a new session |
|
||||
Both modes connect to the same WebSocket and switch instantly without losing the stream.
|
||||
|
||||
## Log viewer
|
||||
|
||||
The log viewer (opened from the container action buttons) streams output from a single container in real-time using Server-Sent Events. Logs auto-scroll to the bottom as new lines arrive. Close the modal to stop the stream.
|
||||
The **View logs** button on a container row opens a dedicated modal that streams output from a single container in real time using Server-Sent Events. Logs auto-scroll to the bottom as new lines arrive. Close the modal to stop the stream.
|
||||
|
||||
## Container exec (bash session)
|
||||
|
||||
The **Open bash shell** icon button opens an interactive shell inside a single running container, equivalent to `docker exec -it <id> bash`. The modal uses xterm.js with color, tab completion, and resize handling.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/editor/container-exec-modal.png" alt="Bash session modal connected to the plex container running cat slash etc slash os release with a Connected status pill" />
|
||||
</Frame>
|
||||
|
||||
### Access requirements
|
||||
|
||||
- **Admin role required.** The button is rendered only for admin users.
|
||||
- **Container must be running.** The button is disabled for stopped containers, and the backend rejects exec attempts against non-running containers.
|
||||
- **API token scope.** API tokens with the `read-only` or `deploy-only` scope cannot open exec sessions. Only `full-admin` tokens are accepted.
|
||||
|
||||
### Shell selection
|
||||
|
||||
Sencho tries `/bin/bash` first and transparently falls back to `/bin/sh` if bash is missing. No user action is needed.
|
||||
|
||||
<Warning>
|
||||
Minimal base images that ship no shell at all (for example `scratch` or fully `distroless`) will not work with container exec.
|
||||
</Warning>
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="The compose editor is read-only and I can't type">
|
||||
You have not entered edit mode yet. Click **edit** in the Anatomy panel header (or the **Edit** button at the top of the editor card) to enable typing. If the **Edit** button is missing entirely, your role lacks the `stack:edit` permission; ask an admin to grant it.
|
||||
</Accordion>
|
||||
<Accordion title="Save & Deploy is disabled">
|
||||
A deploy is already running for this stack. Watch the action bar for the spinning state to clear, then save again.
|
||||
</Accordion>
|
||||
<Accordion title="The .env tab is greyed out">
|
||||
The stack has no env file to edit. Add an `env_file:` entry to a service in `compose.yaml` and save, or create a `.env` file in the stack directory through the **Files** tab.
|
||||
</Accordion>
|
||||
<Accordion title='"Container is not running" error when opening a bash session'>
|
||||
The container stopped between clicking the button and the exec starting. Start the container from the action bar (or the row's **Start service** option) and try again.
|
||||
</Accordion>
|
||||
<Accordion title='"Failed to start shell" error when opening a bash session'>
|
||||
The container image has no shell binary at `/bin/bash` or `/bin/sh`. Use an image that includes a shell, or install one in your Dockerfile.
|
||||
</Accordion>
|
||||
<Accordion title='Bash session connects but immediately shows "Session ended"'>
|
||||
The shell process inside the container exited as soon as it started. Check the container logs (the **View logs** button on the same row) for errors; the container's entrypoint may be overriding the shell, or the container itself may be in a crash loop.
|
||||
</Accordion>
|
||||
<Accordion title="Bash session is unresponsive">
|
||||
The WebSocket dropped silently. Close the modal and reopen it to start a fresh session; the bash modal does not reconnect automatically.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
+171
-83
@@ -1,116 +1,204 @@
|
||||
---
|
||||
title: Features Overview
|
||||
description: A high-level tour of everything Sencho can do.
|
||||
description: A high-level tour of everything Sencho can do, organized by area.
|
||||
---
|
||||
|
||||
## Dashboard
|
||||
Sencho is a self-hosted cockpit for Docker Compose. The catalog below groups every shipped feature by area so you can scan the surface area at a glance and jump into the deep-dive page for the bits you care about. Tier callouts are inline with each entry; if no tier is mentioned, the feature is available on every Sencho installation.
|
||||
|
||||
The Home view shows real-time system stats at a glance: active containers, exited containers, Docker network activity, and host resource usage (CPU, RAM, disk). Historical CPU and RAM charts display trends over the last 24 hours. A Docker Run converter lets you paste any `docker run` command and convert it to a Compose stack. [Learn more →](/features/dashboard)
|
||||
<Frame>
|
||||
<img src="/images/overview/dashboard-hero.png" alt="Home dashboard showing the system status masthead, the CPU, memory, disk, and network gauge strip with sparklines, and the stack health table sorted by load" />
|
||||
</Frame>
|
||||
|
||||
## Stack management
|
||||
## Stacks & Deployments
|
||||
|
||||
Deploy, start, stop, restart, update, and remove Docker Compose stacks through a point-and-click interface. Right-click any stack in the sidebar for a context menu with quick actions including alerts configuration, update checks, and deployment controls. [Learn more →](/features/stack-management)
|
||||
<Frame>
|
||||
<img src="/images/overview/stack-anatomy.png" alt="Stack anatomy view with action buttons, container card, live logs, and a structured panel listing ports, volumes, healthcheck, and network" />
|
||||
</Frame>
|
||||
|
||||
## Stack labels
|
||||
### Stack management
|
||||
|
||||
Tag your stacks with custom colored labels like `production`, `staging`, or `media-server`. Filter the sidebar by label, identify stacks at a glance, and organize your infrastructure visually. Skipper or Admiral. [Learn more →](/features/stack-labels)
|
||||
Deploy, start, stop, restart, update, and remove Docker Compose stacks through a point-and-click interface. Right-click any stack in the sidebar for a context menu with quick actions, including alerts configuration, update checks, and deployment controls. [Learn more →](/features/stack-management)
|
||||
|
||||
## Editor
|
||||
### Stack activity
|
||||
|
||||
Full in-browser Monaco editor for your `compose.yaml` and `.env` files with syntax highlighting. Toggle edit mode, save to disk, or save and deploy in one step. The container panel shows per-container live stats (CPU, RAM, network), with buttons to open the app, stream logs, or launch a bash terminal. [Learn more →](/features/editor)
|
||||
Every stack has its own event log showing deploys, restarts, starts, stops, and image updates, each event attributed to the user or system that triggered it. The most recent 50 events load immediately and new events stream in live without page refresh; pagination fetches older events on demand. [Learn more →](/features/stack-activity)
|
||||
|
||||
## Resources hub
|
||||
### Editor
|
||||
|
||||
View and manage all Docker images, volumes, and networks. Resources are classified as:
|
||||
Full in-browser Monaco editor for `compose.yaml` and `.env` files with syntax highlighting. Toggle edit mode, save to disk, or save and deploy in one step. The container panel shows per-container live stats (CPU, RAM, network), with buttons to open the app, stream logs, or launch a bash terminal. [Learn more →](/features/editor)
|
||||
|
||||
| Label | Meaning |
|
||||
|-------|---------|
|
||||
| **Managed** | Owned by a Sencho stack |
|
||||
| **External** | Part of another Compose project |
|
||||
| **Unused / Reclaimable** | Safe to prune |
|
||||
### Stack file explorer
|
||||
|
||||
Run scoped prune operations to clean up Sencho-managed resources only, or target all Docker resources when needed. [Learn more →](/features/resources)
|
||||
Browse, edit, upload, and manage files inside a stack's directory from the dashboard. Read-only browsing and text-file viewing are available on every tier; upload, download, edit, folder creation, and file deletion are Skipper or Admiral features. [Learn more →](/features/stack-file-explorer)
|
||||
|
||||
## App Store
|
||||
### Deploy progress
|
||||
|
||||
Stream live output from stack actions in a structured log view with stage badges (PULL, BUILD, CREATE, START, STOP) so you can track each step of the deployment. The modal auto-closes on success and minimizes to a status pill that persists across navigation. [Learn more →](/features/deploy-progress)
|
||||
|
||||
### Resources hub
|
||||
|
||||
View and manage all Docker images, volumes, and networks. Resources are classified as Managed (owned by a Sencho stack), External (part of another Compose project), or Unused / Reclaimable (safe to prune). Run scoped prune operations to clean up Sencho-managed resources only, or target all Docker resources when needed. [Learn more →](/features/resources)
|
||||
|
||||
### App Store
|
||||
|
||||
Browse pre-configured application templates. Filter by category (Media, Automation, Development, etc.), configure environment variables, volumes, and ports, and deploy with a single click. Customize the template source URL to use your own registry. [Learn more →](/features/app-store)
|
||||
|
||||
## Global observability
|
||||
### Atomic deployments
|
||||
|
||||
Sencho snapshots your compose and environment files before applying changes. If containers crash after deploy, the previous configuration is restored automatically. Skipper or Admiral. [Learn more →](/features/atomic-deployments)
|
||||
|
||||
### Deploy enforcement
|
||||
|
||||
Block deploys that violate a scan policy before `docker compose up` runs, with an admin bypass path and a full audit trail. The pre-flight gate enumerates images and rejects deploys when any image meets or exceeds the policy's severity threshold; drift detection continues post-deploy and on schedule. Skipper or Admiral. [Learn more →](/features/deploy-enforcement)
|
||||
|
||||
### Blueprints
|
||||
|
||||
Fleet-wide compose templates that Sencho keeps in sync across the nodes you choose. One declaration covers many nodes via label selectors, drift detection always runs, and stateful blueprints get confirmation prompts before first deploy and before eviction. Skipper or Admiral. [Learn more →](/features/blueprint-model)
|
||||
|
||||
### Git sources
|
||||
|
||||
Link a stack to a Git repository and keep `compose.yaml` in sync via manual pulls or webhook triggers. Review a diff before applying changes, create stacks directly from a repo, and optionally sync sibling `.env` files for consistent configuration. [Learn more →](/features/git-sources)
|
||||
|
||||
### Stack labels
|
||||
|
||||
Tag your stacks with custom colored labels like `production`, `staging`, or `media-server`. Filter the sidebar by label, identify stacks at a glance, and organize your infrastructure visually. Skipper or Admiral. [Learn more →](/features/stack-labels)
|
||||
|
||||
## Observability
|
||||
|
||||
### Dashboard
|
||||
|
||||
The Home view shows real-time system stats at a glance: active containers, exited containers, Docker network activity, and host resource usage (CPU, RAM, disk). Historical CPU and RAM charts display trends over the last 24 hours. A Docker Run converter lets you paste any `docker run` command and convert it to a Compose stack. [Learn more →](/features/dashboard)
|
||||
|
||||
### Global search
|
||||
|
||||
Jump to any page, node, or stack from anywhere in the app with `Ctrl+K` (`Cmd+K` on macOS). The palette groups results into Pages, Nodes, and Stacks; cross-node search fans out across every online node; and keyboard navigation keeps your hands on the keys. [Learn more →](/features/global-search)
|
||||
|
||||
### Global observability
|
||||
|
||||
The **Logs** view aggregates output from all containers across all stacks into a single scrollable stream. Filter by stack, log level (stdout/stderr), or search for keywords. Switch to developer mode for real-time SSE streaming instead of polling. [Learn more →](/features/global-observability)
|
||||
|
||||
## Host console
|
||||
|
||||
Open an interactive terminal on the host OS directly in the browser with full xterm.js emulation and color support. No SSH client required. Admin-only access. [Learn more →](/features/host-console)
|
||||
|
||||
## Multi-node support
|
||||
|
||||
Add remote Sencho instances as nodes. All dashboard operations (stack management, logs, stats) work identically whether you're targeting your local machine or a server on the other side of the world. Uses a transparent HTTP proxy model; no SSH or shared Docker sockets required. [Learn more →](/features/multi-node)
|
||||
|
||||
## Node compatibility
|
||||
|
||||
When you manage multiple nodes running different Sencho versions, the dashboard automatically detects each node's capabilities and disables features that aren't supported on older instances. No errors, no broken pages. [Learn more →](/features/node-compatibility)
|
||||
|
||||
## Fleet View
|
||||
|
||||
Monitor your entire infrastructure from a single screen. The fleet dashboard shows all nodes with health metrics, container counts, and resource usage. Skipper and Admiral users unlock fleet health summary cards, container drill-down, search, sorting, filtering, and critical node detection. [Learn more →](/features/fleet-view)
|
||||
|
||||
## Remote updates
|
||||
|
||||
Check for outdated nodes and trigger over-the-air updates from the Fleet View. When the gateway is running a newer version than a remote node, a one-click update pulls the latest image and recreates the container automatically. Per-node updates and the Check Updates view are available on every tier; the bulk **Update All** action is Skipper or Admiral. [Learn more →](/features/remote-updates)
|
||||
|
||||
## Alerts & notifications
|
||||
### Alerts & notifications
|
||||
|
||||
Configure threshold-based alerts (CPU, memory, network, restart count) per stack. Route notifications to Discord, Slack, or any generic webhook endpoint. Alerts are evaluated every minute with configurable duration and cooldown. [Learn more →](/features/alerts-notifications)
|
||||
|
||||
## Notification routing
|
||||
### Notification routing
|
||||
|
||||
Route alerts to specific channels with per-stack routing rules. Send production alerts to a critical Slack channel while routing dev stack alerts to a less urgent Discord channel. Admiral only. [Learn more →](/features/notification-routing)
|
||||
|
||||
## Webhooks
|
||||
|
||||
Trigger stack actions from external CI/CD pipelines via HTTP webhooks. Create a webhook targeting a specific stack and action, then call it from GitHub Actions, GitLab CI, or any system that can send an HTTP POST. Requests are authenticated with HMAC-SHA256 signatures. [Learn more →](/features/webhooks)
|
||||
|
||||
## API tokens
|
||||
|
||||
Generate scoped API tokens for CI/CD pipelines, scripts, and automation workflows. Each token is assigned a permission level (Read Only, Deploy Only, or Full Admin) so you can follow the principle of least privilege. Admiral only. [Learn more →](/features/api-tokens)
|
||||
|
||||
## Auto-update policies
|
||||
|
||||
Define schedules for Sencho to automatically check your container images for updates and apply them when new versions are available. Each policy targets a specific stack and runs on a cron schedule, with full run history for auditability. Think of it as a built-in Watchtower integrated into your dashboard. Skipper or Admiral. [Learn more →](/features/auto-update-policies)
|
||||
|
||||
## Scheduled operations
|
||||
|
||||
Automate recurring maintenance tasks like stack restarts, fleet snapshots, and system prunes on a cron schedule. Every execution is logged with full history so you always know what ran and when. Scheduled scans, updates, and snapshots are available on Skipper and Admiral; other scheduled actions remain Admiral only. [Learn more →](/features/scheduled-operations)
|
||||
|
||||
## 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 supports two roles on Skipper: Admin (full access) and Viewer (read-only), with three additional roles on Admiral. [Learn more →](/features/rbac)
|
||||
|
||||
## SSO & LDAP authentication
|
||||
|
||||
Authenticate with your existing identity provider. Custom OIDC (Authelia, Keycloak, Authentik, any spec-compliant OIDC provider) is available on every tier. Skipper adds one-click Google, GitHub, and Okta presets. Admiral adds LDAP / Active Directory for enterprise directories. SSO works alongside password authentication and auto-provisions accounts on first login with configurable role mapping. [Learn more →](/features/sso)
|
||||
|
||||
## Atomic deployments
|
||||
|
||||
Skipper and Admiral 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. Manual snapshots are available on every tier; scheduled fleet snapshots are Skipper or Admiral. [Learn more →](/features/fleet-backups)
|
||||
|
||||
## Private registries
|
||||
|
||||
Store credentials for private Docker registries: Docker Hub organizations, GHCR, AWS ECR, and self-hosted registries. Sencho injects them automatically during deploy and pull operations. ECR short-lived tokens are refreshed on every operation. Admiral only. [Learn more →](/features/private-registries)
|
||||
|
||||
## Vulnerability scanning
|
||||
|
||||
Scan container images for known CVEs with [Trivy](https://trivy.dev). Manual scanning, secret and misconfiguration detection, scan comparison, and CVE suppressions are available on every tier; scheduled scans, scan policies that gate deploys, SBOM generation, and SARIF export are available on Skipper and Admiral. Auto-update of the managed Trivy binary is Admiral. [Learn more →](/features/vulnerability-scanning)
|
||||
|
||||
## Audit log
|
||||
### Audit log
|
||||
|
||||
Track every mutating action across your Sencho instance with a searchable audit trail. See who deployed, stopped, deleted, or changed settings, with timestamps, user attribution, and node context. Admiral only. [Learn more →](/features/audit-log)
|
||||
|
||||
## Licensing & billing
|
||||
## Fleet & Multi-Node
|
||||
|
||||
<Frame>
|
||||
<img src="/images/overview/fleet-topology.png" alt="Fleet topology view showing the local node connected by curved links to two remote rack cards, each rendered with a status pill, hostname, CPU, memory, and disk bars" />
|
||||
</Frame>
|
||||
|
||||
### Multi-node support
|
||||
|
||||
Add remote Sencho instances as nodes. All dashboard operations (stack management, logs, stats) work identically whether you are targeting your local machine or a server on the other side of the world. Uses a transparent HTTP proxy model; no SSH or shared Docker sockets required. [Learn more →](/features/multi-node)
|
||||
|
||||
### Pilot Agent
|
||||
|
||||
Add remote nodes behind NAT, residential networks, or corporate firewalls without exposing any inbound port. The agent runs inside a container on the remote host and holds an outbound WebSocket tunnel to your primary instance; every request rides through the tunnel. [Learn more →](/features/pilot-agent)
|
||||
|
||||
### Sencho Mesh
|
||||
|
||||
Connect containers across nodes by hostname over the Pilot tunnel so multi-node fleets feel like one machine. Opt a stack into the mesh and its services become reachable from any other meshed stack at a stable hostname, with no VPN or firewall changes. Admiral only. [Learn more →](/features/sencho-mesh)
|
||||
|
||||
### Fleet View
|
||||
|
||||
Monitor your entire infrastructure from a single screen. The fleet dashboard shows all nodes with health metrics, container counts, and resource usage. Search, sort, filtering, stack drill-down, the Grid / Topology toggle, and critical-node detection are available on every tier; the bulk **Update All** action inside the Node Updates modal is Skipper or Admiral. [Learn more →](/features/fleet-view)
|
||||
|
||||
### Fleet Federation
|
||||
|
||||
Operator-driven placement controls for fleets running Blueprints. Cordon nodes to mark them unschedulable for new work, or pin a blueprint to a specific node to override selector matches. Cordon affects new placements only; existing deployments remain unchanged. Admiral only. [Learn more →](/features/fleet-federation)
|
||||
|
||||
### Fleet Actions
|
||||
|
||||
Run fleet-wide bulk operations from one place: stop stacks across nodes by label selector, or bulk-assign labels to many stacks at once on a single node. Skipper or Admiral. [Learn more →](/features/fleet-actions)
|
||||
|
||||
### Fleet Sync
|
||||
|
||||
When several Sencho instances run as a fleet, the control instance is the source of truth for security configuration and replicates rules to every remote automatically. Replicas show rules read-only and reject direct write attempts with `403 Forbidden`. [Learn more →](/features/fleet-sync)
|
||||
|
||||
### Fleet Secrets
|
||||
|
||||
Centralized, encrypted, versioned env-var bundles you can push to labeled nodes' stacks. Bundles are encrypted at rest with AES-256-GCM, every save bumps a version, and every push records a per-node diff in the audit log using overlay merge semantics. Skipper or Admiral. [Learn more →](/features/fleet-secrets)
|
||||
|
||||
### 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. Manual snapshots are available on every tier; scheduled fleet snapshots are Skipper or Admiral. [Learn more →](/features/fleet-backups)
|
||||
|
||||
### Remote updates
|
||||
|
||||
Check for outdated nodes and trigger over-the-air updates from the Fleet View. When the gateway is running a newer version than a remote node, a one-click update pulls the latest image and recreates the container automatically. Per-node updates and the Check Updates view are available on every tier; the bulk **Update All** action is Skipper or Admiral. [Learn more →](/features/remote-updates)
|
||||
|
||||
### Scheduled operations
|
||||
|
||||
Automate recurring maintenance tasks like stack restarts, fleet snapshots, and system prunes on a cron schedule. Every execution is logged with full history so you always know what ran and when. Scheduled scans, updates, and snapshots are available on Skipper and Admiral; other scheduled actions remain Admiral only. [Learn more →](/features/scheduled-operations)
|
||||
|
||||
## Security & Identity
|
||||
|
||||
### Two-factor authentication
|
||||
|
||||
Protect your Sencho account with a time-based one-time password (TOTP) from an authenticator app and ten single-use backup codes for sign-in recovery. Enroll by scanning a QR code or typing the secret; on every sign-in, Sencho asks for the current six-digit code after your password passes. [Learn more →](/features/two-factor-authentication)
|
||||
|
||||
### 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. Skipper supports two roles (Admin and Viewer); Admiral adds three more (Deployer, Node Admin, Auditor) plus scoped permissions per stack or node. [Learn more →](/features/rbac)
|
||||
|
||||
### SSO & LDAP authentication
|
||||
|
||||
Authenticate with your existing identity provider. Custom OIDC (Authelia, Keycloak, Authentik, any spec-compliant OIDC provider) is available on every tier. Skipper adds preset providers for Google, GitHub, and Okta. Admiral adds LDAP / Active Directory for enterprise directories. SSO works alongside password authentication and auto-provisions accounts on first login with configurable role mapping. [Learn more →](/features/sso)
|
||||
|
||||
### API tokens
|
||||
|
||||
Generate scoped API tokens for CI/CD pipelines, scripts, and automation workflows. Each token is assigned a permission level (Read Only, Deploy Only, or Full Admin) so you can follow the principle of least privilege. Admiral only. [Learn more →](/features/api-tokens)
|
||||
|
||||
### Vulnerability scanning
|
||||
|
||||
Scan container images for known CVEs with [Trivy](https://trivy.dev). Manual scanning, secret and misconfiguration detection, scan comparison, and CVE suppressions are available on every tier; scheduled scans, scan policies that gate deploys, SBOM generation, and SARIF export are available on Skipper and Admiral. Auto-update of the managed Trivy binary is Admiral. [Learn more →](/features/vulnerability-scanning)
|
||||
|
||||
### CVE suppressions
|
||||
|
||||
Accept known-benign vulnerabilities so scan results stay focused on findings that actually need action. Suppressed findings remain in the database and raw counts but are visually dimmed in scan drawers and comparison sheets with your reason shown, optionally expiring after a specified number of days. [Learn more →](/features/cve-suppressions)
|
||||
|
||||
### Private registries
|
||||
|
||||
Store credentials for private Docker registries: Docker Hub organizations, GHCR, AWS ECR, and self-hosted registries. Sencho injects them automatically during deploy and pull operations. ECR short-lived tokens are refreshed on every operation. Admiral only. [Learn more →](/features/private-registries)
|
||||
|
||||
## Automation
|
||||
|
||||
### Auto-Update Readiness
|
||||
|
||||
Review pending container updates across your fleet with risk tags (`patch`, `minor`, `major`, `digest rebuild`), one-line changelog previews, and rollback targets on a single board. The hero counts pending updates and tells you how many are ready to apply without human review; major version jumps and stacks with blocked registries are counted separately for review. Skipper or Admiral. [Learn more →](/features/auto-update-policies)
|
||||
|
||||
### Auto-Heal Policies
|
||||
|
||||
Automatically restart containers that fail Docker healthchecks for longer than a specified threshold. Each policy ships with safety rails: a cooldown period, hourly restart cap, recent-user-action suppression, and auto-disable on repeated restart failures. Skipper or Admiral. [Learn more →](/features/auto-heal-policies)
|
||||
|
||||
### Webhooks
|
||||
|
||||
Trigger stack actions from external CI/CD pipelines via HTTP webhooks. Create a webhook targeting a specific stack and action, then call it from GitHub Actions, GitLab CI, or any system that can send an HTTP POST. Requests are authenticated with HMAC-SHA256 signatures. [Learn more →](/features/webhooks)
|
||||
|
||||
## Platform
|
||||
|
||||
### Stack sidebar
|
||||
|
||||
Manage, group, and pin your stacks from the primary sidebar, organized by label. Pinned stacks sit in a dedicated `PINNED` group at the top, the context menu groups actions by purpose (Inspect, Organize, Lifecycle, Destructive), and an activity footer shows the most recent stack event. [Learn more →](/features/sidebar)
|
||||
|
||||
### Host console
|
||||
|
||||
Open an interactive terminal on the host OS directly in the browser with full xterm.js emulation and color support. No SSH client required. Admin-only access. [Learn more →](/features/host-console)
|
||||
|
||||
## Reference
|
||||
|
||||
### Node compatibility
|
||||
|
||||
When you manage multiple nodes running different Sencho versions, the dashboard automatically detects each node's capabilities and disables features that are not supported on older instances. No errors, no broken pages. [Learn more →](/features/node-compatibility)
|
||||
|
||||
### Licensing & billing
|
||||
|
||||
Sencho is free for personal use with the Community tier. Skipper and Admiral unlock RBAC, webhooks, fleet backups, atomic deployments, and advanced fleet features. Manage your license, view subscription details, and access the billing portal from Settings. [Learn more →](/features/licensing)
|
||||
|
||||
+102
-62
@@ -1,79 +1,102 @@
|
||||
---
|
||||
title: Resources Hub
|
||||
description: Browse, filter, and clean up Docker images, volumes, networks, and unmanaged containers.
|
||||
description: Browse, filter, scan, and clean up Docker images, volumes, networks, and unmanaged containers from a single view.
|
||||
---
|
||||
|
||||
The **Resources** tab gives you a full view of everything Docker is storing on your host, broken down by type and ownership.
|
||||
The **Resources** tab shows everything Docker is storing on your host, broken down by ownership, with one-click cleanup, on-demand vulnerability scanning, and a topology view of how your containers connect.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/resources/resources-reclaim.png" alt="Resources Hub with reclaim hero, disk footprint treemap, and quick clean panel" />
|
||||
<img src="/images/resources/resources-reclaim.png" alt="Resources Hub with the You can reclaim banner, Docker Disk Footprint treemap, Quick Clean panel, and the Images tab populated below" />
|
||||
</Frame>
|
||||
|
||||
## Reclaim hero
|
||||
|
||||
When there is reclaimable disk space (unused images, stopped containers, or dangling volumes), an amber banner leads the view with the total amount you can free and a breakdown of what contributes to it. Click **Review & prune** to jump straight into a confirmation dialog scoped to every reclaimable resource at once.
|
||||
When there is reclaimable disk space (unused images, stopped containers, or dangling volumes), an amber banner leads the view with the total amount you can free and a `·`-separated breakdown of what contributes to it (for example, `16 unused images · 10 dangling volumes`). Click **Review & prune** to open a single confirmation dialog scoped to every reclaimable resource at once.
|
||||
|
||||
The hero stays hidden when there is nothing to reclaim, keeping the view focused on the rest of your inventory.
|
||||
|
||||
## Docker disk footprint
|
||||
<Note>
|
||||
The banner and the **Review & prune** action are admin-only. Read-only roles still see the rest of the page but cannot trigger destructive operations.
|
||||
</Note>
|
||||
|
||||
Below the hero, a three-tile treemap shows how your Docker disk usage is distributed:
|
||||
## Docker Disk Footprint
|
||||
|
||||
The left card under the hero shows how your Docker disk usage is distributed:
|
||||
|
||||
| Segment | Meaning |
|
||||
|---------|---------|
|
||||
| **Sencho Managed** (green) | Images and volumes used by stacks in your `COMPOSE_DIR` |
|
||||
| **Sencho managed** (green) | Images and volumes used by stacks in your `COMPOSE_DIR` |
|
||||
| **External** (amber) | Images and volumes used by Docker projects outside Sencho |
|
||||
| **Reclaimable** (neutral) | Unused images, stopped containers, and dangling volumes safe to delete |
|
||||
|
||||
Tile area is proportional to bytes. Click any tile to filter the tabs below to that category.
|
||||
Each segment shows its size and its share of the total footprint. Tile area is proportional to bytes. Click any segment to filter the resource tabs below to that category.
|
||||
|
||||
## Quick Clean panel
|
||||
## Quick Clean
|
||||
|
||||
Four prune buttons let you reclaim disk space immediately. By default they operate on **Sencho-managed resources only**, so they will not touch external Docker projects.
|
||||
The right card under the hero exposes four prune actions. Each tile has a single primary button that targets **Sencho-managed resources only**, so by default the action will not touch external Docker projects.
|
||||
|
||||
| Button | What it removes |
|
||||
| Action | What it removes |
|
||||
|--------|----------------|
|
||||
| **Prune Unused Images** | Images with no running containers in Sencho stacks |
|
||||
| **Prune Unused Volumes** | Volumes not attached to any Sencho container |
|
||||
| **Prune Dead Networks** | Networks not connected to any Sencho container |
|
||||
| **Purge Unmanaged Containers** | Containers Sencho doesn't recognize (started outside it) |
|
||||
|
||||
The first three buttons have a **More options** dropdown that lets you target **all Docker resources** instead of Sencho-only. Use this carefully, as it can affect other Compose projects running on the same host. The "Purge Unmanaged Containers" button always targets unmanaged containers only.
|
||||
The first three tiles also show a **More options** menu with a single destructive entry, **All Docker (includes external)**, that broadens the prune to every Docker resource on the host. Use it carefully, since it can affect other Compose projects sharing the same daemon. The **Purge Unmanaged Containers** tile has no menu and always targets unmanaged containers only.
|
||||
|
||||
A confirmation dialog appears before any destructive operation, showing a summary of what will be removed. While the operation runs, a loading notification appears so you know Sencho is working. Once complete, a success or error notification replaces it with details on how much space was reclaimed.
|
||||
A confirmation dialog appears before any destructive operation, with a summary of what will be removed. While the operation runs, a loading notification keeps you informed; on completion it is replaced with a success or error notification, including how much space was reclaimed.
|
||||
|
||||
<Note>
|
||||
Quick Clean is admin-only. The panel is hidden for users without admin permissions.
|
||||
</Note>
|
||||
|
||||
## Resource tabs
|
||||
|
||||
Below the hero, four tabs partition your inventory: **images**, **volumes**, **networks**, and **Unmanaged**. The Unmanaged tab shows a count badge whenever orphan containers are detected.
|
||||
|
||||
A **Scan history** button sits on the right of the tab strip when image vulnerability scanning is configured for the node. It opens the full scan record so you can review past results without launching a new scan. See [Vulnerability scanning](/features/vulnerability-scanning) for the full workflow.
|
||||
|
||||
### Images
|
||||
|
||||
Lists all Docker images on the host with their ID, repository tag, size, and status.
|
||||
|
||||
**Filter buttons:** `All` / `Managed` / `External`
|
||||
**Filter chips:** `All`, `Managed`, `External`. Each chip shows the matching count, for example `All 31 · Managed 14 · External 17`.
|
||||
|
||||
**Status badges:**
|
||||
- `In Use` + stack name - image is actively used by a running container in a Sencho-managed stack
|
||||
- `In Use` + `External` - image is used by a container outside Sencho
|
||||
- `Unused` - image has no running containers; safe to delete
|
||||
**Status column** combines two pieces of information per row:
|
||||
|
||||
Click the trash icon on any row to delete an individual image. Sencho will warn you if the image is in use.
|
||||
- A usage badge: `In Use` plus the stack name when the image runs in a Sencho-managed stack, `In Use` plus `External` when it runs in another Docker project, or `Unused` when no container references it.
|
||||
- A severity badge from any image scan: `Clean`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`, or `UNKNOWN`. Click the badge to open the scan results.
|
||||
|
||||
**Per-row actions** sit on the right:
|
||||
|
||||
- **Inspect** (eye) opens the image detail sheet.
|
||||
- **Scan** (shield) opens a menu with `Scan (vulnerabilities)` and `Full scan (vulnerabilities + secrets)`. The full scan is a paid-tier option.
|
||||
- **Delete** (trash, admin-only) removes the image. Sencho warns before deleting an image that is still in use.
|
||||
|
||||
#### Inspect image
|
||||
|
||||
Click the eye icon on any image row to open a detail panel showing:
|
||||
Click the eye icon on any image row to open a detail sheet with three sections:
|
||||
|
||||
- **Overview** - ID, size, creation date, architecture and OS, author, and all repository tags
|
||||
- **Config** - Default `Cmd`, `Entrypoint`, `WorkingDir`, `User`, exposed ports, environment variables, and labels (env and labels are collapsible)
|
||||
- **Layers** - Ordered layer history. Each row shows layer index, size, age, and the build command (`CreatedBy`). Empty layers (metadata-only, zero bytes) are dimmed.
|
||||
- **Overview** lists the ID, size, creation date, architecture and OS, author, and all repository tags.
|
||||
- **Config** shows the default `Cmd`, `Entrypoint`, `WorkingDir`, `User`, exposed ports, environment variables, and labels. Env vars and labels are collapsible.
|
||||
- **Layers** lists the layer history in build order. Each row shows the layer index, size, age, and the build command (`CreatedBy`). Empty layers (metadata-only, zero bytes) are dimmed.
|
||||
|
||||
The inspect panel is read-only and available to all users.
|
||||
The inspect sheet is read-only and available to all roles.
|
||||
|
||||
### Volumes
|
||||
|
||||
Lists all Docker volumes. Columns: name, driver, mount point, size, and managed status.
|
||||
<Frame>
|
||||
<img src="/images/resources/resources-volumes-tab.png" alt="Volumes tab with Largest 5 and Recently changed landing cards above the volume list" />
|
||||
</Frame>
|
||||
|
||||
When any volumes are present, a two-card landing strip above the table highlights the **Largest 5** volumes by size and **Recently changed** volumes from the last 24 hours. This makes it easy to spot growing volumes or newly created data at a glance.
|
||||
Lists all Docker volumes with name, driver, mount point, and managed status.
|
||||
|
||||
**Filter buttons:** `All` / `Managed` / `External`
|
||||
A two-card landing strip sits above the table:
|
||||
|
||||
- **Largest 5** ranks volumes by on-disk size, with the total volume count alongside.
|
||||
- **Recently changed** highlights volumes created or touched in the last 24 hours, with relative timestamps such as `24m ago`.
|
||||
|
||||
**Filter chips:** `All`, `Managed`, `External`, each with its count.
|
||||
|
||||
<Warning>
|
||||
Deleting a volume is permanent. Any data stored in it will be lost. Always back up important volume data before pruning.
|
||||
@@ -81,7 +104,7 @@ When any volumes are present, a two-card landing strip above the table highlight
|
||||
|
||||
#### Browse volume contents
|
||||
|
||||
Click the folder icon on any volume row (admin only) to open a read-only browser for that volume. The panel shows a directory tree on the left and a file viewer on the right.
|
||||
Click the folder icon on any volume row (admin-only) to open a read-only browser for that volume. The panel shows a directory tree on the left and a file viewer on the right.
|
||||
|
||||
- **Read only.** No edits, no writes, no deletions. The browser launches a short-lived helper container with the volume mounted read-only.
|
||||
- **Size cap.** Files are read up to 5 MB. Larger files show a truncation banner.
|
||||
@@ -95,77 +118,94 @@ Click the folder icon on any volume row (admin only) to open a read-only browser
|
||||
|
||||
### Networks
|
||||
|
||||
Lists all Docker networks. Columns: ID, name, driver, scope (`local`, `global`, `swarm`), and managed status.
|
||||
|
||||
**Filter buttons:** `All` / `Managed` / `External`
|
||||
|
||||
System networks (like `bridge`, `host`, `none`) are shown but cannot be deleted.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/networks/networks-list.png" alt="Networks list view with filter, inspect, and create actions" />
|
||||
<img src="/images/networks/networks-list.png" alt="Networks tab in List view with filter chips, view-mode toggle, Create Network button, and the network table" />
|
||||
</Frame>
|
||||
|
||||
#### Create network
|
||||
Lists all Docker networks with ID, name, driver, scope (`local`, `global`, `swarm`), and managed status. System networks (`bridge`, `host`, `none`) are shown but cannot be deleted.
|
||||
|
||||
Click **+ Create Network** (admin only) to open the creation dialog.
|
||||
**Filter chips:** `All`, `Managed`, `External`, each with its count.
|
||||
|
||||
A **List | Topology** view-mode toggle sits on the right of the toolbar. **List** is the default tabular view; **Topology** is a paid-tier graph view of how containers connect to networks (covered below).
|
||||
|
||||
#### Create Network
|
||||
|
||||
In **List** view, the **+ Create Network** button (admin-only) opens the creation dialog.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/networks/create-network.png" alt="Create Network dialog with name, driver, subnet, and gateway fields" />
|
||||
<img src="/images/networks/create-network.png" alt="Create network dialog with Name, Driver, Subnet, Gateway fields, and Internal and Attachable toggles" />
|
||||
</Frame>
|
||||
|
||||
| Field | Required | Description |
|
||||
|-------|----------|-------------|
|
||||
| **Name** | Yes | Alphanumeric, hyphens, underscores, and dots |
|
||||
| **Driver** | No | `bridge` (default), `overlay`, `macvlan`, `host`, or `none` |
|
||||
| **Subnet** | No | CIDR notation, e.g. `172.20.0.0/16` |
|
||||
| **Gateway** | No | Gateway IP, e.g. `172.20.0.1` |
|
||||
| **Subnet** | No | CIDR notation, for example `172.20.0.0/16` |
|
||||
| **Gateway** | No | Gateway IP, for example `172.20.0.1` |
|
||||
| **Internal** | No | Isolates the network from external access |
|
||||
| **Attachable** | No | Allows containers to be manually attached |
|
||||
|
||||
The footer shows a **DRIVER** chip that mirrors the selected driver, and a **Create network** button that stays disabled until the form is valid.
|
||||
|
||||
#### Inspect network
|
||||
|
||||
Click the eye icon on any network row to open a detail panel showing:
|
||||
|
||||
- **Overview** - ID, driver, scope, creation date, internal/attachable flags
|
||||
- **IPAM configuration** - Subnet, gateway, and IP range
|
||||
- **Options** - Driver-specific options applied to the network (when present)
|
||||
- **Connected containers** - Container name, IPv4 address, and MAC address
|
||||
- **Labels** - All Docker labels applied to the network
|
||||
Click the eye icon on any network row to open a detail sheet.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/networks/network-inspect.png" alt="Network inspect panel showing IPAM config and connected containers" />
|
||||
<img src="/images/networks/network-inspect.png" alt="Network inspect sheet for arr-net showing the Overview, IPAM configuration, and Connected containers sections" />
|
||||
</Frame>
|
||||
|
||||
The sheet is grouped into sections:
|
||||
|
||||
- **Overview** lists the ID, driver, scope, creation date, and the internal/attachable flags.
|
||||
- **IPAM configuration** shows the subnet, gateway, and IP range for each configured address pool.
|
||||
- **Options** lists driver-specific options applied to the network (rendered only when present).
|
||||
- **Connected** shows every container attached to the network, with its name, IPv4 address, and MAC address. The section header counts the containers.
|
||||
- **Labels** lists all Docker labels on the network (rendered only when present).
|
||||
|
||||
#### Network topology <span style={{fontSize: '0.75em', color: 'var(--brand)'}}>Skipper</span>
|
||||
|
||||
Switch to the **Topology** view to see an interactive graph of your Docker networks and the containers connected to them. The graph uses automatic hierarchical layout (networks on top, containers below) that scales cleanly regardless of how many networks and containers you have.
|
||||
Switch to the **Topology** view to see an interactive graph of your Docker networks and the containers attached to them. The graph uses an automatic hierarchical layout (networks on top, containers below) that scales cleanly regardless of how many networks and containers you have.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/networks/network-topology.png" alt="Network topology visualization showing containers connected to networks" />
|
||||
<img src="/images/networks/network-topology.png" alt="Network topology graph with arr-net at top and the connected containers fanned out below it, mini-map and zoom controls visible" />
|
||||
</Frame>
|
||||
|
||||
- **Network nodes** - Dashed border cards showing network name and driver, color-coded by status (managed, external, system)
|
||||
- **Container nodes** - Cards showing container name, state indicator, stack badge, image name, and IP addresses per network
|
||||
- **Edges** - Animated color-coded connections between networks and their containers
|
||||
- **Click-to-logs** - Click any running container node to open its log viewer directly
|
||||
- **Refresh** - Use the refresh button in the toolbar to re-fetch the topology on demand
|
||||
- Pan, zoom, and drag nodes to explore the topology
|
||||
- A mini map in the bottom-right provides an overview
|
||||
- **Network nodes** are dashed-border cards showing the network name and driver, color-coded by status (managed, external, system).
|
||||
- **Container nodes** are cards showing the container name, a state indicator, the stack badge, the image name, and the IPv4 address per network.
|
||||
- **Edges** are animated, color-coded connections between networks and their containers.
|
||||
- **Click-to-logs.** Click any running container node to open its log viewer directly.
|
||||
- **Refresh.** Use the refresh button in the toolbar to re-fetch the topology on demand.
|
||||
- Pan, zoom, and drag nodes to explore the graph.
|
||||
- A **mini-map** in the bottom-right gives an overview of the full graph. Zoom and fit-view controls sit on the bottom-left.
|
||||
|
||||
##### Show system networks
|
||||
|
||||
By default, system networks (`bridge`, `host`, `none`) are hidden. Toggle **Show system networks** to include them in the graph, which is useful for debugging containers attached to the default bridge network.
|
||||
By default, system networks (`bridge`, `host`, `none`) are hidden so the graph stays focused on user networks. Toggle **Show system networks** to include them, which is useful for debugging containers attached to the default bridge.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/networks/network-topology-toggle.png" alt="Network topology with system networks visible" />
|
||||
<img src="/images/networks/network-topology-toggle.png" alt="Topology with Show system networks toggled on; arr-net plus the bridge, none, and host system networks all visible at the top" />
|
||||
</Frame>
|
||||
|
||||
<Note>
|
||||
Network Topology requires a Skipper or Admiral license. Community users see an upgrade prompt.
|
||||
Network Topology requires a Skipper or Admiral license. On Community, the Topology toggle shows an upgrade prompt instead of the graph.
|
||||
</Note>
|
||||
|
||||
### Unmanaged
|
||||
|
||||
Lists containers running on the host that are not part of any Sencho-managed stack. This includes containers started with `docker run`, or Compose projects outside your `COMPOSE_DIR`.
|
||||
<Frame>
|
||||
<img src="/images/resources/resources-unmanaged-tab.png" alt="Unmanaged tab with Select all checkbox, Purge Selected action, and a container row grouped under External Project: sencho" />
|
||||
</Frame>
|
||||
|
||||
This view is useful for identifying orphaned containers after a failed deployment or after moving stacks in and out of `COMPOSE_DIR`. A badge on the tab shows the count of unmanaged containers when any are detected.
|
||||
Lists containers running on the host that are not part of any Sencho-managed stack: containers started with `docker run`, or Compose projects outside your `COMPOSE_DIR`. The tab shows a count badge when any are detected.
|
||||
|
||||
Containers are grouped by their external Compose project. Each group has an **External Project** header with the project name and a container count. Each container row shows:
|
||||
|
||||
- A row checkbox for multi-selection.
|
||||
- The container name (or short ID if unnamed).
|
||||
- A state pill, for example `running`.
|
||||
- The image reference, in monospace below the name.
|
||||
|
||||
The toolbar above the list provides a **Select all** checkbox and a destructive **Purge Selected (N)** button. The button stays disabled until at least one row is checked, and is admin-only.
|
||||
|
||||
When no unmanaged containers are detected, the tab shows a success state with the message "No unmanaged containers" and the subline "All running containers are managed by Sencho."
|
||||
|
||||
@@ -3,20 +3,20 @@ title: SSO & LDAP Authentication
|
||||
description: Authenticate with your existing identity provider, including LDAP, Google, GitHub, Okta, and any spec-compliant OIDC provider.
|
||||
---
|
||||
|
||||
Sencho lets your team sign in using existing identity providers instead of managing separate credentials. SSO works **alongside** password authentication; it does not replace it. SSO is available in every Sencho edition; higher tiers add turnkey presets and enterprise directory support.
|
||||
Sencho lets your team sign in using existing identity providers instead of managing separate credentials. SSO works **alongside** password authentication; it does not replace it. SSO is available in every Sencho edition; higher tiers add preset providers and enterprise directory support.
|
||||
|
||||
## Supported providers
|
||||
|
||||
| Provider | Protocol | Tier | Notes |
|
||||
|----------|----------|------|-------|
|
||||
| **Custom OIDC** | OpenID Connect | Community | Any spec-compliant OIDC provider: Authelia, Keycloak, Authentik, Zitadel, KanIDM, Pocket ID, and more |
|
||||
| **Google** | OpenID Connect | Skipper | One-click preset for Google Workspace or personal Google accounts |
|
||||
| **GitHub** | OAuth 2.0 | Skipper | One-click preset for GitHub personal accounts and GitHub orgs |
|
||||
| **Okta** | OpenID Connect | Skipper | One-click preset for any Okta org or Okta-compatible IdP |
|
||||
| **Google** | OpenID Connect | Skipper | Preset for Google Workspace or personal Google accounts, with branded login button |
|
||||
| **GitHub** | OAuth 2.0 | Skipper | Preset for GitHub personal accounts and GitHub orgs, with branded login button |
|
||||
| **Okta** | OpenID Connect | Skipper | Preset for any Okta org or Okta-compatible IdP, with branded login button |
|
||||
| **LDAP / Active Directory** | LDAP bind + search | Admiral | Works with OpenLDAP, Active Directory, FreeIPA, and any LDAPv3 server |
|
||||
|
||||
<Tip>
|
||||
**Self-hosters on the Community tier** can still integrate Google, GitHub, Okta, or any other identity provider by using the Custom OIDC option pointed at the provider's discovery endpoint. The paid-tier presets add one-click configuration and provider-specific defaults; the underlying protocol is the same.
|
||||
**Self-hosters on the Community tier** can still integrate Google, GitHub, Okta, or any other identity provider by using the Custom OIDC option pointed at the provider's discovery endpoint. The paid-tier presets ship with provider-aware defaults (issuer URL, claim mapping) and a branded login button; the underlying protocol is the same. You still create the OAuth app in the provider's console and paste the Client ID and Secret either way.
|
||||
</Tip>
|
||||
|
||||
## How it works
|
||||
|
||||
@@ -3,10 +3,10 @@ title: Stack Activity
|
||||
description: Per-stack event log showing deploys, restarts, config changes, and alerts, each attributed to the user or system that triggered them.
|
||||
---
|
||||
|
||||
The **Activity** tab inside each stack's panel gives you a timestamped record of everything that happened to that stack: deploys, restarts, starts, stops, and image updates. Each entry shows who triggered the event so you always have operational context.
|
||||
The **Activity** tab in the right-hand **Anatomy** panel gives you a timestamped record of everything that happened to the selected stack: deploys, restarts, starts, stops, and image updates. Each entry shows who triggered the event so you always have operational context. The `files` and `edit` actions on the same strip belong to the panel as a whole and stay available regardless of which tab is active.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-activity/activity-tab-populated.png" alt="Stack Activity tab showing a restart event attributed to a user" />
|
||||
<img src="/images/stack-activity/activity-tab-populated.png" alt="Stack Activity tab showing events grouped by Today, Yesterday, and Earlier with restart, auto-update, and image-update entries" />
|
||||
</Frame>
|
||||
|
||||
## What you'll see
|
||||
@@ -15,34 +15,59 @@ Each entry in the activity list contains:
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Icon** | Category of the event (deploy, restart, stop, start, update) |
|
||||
| **Message** | What happened (e.g. "bazarr restarted") |
|
||||
| **Attributed to** | `by <username>` for user-initiated actions, omitted for automated system events |
|
||||
| **Time** | Relative time since the event (e.g. "just now", "5m ago", "2h ago") |
|
||||
| **Icon** | Category of the event (deploy, restart, stop, start, image update applied) |
|
||||
| **Message** | What happened (for example, `dozzle restarted`) |
|
||||
| **Attributed to** | `by <username>` for user-initiated actions; omitted for events without an actor and for system-driven events such as auto-update or auto-heal |
|
||||
| **Time** | Relative time since the event: `just now`, `5m ago`, `2h ago`, `3d ago` |
|
||||
|
||||
Events are grouped by day: **Today**, **Yesterday**, and **Earlier**.
|
||||
## Event categories
|
||||
|
||||
## Who triggered an event
|
||||
The five operational categories below have a dedicated icon. Other notification categories that scope to a stack (for example, deploy failures, available image updates, auto-heal triggers, monitor alerts, or scan findings) also flow into the timeline and render with a generic activity icon.
|
||||
|
||||
Sencho attributes every recorded event to the user who was authenticated when the action was taken. If the action was triggered by an automated process (auto-heal, image update polling, or any other system process) the event is recorded as a system action and the attribution label is omitted from the display.
|
||||
| Category | Icon | Example message |
|
||||
|----------|------|-----------------|
|
||||
| Deploy succeeded | rocket | `plex deployed` |
|
||||
| Stack restarted | refresh | `dozzle restarted` |
|
||||
| Stack stopped | stop | `radarr stopped` |
|
||||
| Stack started | play | `radarr started` |
|
||||
| Image update applied | up arrow | `Auto-update: stack "dozzle" updated with new images` |
|
||||
|
||||
## Accessing the Activity tab
|
||||
## Day grouping
|
||||
|
||||
1. Click any stack in the left sidebar to open its panel.
|
||||
2. Switch to the **Activity** tab in the panel header.
|
||||
Events are grouped by day under three headers: **Today**, **Yesterday**, and **Earlier**. Within each group, events are ordered most-recent first.
|
||||
|
||||
The tab loads the most recent 50 events immediately and streams new events live as they happen without a page refresh.
|
||||
## Live updates
|
||||
|
||||
New events stream in over the same WebSocket that powers the notification bell, so the list updates without a page refresh while the tab is open.
|
||||
|
||||
## Pagination
|
||||
|
||||
If a stack has more than 50 recorded events, a **Load more** button appears at the bottom of the list. Each click fetches the next 50 older events.
|
||||
The tab loads the most recent 50 events on open. If a stack has more recorded events, a **Load more** button appears at the bottom of the list. Each click fetches the next 50 older events.
|
||||
|
||||
## Empty state
|
||||
|
||||
When a stack has no recorded operational events yet, the tab displays a heartbeat icon with the message `No activity recorded yet`.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-activity/activity-tab-empty.png" alt="Stack Activity tab in its empty state with a heartbeat icon and the message 'No activity recorded yet'" />
|
||||
</Frame>
|
||||
|
||||
## Who triggered an event
|
||||
|
||||
Sencho attributes every recorded event to the user who was authenticated when the action was taken. Events without an actor, and events triggered by automated processes such as auto-update polling or auto-heal, are recorded as system actions; the attribution label is omitted from their display.
|
||||
|
||||
## Accessing the Activity tab
|
||||
|
||||
1. Click any stack in the left sidebar to open it.
|
||||
2. Switch to the **Activity** tab in the Anatomy panel header.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**The Activity tab shows "No activity recorded yet"**
|
||||
|
||||
The activity log is populated by operations performed through Sencho — deploys, restarts, starts, stops, and image updates — since the Sencho instance started tracking them. If you have not performed any of these operations on this stack via Sencho since the feature was enabled, the tab will be empty. Trigger a restart or deploy and the entry appears within a few seconds.
|
||||
|
||||
**Events appear in the bell notification dropdown**
|
||||
|
||||
The notification dropdown shows system alerts and error-level events only. User-initiated operational events (start, stop, restart, deploy, update) appear exclusively in the per-stack Activity tab rather than the global notification tray, keeping the tray focused on conditions that need your attention.
|
||||
<AccordionGroup>
|
||||
<Accordion title="The Activity tab shows 'No activity recorded yet'">
|
||||
The activity log is populated by operations performed through Sencho on this stack: deploys, restarts, starts, stops, and image updates. Trigger one of those actions and the entry appears within a few seconds.
|
||||
</Accordion>
|
||||
<Accordion title="Operational events don't appear in the bell notification dropdown">
|
||||
The notification dropdown surfaces system alerts and error-level events. User-initiated operational events (start, stop, restart, deploy, update) appear exclusively in the per-stack Activity tab, keeping the global tray focused on conditions that need your attention.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@@ -1,9 +1,13 @@
|
||||
---
|
||||
title: Stack File Explorer
|
||||
description: Browse, edit, upload, and manage files inside a stack's directory from the dashboard.
|
||||
description: Browse, view, edit, upload, rename, and chmod every file inside a stack's directory from the dashboard.
|
||||
---
|
||||
|
||||
The file explorer gives you direct access to everything inside a stack's directory: configuration files, certificates, scripts, static assets, and any other files your containers depend on. It lives on the **Files** tab inside the stack editor.
|
||||
The file explorer gives you direct access to everything inside a stack's directory: configuration files, certificates, scripts, static assets, and any other files your containers depend on. It lives on the **Files** tab inside the stack editor, alongside the dedicated `compose.yaml` and `.env` editors.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-file-explorer/overview.png" alt="Files tab open with a populated tree on the left, a YAML file open in the editor on the right, and the Anatomy panel in the background" />
|
||||
</Frame>
|
||||
|
||||
<Note>
|
||||
The explorer is scoped to the stack's own directory. You cannot browse other stacks or navigate above the stack root.
|
||||
@@ -11,94 +15,189 @@ The file explorer gives you direct access to everything inside a stack's directo
|
||||
|
||||
## Opening the file explorer
|
||||
|
||||
Select any stack in the sidebar, then click the **Files** tab in the editor. The left panel shows the directory tree; clicking a file opens it in the viewer on the right.
|
||||
1. Click any stack in the left sidebar.
|
||||
2. Click **edit** in the right-hand Anatomy panel header to open the editor.
|
||||
3. Switch to the **Files** tab.
|
||||
|
||||
The **files** shortcut button next to **edit** in the Anatomy header opens the editor and selects the Files tab in one click.
|
||||
|
||||
## Tiers at a glance
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Community" icon="eye">
|
||||
Browse the directory tree and view text files in read-only mode.
|
||||
Browse the directory tree, view text files in read-only mode, and inspect file permissions.
|
||||
</Card>
|
||||
<Card title="Skipper" icon="pencil">
|
||||
Full read/write access: upload, download, edit and save, create folders, and delete files or directories. Admiral tier includes the same access.
|
||||
Full read and write: upload, download, edit and save, create files and folders, rename, change permissions, and delete. Admiral inherits the same access.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Layout
|
||||
|
||||
The Files tab splits into two panes. The left pane holds the upload affordance, the new-folder button, and the directory tree. The right pane is the action bar plus the file viewer.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-file-explorer/layout-panes.png" alt="Files tab two-pane layout showing the upload widget and tree on the left and the file viewer on the right" />
|
||||
</Frame>
|
||||
|
||||
## Browsing the directory tree
|
||||
|
||||
The tree lists all files and folders in the stack directory. Folders are sorted before files, and items within each group are sorted alphabetically.
|
||||
Folders sort before files, and entries within each group sort alphabetically.
|
||||
|
||||
Click a folder to expand or collapse it. Click a file to open it in the viewer panel on the right.
|
||||
Click a folder to expand or collapse it. Click a file to open it in the viewer on the right. Symlinks render with a chain icon and behave like files when clicked.
|
||||
|
||||
### Protected files
|
||||
**Display cap.** Each directory render is capped at 500 entries. A folder with more than 500 children shows the first 500 alphabetically and appends `Showing 500 of N - refine in shell` at the bottom of the list. For directories with more entries, work from a host shell.
|
||||
|
||||
`compose.yaml`, `docker-compose.yaml`, `docker-compose.yml`, `.env`, and any `.env.*` variants are shown in the tree, but clicking them does not open the generic file viewer. Instead, Sencho navigates to the dedicated **Compose** or **Env** tab editor for that file. This ensures you always use the purpose-built editor with save-and-deploy controls for your main stack files.
|
||||
## Protected files
|
||||
|
||||
The amber dot in the tree marks the five canonical stack files: `compose.yaml`, `compose.yml`, `docker-compose.yaml`, `docker-compose.yml`, and `.env`.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-file-explorer/protected-tree-marker.png" alt="File tree with amber dot markers next to compose.yaml and .env" />
|
||||
</Frame>
|
||||
|
||||
Two behaviours follow from the marker:
|
||||
|
||||
- **Dedicated tab redirect.** Clicking `compose.yaml`, `compose.yml`, or `.env` jumps you to the matching **compose.yaml** or **.env** tab so the save-and-deploy controls stay in front of you. `docker-compose.yaml` and `docker-compose.yml` are still flagged as protected, but they open in the regular file viewer because they are not the canonical Sencho file.
|
||||
- **Type-to-confirm delete.** All five protected names require typing the filename to confirm a delete. See the Deleting section below.
|
||||
|
||||
## Viewing files
|
||||
|
||||
When you click a text file, its contents appear in the editor panel on the right.
|
||||
|
||||
**Viewing limits:**
|
||||
When you click a text file, its contents appear in the editor on the right. The Monaco editor auto-detects the language from the extension.
|
||||
|
||||
| File type | Behaviour |
|
||||
|-----------|-----------|
|
||||
| Text file up to 2 MB | Displayed inline with syntax highlighting. |
|
||||
| Text file over 2 MB | "File is too large to preview" message with a **Download** button (Skipper+). |
|
||||
| Binary file | "Binary file detected" message with a **Download** button (Skipper+). |
|
||||
| Text file up to 2 MB | Rendered inline with syntax highlighting. |
|
||||
| Text file over 2 MB | Panel with the filename and size, plus a **Download** button on Skipper+. |
|
||||
| Binary file | Same panel layout, label is `Binary file`. |
|
||||
|
||||
On Community, the Download button is hidden for files that exceed the preview limit. To access large or binary files from the Community tier, use the host terminal or `docker cp` from your server.
|
||||
On Community, the panel for over-2-MB and binary files omits the Download button. To pull oversized or binary files from Community, use a host shell or `docker cp`.
|
||||
|
||||
## Editing and saving (Skipper+)
|
||||
|
||||
Text files open in read-only mode by default. Click **Edit** in the toolbar to enable editing. The editor accepts plain text input.
|
||||
When you have stack edit permission and a paid tier, the editor opens in write mode. The toolbar shows the filename and a **Save** button that activates as soon as there are unsaved changes.
|
||||
|
||||
When you're done, click **Save** to write the file to disk. Unsaved changes are discarded when you navigate away or close the tab.
|
||||
When you do not, the toolbar shows a `Read-only` chip and the editor refuses input.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-file-explorer/viewer-edit-mode.png" alt="Viewer toolbar showing the filename label and the Save button next to a YAML buffer" />
|
||||
</Frame>
|
||||
|
||||
Click **Save** to write the file to disk. Navigating away from the file before saving discards the unsaved edits.
|
||||
|
||||
<Warning>
|
||||
Editing a file does not restart any containers. If your stack reads the file at runtime (e.g. a config file mounted as a volume), restart the relevant service after saving for the change to take effect.
|
||||
Editing a file does not restart any containers. If your stack reads the file at runtime (for example, a config file mounted as a volume), restart the relevant service after saving so the container picks up the new content.
|
||||
</Warning>
|
||||
|
||||
## Creating files and folders (Skipper+)
|
||||
|
||||
The toolbar **New folder** button at the top of the tree creates a folder in the currently selected directory (the parent of the file you have open, or the stack root if nothing is open). The button is hidden on Community.
|
||||
|
||||
Right-click any folder for **New File** and **New Folder** entries that scope to the right-clicked folder.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-file-explorer/new-file-dialog.png" alt="New file modal scoped to the nginx folder, with the file name field populated and a Create button" />
|
||||
</Frame>
|
||||
|
||||
Filenames cannot be empty, cannot contain `/` or `\`, and cannot be `.` or `..`. The Create button stays disabled until the input passes validation.
|
||||
|
||||
## Uploading files (Skipper+)
|
||||
|
||||
Click **Upload** in the file explorer toolbar, then select one or more files from your local machine. Files are uploaded into the currently selected directory.
|
||||
The dashed **Upload file** affordance at the top of the tree opens a file picker. Uploads are one file at a time.
|
||||
|
||||
**Limits:**
|
||||
| Limit | Value |
|
||||
|-------|-------|
|
||||
| Maximum file size | 25 MB. Uploads above the limit return a 413 error with `TOO_LARGE`. |
|
||||
| Target directory | The currently selected directory, or the stack root if no file is open. |
|
||||
| Same-name files | Overwritten without prompt. |
|
||||
|
||||
- Maximum 25 MB per file.
|
||||
- Files larger than 25 MB are rejected with an error. Split large archives or use `scp` / `rsync` for bulk transfers.
|
||||
On Community the upload affordance is hidden entirely.
|
||||
|
||||
If a file with the same name already exists in the target directory, it is overwritten.
|
||||
<Tip>
|
||||
For bulk transfers or files above 25 MB, use `scp` or `rsync` from your workstation directly to the stack directory on the host.
|
||||
</Tip>
|
||||
|
||||
## Downloading files (Skipper+)
|
||||
|
||||
Click the **Download** button in the file toolbar (for the currently open file) or right-click a file in the tree and choose **Download**. Files are streamed directly to your browser. The download limit is 100 MB per file.
|
||||
When a file is selected on Skipper+, the right pane action bar shows **Download**. Files stream straight to your browser. Files that exceed the inline preview limit also expose a Download button inside the oversized-file panel itself.
|
||||
|
||||
<Tip>
|
||||
For files larger than 100 MB, use `docker cp`, `scp`, or mount an export volume and copy from there.
|
||||
</Tip>
|
||||
## Renaming (Skipper+)
|
||||
|
||||
## Creating folders (Skipper+)
|
||||
Right-click any file or folder and choose **Rename**. The dialog accepts a new name following the same rules as creation.
|
||||
|
||||
Click the **New Folder** button in the tree toolbar, or right-click an existing folder and choose **New Folder**. Enter a name and confirm. The new folder is created immediately and appears in the tree.
|
||||
The rename is in-place; cross-directory moves are not supported. To move an entry between directories, copy it via the host shell or upload to the new location and delete the original.
|
||||
|
||||
Folder names follow the same rules as filenames on your host OS. Avoid leading dots unless you intend a hidden directory.
|
||||
## Permissions (chmod)
|
||||
|
||||
## Deleting files and folders (Skipper+)
|
||||
Right-click any file and choose **Permissions** to inspect or edit its Unix mode bits. The dialog shows a 3 by 3 grid of `r` / `w` / `x` toggles for Owner, Group, and Other, plus the current octal value.
|
||||
|
||||
Right-click a file or folder in the tree and choose **Delete**. A confirmation prompt appears before anything is removed.
|
||||
<Frame>
|
||||
<img src="/images/stack-file-explorer/permissions-dialog.png" alt="Permissions modal for a file showing the rwx grid for Owner, Group, and Other plus the octal value 644" />
|
||||
</Frame>
|
||||
|
||||
**Deleting a folder** removes the folder and all of its contents recursively. The confirmation dialog lists the path so you can verify before proceeding.
|
||||
On Community the dialog opens read-only: the toggles render the current state and the footer shows only **Close**. On Skipper+ the toggles are interactive and the footer adds **Save**.
|
||||
|
||||
<Note>
|
||||
Permissions are applied with `chmod`. Symlinks may not honour the change depending on the host kernel.
|
||||
</Note>
|
||||
|
||||
## Deleting (Skipper+)
|
||||
|
||||
There are three delete entry points. All three open the same confirmation modal.
|
||||
|
||||
- **Toolbar delete.** With a file open in the viewer, click **Delete** in the right-pane action bar.
|
||||
- **Context-menu delete.** Right-click any file or folder in the tree and choose **Delete**.
|
||||
- **Non-empty folder delete.** The first attempt is non-recursive. If the folder has contents, the modal switches to `This folder is not empty. Delete everything inside?` with a destructive **Delete all** button.
|
||||
|
||||
When the entry is one of the five protected names, the modal asks you to type the filename before the destructive button activates.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-file-explorer/delete-protected-confirm.png" alt="Delete confirmation modal for compose.yaml requiring the user to type the filename before the destructive button activates" />
|
||||
</Frame>
|
||||
|
||||
<Warning>
|
||||
Deletions are permanent. Sencho does not keep a trash bin or undo history for file operations.
|
||||
Deletes are permanent. Sencho does not keep a trash bin or undo history for file operations.
|
||||
</Warning>
|
||||
|
||||
## Context menu reference
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-file-explorer/context-menu-folder.png" alt="Right-click menu on a folder showing New File, New Folder, Rename, and Delete entries" />
|
||||
</Frame>
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-file-explorer/context-menu-file.png" alt="Right-click menu on a file showing Rename, Permissions, and Delete entries" />
|
||||
</Frame>
|
||||
|
||||
| Right-click target | Skipper+ entries | Community admin entries |
|
||||
|---|---|---|
|
||||
| Folder | New File, New Folder, Rename, Delete | Rename, Delete |
|
||||
| File | Rename, Permissions, Delete | Rename, Permissions, Delete |
|
||||
|
||||
On Community, the New File and New Folder entries on a folder are hidden. Rename and Delete are gated by the `stack:edit` permission, so admins still see them, but the underlying API rejects the call with a 403 toast on a non-paid tier. Use Skipper+ for any write action; the Permissions dialog opens for everyone but only Skipper+ can save changes.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Symptom | Cause | Resolution |
|
||||
|---------|-------|------------|
|
||||
| File shows as "Binary file detected" but it is a text file | The binary detection heuristic found null bytes or a high proportion of non-printable characters, which can happen with certain encodings or line endings | Download the file, edit it locally or via an SSH session, then re-upload. Alternatively, open a host terminal and edit with `nano` or `vim`. |
|
||||
| Upload fails with a 413 error | The file exceeds the 25 MB per-file limit | Compress or split the file before uploading, or transfer it via `scp` / `rsync` directly to the stack directory on the host. |
|
||||
| Cannot delete a folder | The UI requires confirmation before a recursive delete | Confirm the deletion prompt. If the error persists, check whether a running container has an open file handle inside that directory, which can block the delete on some OS configurations. Stop the relevant service and retry. |
|
||||
| File saved but container still reads old content | The container caches the file at startup or the mount is read-only inside the container | Restart the service after saving so the container picks up the new file. |
|
||||
| Download button not visible | You are on the Community tier, and the file exceeds the preview limit or is binary | Upgrade to Skipper to enable downloads, or access the file via the host terminal or `docker cp`. |
|
||||
<AccordionGroup>
|
||||
<Accordion title="File shows as 'Binary file detected' but it is a text file">
|
||||
The binary detection heuristic flagged null bytes or a high proportion of non-printable characters in the file's first kilobytes. This can happen with certain encodings, non-UTF-8 byte sequences, or unusual line-ending mixes. Download the file, edit it locally or via a host terminal, then re-upload.
|
||||
</Accordion>
|
||||
<Accordion title="Upload fails with a 413 error">
|
||||
The file exceeds the 25 MB per-file upload limit. Compress or split the file before uploading, or transfer it via `scp` or `rsync` directly to the stack directory on the host.
|
||||
</Accordion>
|
||||
<Accordion title="Cannot delete a folder">
|
||||
The first delete attempt is non-recursive. If the folder is not empty, the dialog switches to `This folder is not empty. Delete everything inside?`. Click **Delete all** to remove the folder and its contents. If the error persists, check whether a running container has an open file handle inside that directory; stop the relevant service and retry.
|
||||
</Accordion>
|
||||
<Accordion title="File saved but the container still reads the old content">
|
||||
The container caches the file at startup, or the mount is configured read-only inside the container. Restart the service after saving so the container picks up the new file.
|
||||
</Accordion>
|
||||
<Accordion title="Download button is missing">
|
||||
You are on the Community tier. Downloads are a Skipper+ feature. To pull large or binary files from Community, use a host terminal or `docker cp`.
|
||||
</Accordion>
|
||||
<Accordion title="The tree shows 'Showing 500 of N - refine in shell'">
|
||||
Each directory render is capped at 500 entries to keep the tree responsive. The first 500 entries alphabetically are shown. To work with the entries past the cap, drop into a host shell with `cd` into the stack directory.
|
||||
</Accordion>
|
||||
<Accordion title="Rename or Delete returned a 403">
|
||||
Rename and Delete in the file context menu are write operations that require Skipper+. The menu items appear for any user with the `stack:edit` permission so a Community admin can see them, but the API rejects the call. Upgrade to Skipper+ to enable these actions, or perform the rename or delete from a host shell.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@@ -3,50 +3,75 @@ title: Stack Management
|
||||
description: Create, deploy, control, and remove Docker Compose stacks.
|
||||
---
|
||||
|
||||
A **stack** in Sencho is a Docker Compose project: a directory inside your `COMPOSE_DIR` that contains at least a `compose.yaml` (or `docker-compose.yml`) file. Sencho automatically discovers every subdirectory as a stack.
|
||||
A **stack** in Sencho is a Docker Compose project: a directory inside your `COMPOSE_DIR` that contains at least a `compose.yaml` (or `docker-compose.yml`) file. Sencho discovers every subdirectory as a stack and surfaces them in the left sidebar.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/create-stack-dialog.png" alt="New stack dialog" />
|
||||
<img src="/images/stack-management/sidebar-grouped.png" alt="Sencho sidebar showing the stack list grouped by label, with filter chips at the top" />
|
||||
</Frame>
|
||||
|
||||
## Creating a stack
|
||||
|
||||
Click **Create Stack** in the left sidebar. Enter a name and click **Create**.
|
||||
Click **Create Stack** in the left sidebar to open the **New stack** dialog. Pick a source from the tabs at the top:
|
||||
|
||||
- **Empty**: start with a blank `compose.yaml` and write it from scratch.
|
||||
- **From Git**: clone a Git repository so its compose file becomes the stack source. Future webhook pulls keep it in sync. See [Git Sources](/features/git-sources) for the full sync flow.
|
||||
- **From Docker Run**: paste a `docker run` command and let Sencho convert it to compose YAML.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/create-stack-dialog.png" alt="New stack dialog on the Empty tab with a stack name field" />
|
||||
</Frame>
|
||||
|
||||
**Naming rules:**
|
||||
- Lowercase letters, numbers, and hyphens only (e.g. `my-app`, `nextcloud`)
|
||||
- No spaces or special characters
|
||||
- Must be unique; duplicates are rejected
|
||||
|
||||
Sencho creates a new directory inside `COMPOSE_DIR` with a blank `compose.yaml` file. You'll land in the editor automatically.
|
||||
Sencho creates a new directory inside `COMPOSE_DIR` with the chosen seed file. You land in the editor for the new stack and can deploy it from there.
|
||||
|
||||
## Convert from a docker run command
|
||||
### From Git
|
||||
|
||||
If you have a `docker run` command handy (from a README, a forum post, or your shell history), Sencho can turn it into a ready-to-deploy `compose.yaml` without hand translation.
|
||||
|
||||
Open the **New stack** dialog and switch to the **From Docker Run** tab.
|
||||
The **From Git** tab clones a public or private repository and treats its compose file as the stack's source of truth.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/convert-tab-empty.png" alt="Create stack dialog on the From Docker Run tab" />
|
||||
<img src="/images/stack-management/create-stack-git.png" alt="New stack dialog on the From Git tab with repository URL, branch, compose file path, authentication, and apply behavior fields" />
|
||||
</Frame>
|
||||
|
||||
### How to use it
|
||||
Fill in:
|
||||
|
||||
- **Stack Name**: same naming rules as the Empty tab.
|
||||
- **Repository URL**: HTTPS only. SSH URLs are not supported.
|
||||
- **Branch**: defaults to `main`.
|
||||
- **Compose file path**: path inside the repository, defaults to `compose.yaml`.
|
||||
- **Also sync sibling .env file**: when checked, a `.env` next to the compose file is pulled along with it.
|
||||
- **Authentication**: pick **Public (no auth)** or **Personal Access Token** for private repos.
|
||||
- **Apply behavior**: controls what happens on future webhook pulls:
|
||||
- **Review only**: diffs surface in the sidebar; you apply manually.
|
||||
- **Auto-write files**: pulls write to disk; you redeploy manually.
|
||||
- **Auto-deploy**: pulls write and redeploy automatically.
|
||||
- **Deploy after create**: deploys the stack immediately after the repo is cloned.
|
||||
|
||||
Click **Create from Git**. Sencho clones the repo, writes the compose file into the stack directory, and (when **Deploy after create** is checked) runs `docker compose up -d`.
|
||||
|
||||
### Convert from a docker run command
|
||||
|
||||
If you have a `docker run` command from a README, a forum post, or your shell history, the **From Docker Run** tab turns it into a ready-to-deploy `compose.yaml` without hand translation.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/convert-tab-empty.png" alt="New stack dialog on the From Docker Run tab with stack name and command paste fields" />
|
||||
</Frame>
|
||||
|
||||
**How to use it:**
|
||||
|
||||
1. Enter a **Stack Name**. Same rules as the Empty tab (lowercase, hyphens, unique).
|
||||
2. Paste your full command into **Paste your docker run command**. The whole command should be on one logical line; line continuations with `\` are fine.
|
||||
3. Click **Convert**. Sencho parses the command and shows the resulting compose YAML in a read-only preview below.
|
||||
4. Review the YAML. If it looks right, click **Create Stack**. Sencho creates the stack directory and writes the converted YAML into `compose.yaml`.
|
||||
5. The editor opens on the new stack. Click **Start** to deploy it.
|
||||
4. Review the YAML. If it looks right, click **Create Stack**. Sencho creates the stack directory and writes the converted YAML into `compose.yaml`, then opens the editor on the new stack.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/convert-tab-result.png" alt="Converted compose YAML preview before creating the stack" />
|
||||
<img src="/images/stack-management/convert-tab-result.png" alt="Converted compose YAML preview shown after a successful conversion" />
|
||||
</Frame>
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/convert-stack-created.png" alt="Newly created stack loaded in the editor after conversion" />
|
||||
</Frame>
|
||||
|
||||
### Supported flags
|
||||
**Supported flags:**
|
||||
|
||||
The converter handles the flags you reach for most often:
|
||||
|
||||
@@ -71,45 +96,74 @@ The converter handles the flags you reach for most often:
|
||||
|
||||
The image tag is taken from the final positional argument (for example `nginx:alpine`). Any trailing command arguments are preserved as the service `command`.
|
||||
|
||||
### Troubleshooting
|
||||
**Troubleshooting conversion:**
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/convert-tab-error.png" alt="Error toast shown when the converter cannot parse the input" />
|
||||
<img src="/images/stack-management/convert-tab-error.png" alt="Error toast shown above the New stack dialog when the converter cannot parse the input" />
|
||||
</Frame>
|
||||
|
||||
If the converter cannot produce a usable compose file, the request fails with a clear error toast. Common causes:
|
||||
|
||||
- **Not a docker run command.** The input must begin with `docker run` and include an image reference. Free-form text, `docker compose` commands, and shell pipelines are rejected.
|
||||
- **Unrecognized flag.** The parser supports the flags listed above. Rare flags (such as `--userns`, `--ipc`, custom runtime options) may not be recognized. Remove the flag, convert the rest, and add it back by hand in the editor.
|
||||
- **Quoting issues.** Multi-line commands with embedded quotes sometimes confuse the parser. Paste the command as a single line with escaped quotes, or simplify the command first.
|
||||
- **Unrecognized flag.** The parser supports the flags listed above. Rare flags (such as `--userns`, `--ipc`, custom runtime options) are not recognized. Remove the flag, convert the rest, and add it back by hand in the editor.
|
||||
- **Quoting issues.** Multi-line commands with embedded quotes can confuse the parser. Paste the command as a single line with escaped quotes, or simplify the command first.
|
||||
- **Command is too long.** The endpoint accepts commands up to 8192 characters. Longer inputs are rejected; trim anything you do not need and convert in pieces.
|
||||
|
||||
When a flag is not supported, paste the output you do get into the **Empty** tab as a starting point and fill in the rest by editing `compose.yaml` directly.
|
||||
When a flag is not supported, paste the partial output into the **Empty** tab as a starting point and fill in the rest by editing `compose.yaml` directly.
|
||||
|
||||
## The stack list
|
||||
|
||||
All discovered stacks appear in the left sidebar. Each shows a color-coded status indicator:
|
||||
All discovered stacks appear in the left sidebar. The list groups stacks by label (Skipper+) and by pinned status, so the most relevant entries surface at the top.
|
||||
|
||||
### Status indicator
|
||||
|
||||
Each row leads with a two-character status indicator that summarizes the stack's runtime state.
|
||||
|
||||
| Indicator | Meaning |
|
||||
|-----------|---------|
|
||||
| `UP` (green) | All containers running |
|
||||
| `DN` (red) | One or more containers exited |
|
||||
| No indicator | No containers / status unknown |
|
||||
| (blank) | No containers running, status unknown, or the stack has never been deployed |
|
||||
|
||||
Use the **search box** above the list to filter stacks by name.
|
||||
A small fuchsia dot to the right of the stack name flags that an image update is available. A pulsing brand-color dot on the **Git Source** affordance signals the upstream branch has moved ahead of the working copy.
|
||||
|
||||
### Search and filter chips
|
||||
|
||||
The search box above the list filters stacks by name. The chip row below it filters by state and is independent of search.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/filter-chips.png" alt="Sidebar filter chip row showing All, Up, Down, and Updates with count badges" />
|
||||
</Frame>
|
||||
|
||||
- **All**: every stack discovered in `COMPOSE_DIR`.
|
||||
- **Up**: stacks where every container is running.
|
||||
- **Down**: stacks with at least one stopped or exited container.
|
||||
- **Updates**: stacks with a pending image update.
|
||||
|
||||
Each chip carries a live count. Click **Hide filters** in the top-right of the row to collapse the chips when you want a denser list. Search and chips combine: filtering by **Updates** and typing a few characters returns the intersection.
|
||||
|
||||
### Pinned and label groups
|
||||
|
||||
The list is grouped to keep frequently used stacks reachable.
|
||||
|
||||
- **PINNED**: sits at the very top when at least one stack is pinned. Pin a stack with **Pin to top** in the kebab menu (`P` shortcut).
|
||||
- **Label groups**: each label produces its own collapsible section, header rendered uppercase. Labels are a Skipper+ feature; see [Stack Labels](/features/stack-labels) for color and assignment options.
|
||||
- **UNLABELED**: bottom group with everything that has no label.
|
||||
|
||||
Click any group header to collapse or expand it. The group's stack count appears in the header.
|
||||
|
||||
## Stack header
|
||||
|
||||
Opening a stack puts identity and state front and center.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-view/identity-header.png" alt="Stack identity header with breadcrumb, title, state pill, image digest, and action row" />
|
||||
<img src="/images/stack-view/identity-header.png" alt="Stack identity header showing breadcrumb, title, state pill, image and digest, and action row" />
|
||||
</Frame>
|
||||
|
||||
The header answers three questions at a glance:
|
||||
|
||||
- **What is this?** A breadcrumb (`node › stacks › name`) and the stack name as the title.
|
||||
- **Is it healthy?** A pulsing pill to the right of the title reports the live state:
|
||||
- **What is this?** A breadcrumb (`LOCAL · STACKS · NAME`) and the stack name as the title.
|
||||
- **Is it healthy?** A state pill to the right of the title reports the live state:
|
||||
- `running · healthy` (green) when at least one container reports a passing healthcheck.
|
||||
- `running · unhealthy` (red) when any container reports a failing healthcheck.
|
||||
- `running · starting` (amber) during the Docker healthcheck start period.
|
||||
@@ -117,27 +171,33 @@ The header answers three questions at a glance:
|
||||
- `exited` (red) when no containers are up.
|
||||
- **What does it ship?** A mono line under the title shows the primary image tag and the short image digest, with a copy button to grab the full digest.
|
||||
|
||||
The action row to the right of the header keeps everyday lifecycle controls visible. The **More actions** overflow holds Rollback, Scan config, and Delete; the next sections cover both surfaces.
|
||||
|
||||
## Container health strip
|
||||
|
||||
Below the header, each container in the stack gets a single row that answers "is this piece working, and how do I reach it?" without expanding anything.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-view/health-strip-logs.png" alt="Stack view showing the per-container health strip above the structured logs viewer" />
|
||||
<img src="/images/stack-view/containers.png" alt="CONTAINERS section showing a container card with health badge, uptime, port mapping, open link, and CPU, memory, and network stat tiles" />
|
||||
</Frame>
|
||||
|
||||
Each row includes:
|
||||
|
||||
- **Health badge.** A colored glyph reports the Docker healthcheck state: `✓` green for passing, `✗` red for failing, `…` amber while the healthcheck start period is still in flight. Containers without a `healthcheck:` block show a neutral `✓`.
|
||||
- **Health badge.** A colored glyph reports the Docker healthcheck state: `✓` green for passing, `✗` red for failing, `…` amber while the healthcheck start period is in flight. Containers without a `healthcheck:` block show a neutral `✓`.
|
||||
- **Container name** in mono.
|
||||
- **Meta line.** Uptime (`up 20 hours`), healthcheck state when one is defined, and the primary port mapping (`6875 → 80/tcp`).
|
||||
- **Meta line.** Uptime (`up 12 hours`) and the primary port mapping (`8989 → 8989/tcp`).
|
||||
- **Open link.** When the container publishes a port, an `open ↗` link launches the app in a new tab using the active node's hostname.
|
||||
- **Live stat tiles.** Three tiles show CPU, memory, and network I/O with a rolling 60-sample sparkline. The sparkline uses the cyan data color and refreshes roughly every 1.5 seconds.
|
||||
- **Action icons.** Shortcuts to open this container's logs or a bash shell.
|
||||
- **Live stat tiles.** Three tiles show CPU, memory, and network I/O with a rolling sparkline. The sparkline uses the cyan data color and refreshes roughly every 1.5 seconds.
|
||||
- **Action icons.** Shortcuts to **View logs**, open a bash shell, and the per-service kebab.
|
||||
|
||||
## Logs viewer
|
||||
|
||||
The logs area at the bottom of the stack view has two modes. Toggle between them with the segmented control in the top-right of the panel; your choice is remembered for next time.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-view/logs-viewer.png" alt="Logs panel in Structured mode with toolbar, level filter pills, and timestamped INFO log rows" />
|
||||
</Frame>
|
||||
|
||||
**Structured** (default) parses every line into a DOM row with three columns: local time, level badge, and message. Level detection is automatic:
|
||||
|
||||
- `err` rows get a red left rail and a subtle rose tint.
|
||||
@@ -146,8 +206,8 @@ The logs area at the bottom of the stack view has two modes. Toggle between them
|
||||
|
||||
The toolbar includes:
|
||||
|
||||
- **Following indicator.** A pulsing green dot reads `following` while auto-scroll is engaged. Scrolling up stops follow; a `resume follow` link re-engages it and jumps to the bottom.
|
||||
- **Level filter.** `all · info · warn · err` pills. The `err` pill shows the running error count as a badge.
|
||||
- **Following indicator.** A green dot reads `following` while auto-scroll is engaged. Scrolling up stops follow; a `resume follow` link re-engages it and jumps to the bottom.
|
||||
- **Level filter.** `ALL · INFO · WARN · ERR` pills. The `ERR` pill shows the running error count as a badge.
|
||||
- **Download.** Exports the current buffer as a plain text file.
|
||||
|
||||
The structured viewer holds up to 10,000 lines; older entries are dropped from the top as new ones arrive.
|
||||
@@ -156,35 +216,45 @@ The structured viewer holds up to 10,000 lines; older entries are dropped from t
|
||||
|
||||
## Anatomy panel
|
||||
|
||||
The right half of the stack view is the anatomy panel: a read-only summary of what the compose file declares, without making you open the YAML editor.
|
||||
The right column of the stack view is a two-tab panel: **Anatomy** is the read-only summary of what the compose file declares, and **Activity** is the audit log for that stack.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-view/anatomy-panel.png" alt="Stack view with the anatomy panel on the right showing services, ports, volumes, env file, network, and source" />
|
||||
<img src="/images/stack-view/anatomy-panel.png" alt="Anatomy panel with services, ports, volumes, restart, env_file, network, and source rows, plus a footer link for the exposed port" />
|
||||
</Frame>
|
||||
|
||||
Each row maps one compose concept to the value it resolves to right now:
|
||||
The header carries:
|
||||
|
||||
- **Services** — Cyan pills, one per key under `services:`.
|
||||
- **Ports** — `{host} → {container}/{proto}` per service, host port highlighted.
|
||||
- **Volumes** — `{host-path} → {container-path}` per mount.
|
||||
- **Restart** — The effective restart policy.
|
||||
- **Env file** — Filename plus a count of defined variables. If the compose file references a `${VAR}` that the env file does not define and has no `:-default`, the missing name is called out inline in rose italic.
|
||||
- **Network** — Derived network name and driver (default `{stack}_default · bridge`).
|
||||
- **Source** — `git · {host}/{repo}#{branch}` when Git Source is configured, else `local`. The whole row is clickable and opens the Git Source dialog. A pulsing cyan dot appears when upstream has moved ahead of the working copy.
|
||||
- **Anatomy / Activity tabs.** Activity is documented on its own page; see [Stack Activity](/features/stack-activity).
|
||||
- **Files** button. Opens the in-stack file explorer; see [Stack File Explorer](/features/stack-file-explorer).
|
||||
- **Edit** button. Slides the Monaco editor over the panel for inline compose and env edits.
|
||||
|
||||
If an image update is available for the primary service, an inline banner appears below the rows with the version bump (`27.1.4 → 27.1.5`), risk classification (`safe · patch`, `minor`, or `major · review required`), and an **apply** button that runs the update against the current scheduled-task pipeline. Major bumps show a rose banner and require explicit review before applying.
|
||||
Each row inside the **Anatomy** tab maps one compose concept to the value it resolves to right now:
|
||||
|
||||
- **Services**: Cyan pills, one per key under `services:`.
|
||||
- **Ports**: `{host} → {container}/{proto}` per service, host port highlighted.
|
||||
- **Volumes**: `{host-path} → {container-path}` per mount.
|
||||
- **Restart**: The effective restart policy.
|
||||
- **Env file**: Filename plus a count of defined variables. If the compose file references a `${VAR}` that the env file does not define and has no `:-default`, the missing name is called out inline.
|
||||
- **Network**: Derived network name and driver (default `{stack}_default · bridge`).
|
||||
- **Source**: `git · {host}/{repo}#{branch}` when Git Source is configured, else `local`. The whole row is clickable and opens the Git Source dialog. A pulsing dot appears when upstream has moved ahead of the working copy.
|
||||
|
||||
A footer card under the rows surfaces the first published port as a clickable **EXPOSED** link, so you can jump straight to the running app.
|
||||
|
||||
If an image update is available for the primary service, an inline banner appears below the rows with the version bump (`27.1.4 → 27.1.5`), risk classification (`safe · patch`, `minor`, or `major · review required`), and an **apply** button that runs the update on this stack. Major bumps show a rose banner and require explicit review before applying.
|
||||
|
||||
### Editing compose.yaml
|
||||
|
||||
Anatomy is the default surface. When you need to change the compose file, click **edit compose.yaml** in the anatomy header. The Monaco editor slides in over the anatomy panel with the full editing toolbar (tabs for `compose.yaml` and `.env`, Git Source shortcut, Save / Save & Deploy). Close the editor with the `×` button in its header to return to the anatomy view; unsaved changes are discarded when you close.
|
||||
Click **Edit** in the panel header to open the Monaco editor. Tabs at the top switch between `compose.yaml`, `.env` (when one exists), and **Files** (the stack directory tree). The save split-button reads **Save & Deploy** by default; its dropdown also offers **Save Only** and **Discard Changes**. Close the editor to return to the anatomy view; unsaved changes are kept in the buffer until you discard them. See [Compose Editor](/features/editor) for autocomplete, schema validation, and Git Source workflow.
|
||||
|
||||
## Deploying a stack
|
||||
|
||||
Select a stack and click **Start** (or **Deploy** from the context menu) in the stack header. This runs `docker compose up -d`, pulling images if needed and creating or recreating containers.
|
||||
Select a stack and click **Start** (or **Restart** when it's already running) in the stack header. This runs `docker compose up -d`, pulling images if needed and creating or recreating containers.
|
||||
|
||||
For deploy progress, error surfacing, atomic backups, and rollback, see [Atomic Deployments](/features/atomic-deployments).
|
||||
|
||||
## Controlling a running stack
|
||||
|
||||
The stack header groups actions by frequency of use. The most common action is the filled cyan button on the left, everyday secondaries sit next to it, and destructive or occasional actions are tucked behind the `⋯` overflow.
|
||||
The stack header groups actions by frequency of use. The most common action is the filled cyan button on the left, everyday secondaries sit next to it, and destructive or occasional actions are tucked behind the **More actions** overflow.
|
||||
|
||||
**When running:**
|
||||
|
||||
@@ -193,9 +263,9 @@ The stack header groups actions by frequency of use. The most common action is t
|
||||
| Primary | **Restart** | `docker compose restart` | Restarts all containers in the stack. |
|
||||
| Secondary | **Stop** | `docker compose stop` | Stops containers without removing them. State is preserved. |
|
||||
| Secondary | **Update** | `docker compose pull` + `up -d` | Pulls the latest image tags and recreates containers. |
|
||||
| Overflow `⋯` | **Rollback** | Restores backup | Reverts compose and env files to the pre-deploy snapshot and redeploys. Only shown when a backup exists (Skipper+). |
|
||||
| Overflow `⋯` | **Scan config** | Trivy config scan | Scans the compose file for misconfigurations (Skipper+, admin). |
|
||||
| Overflow `⋯` | **Delete** | `down --volumes` + removes files | Stops and removes containers and volumes, then deletes the stack directory. |
|
||||
| Overflow | **Rollback** | Restores backup | Reverts compose and env files to the pre-deploy snapshot and redeploys. Only shown when a backup exists (Skipper+). |
|
||||
| Overflow | **Scan config** | Trivy config scan | Scans the compose file for misconfigurations (Skipper+, admin). |
|
||||
| Overflow | **Delete** | `down --volumes` + removes files | Stops and removes containers and volumes, then deletes the stack directory. |
|
||||
|
||||
**When stopped:**
|
||||
|
||||
@@ -203,7 +273,7 @@ The stack header groups actions by frequency of use. The most common action is t
|
||||
|-----------|--------|---------|--------------|
|
||||
| Primary | **Start** | `docker compose up -d` | Starts the stack. |
|
||||
| Secondary | **Update** | `docker compose pull` + `up -d` | Pulls the latest image tags and recreates containers. |
|
||||
| Overflow `⋯` | **Delete** | Removes files | Deletes the stack directory. |
|
||||
| Overflow | **Delete** | Removes files | Deletes the stack directory. |
|
||||
|
||||
<Warning>
|
||||
**Delete** is irreversible. It removes the stack directory, including `compose.yaml`, `.env`, and any bind-mounted files stored there. Back up important files before deleting.
|
||||
@@ -213,13 +283,34 @@ The stack header groups actions by frequency of use. The most common action is t
|
||||
Stack directories often contain root-owned files, either because Docker Compose creates them, or because the stacks were originally set up outside of Sencho with `sudo`. Sencho handles this automatically: if a normal deletion fails due to permissions, it uses Docker to clean up root-owned files. No manual intervention is needed in the standard setup.
|
||||
</Note>
|
||||
|
||||
## Bulk mode
|
||||
|
||||
Bulk mode lets you run a single lifecycle action across several stacks at once, instead of opening each stack individually.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/bulk-action-bar.png" alt="Sidebar with bulk mode active, three stacks selected, and the action bar showing Start, Stop, Restart, and Update buttons" />
|
||||
</Frame>
|
||||
|
||||
**Enter bulk mode** with the toggle next to **Create Stack** in the sidebar, or by pressing `B`. Each stack row turns into a checkbox.
|
||||
|
||||
**Select stacks** by clicking rows. The action bar above the list shows `{N} selected` and a **Clear selection** link.
|
||||
|
||||
**Run an action** with one of the four buttons:
|
||||
|
||||
- **Start**: deploys every selected stack that is currently down.
|
||||
- **Stop**: stops every selected stack that is currently running.
|
||||
- **Restart**: restarts every selected stack that is currently running.
|
||||
- **Update**: pulls the latest image tags and redeploys (Skipper+).
|
||||
|
||||
Press `B` again or toggle the bulk mode button to leave bulk mode.
|
||||
|
||||
## Controlling a single service
|
||||
|
||||
Inside the stack detail view, each service row has a kebab menu (`⋮`) on the right side. Use it to act on that service without touching the rest of the stack.
|
||||
Inside the stack detail view, each container card has a **Service actions** kebab on the right side. Use it to act on that service without touching the rest of the stack.
|
||||
|
||||
- **Restart service** — stops and starts all containers for that service.
|
||||
- **Stop service** — stops all containers for that service. Only shown when the service is running.
|
||||
- **Start service** — starts all containers for that service. Only shown when the service is stopped or exited.
|
||||
- **Restart service**: stops and starts all containers for that service.
|
||||
- **Stop service**: stops all containers for that service. Only shown when the service is running.
|
||||
- **Start service**: starts all containers for that service. Only shown when the service is stopped or exited.
|
||||
|
||||
For services running multiple replicas, the action applies to every replica simultaneously. Sibling services are not affected.
|
||||
|
||||
@@ -229,47 +320,52 @@ For services running multiple replicas, the action applies to every replica simu
|
||||
|
||||
## Stack context menu
|
||||
|
||||
Right-click any stack in the sidebar to open the context menu. The menu adapts to the stack's current state; only relevant actions are shown.
|
||||
|
||||
**Running stack:**
|
||||
Click the kebab on a stack row in the sidebar to open its context menu. The menu adapts to the stack's current state; items are grouped by purpose.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/context-menu-running.png" alt="Context menu for a running stack" />
|
||||
<img src="/images/stack-management/context-menu.png" alt="Sidebar stack context menu showing inspect, organize, lifecycle, and destructive groups with keyboard shortcuts" />
|
||||
</Frame>
|
||||
|
||||
**Stopped stack:**
|
||||
**inspect**
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-management/context-menu-stopped.png" alt="Context menu for a stopped stack" />
|
||||
</Frame>
|
||||
- **Alerts** (`A`): open the alert rule editor for this stack. See [Alerts and Notifications](/features/alerts-notifications).
|
||||
- **Auto-Heal** (`H`): configure auto-recovery for this stack (Skipper+). See [Auto-Heal Policies](/features/auto-heal-policies).
|
||||
- **Auto-update** (`Enabled` or `Disabled`): toggle automatic updates for this stack (Skipper+). See [Auto-Update Policies](/features/auto-update-policies).
|
||||
- **Check updates** (`U`): force an image update check now.
|
||||
- **Open App** (`↗`): open the stack's web interface in a new tab. Shown only when the stack is running and exposes a web port.
|
||||
|
||||
### Available actions
|
||||
**organize**
|
||||
|
||||
- **Alerts** - configure metric-based alerting rules for this stack
|
||||
- **Labels** - assign organizational labels (Skipper+)
|
||||
- **Check for updates** - manually trigger an image update check
|
||||
- **Open App** - open the stack's web interface in a new tab (only shown when the stack is running and exposes a web port)
|
||||
- **Deploy** - start the stack (shown when stopped)
|
||||
- **Stop** - stop all containers (shown when running)
|
||||
- **Restart** - restart all containers (shown when running)
|
||||
- **Update** - pull latest images and recreate containers (shown when running)
|
||||
- **Delete** - stop and remove the stack (admin only)
|
||||
- **Labels** (`›`): assign or remove labels (Skipper+). See [Stack Labels](/features/stack-labels).
|
||||
- **Pin to top** (`P`): pin or unpin the stack from the **PINNED** group at the top of the list.
|
||||
|
||||
All actions are disabled while another operation is in progress on that stack.
|
||||
**lifecycle**
|
||||
|
||||
- **Stop** (`⌘.`): shown when running.
|
||||
- **Restart** (`⌘R`): shown when running.
|
||||
- **Update** (`⌘↑`): pulls the latest image tags and redeploys.
|
||||
- **Schedule task**: open the scheduler for this stack (Skipper+). See [Scheduled Operations](/features/scheduled-operations).
|
||||
- **Deploy** (`⌘↵`): shown when stopped, in place of Stop and Restart.
|
||||
|
||||
**destructive**
|
||||
|
||||
- **Delete** (`⌘⌫`): admin only.
|
||||
|
||||
Items are disabled while another operation is in progress on that stack.
|
||||
|
||||
## Scanning for stacks
|
||||
|
||||
If you place Docker Compose files directly into the stacks directory (for example, via `scp`, a file manager, or the command line), you can import them without going through the full "Create Stack" flow.
|
||||
|
||||
Click the **folder-search icon** next to the "Create Stack" button in the sidebar. Sencho scans the configured stacks directory and reports what it finds:
|
||||
If you place Docker Compose files directly into the stacks directory (for example, via `scp`, a file manager, or the command line), you can import them without going through the full **Create Stack** flow.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/stack-scanning/scan-button-sidebar.png" alt="Scan stacks folder button in the sidebar" />
|
||||
<img src="/images/stack-management/sidebar-actions.png" alt="Sidebar action row with Create Stack button, bulk mode toggle, and scan stacks folder icon button" />
|
||||
</Frame>
|
||||
|
||||
- **New stacks detected** - a success notification lists the newly discovered stack names, and they appear immediately in the sidebar
|
||||
- **Stacks removed from disk** - an informational notification lists stacks that are no longer present in the directory
|
||||
- **No changes** - a notification confirms no new stacks were found
|
||||
Click the **Scan stacks folder** icon button to the right of **Create Stack**. Sencho scans the configured stacks directory and reports what it finds:
|
||||
|
||||
- **New stacks detected**: a success notification lists the newly discovered stack names, and they appear immediately in the sidebar.
|
||||
- **Stacks removed from disk**: an informational notification lists stacks that are no longer present in the directory.
|
||||
- **No changes**: a notification confirms no new stacks were found.
|
||||
|
||||
<Tip>
|
||||
Any subdirectory inside your `COMPOSE_DIR` that contains a `compose.yaml`, `compose.yml`, `docker-compose.yaml`, or `docker-compose.yml` file is recognized as a valid stack.
|
||||
@@ -280,3 +376,7 @@ Click the **folder-search icon** next to the "Create Stack" button in the sideba
|
||||
### Service action returns a "service not found" error
|
||||
|
||||
The service name used in the action must match the `services:` key in the stack's `compose.yaml`. This error occurs when no running containers match that service name, either because the service was never deployed or because the compose file defines a different name. Verify the service key in your compose file and ensure the stack has been deployed at least once so containers exist for that service.
|
||||
|
||||
### Bulk **Update** is missing from the action bar
|
||||
|
||||
The bulk **Update** action is a Skipper-tier feature; on Community, it does not appear in the action bar at all. **Start**, **Stop**, and **Restart** are available on every tier.
|
||||
|
||||
@@ -9,7 +9,7 @@ Sencho is configured entirely through environment variables and Docker volume mo
|
||||
|
||||
| Variable | Description |
|
||||
|----------|-------------|
|
||||
| `COMPOSE_DIR` | Absolute path to the directory that contains your Compose stacks. Every subdirectory inside becomes a stack in Sencho. |
|
||||
| `COMPOSE_DIR` | Absolute path to the directory that contains your Compose stacks. Every subdirectory inside becomes a stack in Sencho. Falls back to `/app/compose` if unset, but per the [1:1 path rule](#compose-directory-the-11-path-rule) you should always set this explicitly to match the host path you mount. |
|
||||
|
||||
<Note>
|
||||
**JWT_SECRET is generated automatically.** Sencho creates a secure random signing key during initial setup and stores it in its database. You do not need to provide one.
|
||||
@@ -17,17 +17,29 @@ Sencho is configured entirely through environment variables and Docker volume mo
|
||||
|
||||
### How Sencho organizes your compose directory
|
||||
|
||||
When you point `COMPOSE_DIR` at a directory, Sencho expects each stack to live in its own subdirectory. If you create a stack through the UI, Sencho automatically creates a subfolder and places a blank `compose.yaml` inside it. Sencho does not move or "capture" existing files - it simply treats every subdirectory as a separate stack.
|
||||
When you point `COMPOSE_DIR` at a directory, Sencho expects each stack to live in its own subdirectory. If you create a stack through the UI, Sencho automatically creates a subfolder and places a blank `compose.yaml` inside it. Sencho does not move or "capture" existing files; it simply treats every subdirectory as a separate stack.
|
||||
|
||||
## Optional environment variables
|
||||
|
||||
| Variable | Default | Description |
|
||||
|----------|---------|-------------|
|
||||
| `PORT` | `1852` | Port the Sencho HTTP server listens on. |
|
||||
| `DATA_DIR` | `/app/data` | Directory where Sencho stores its SQLite database, node registry, and cached metrics. |
|
||||
| `FRONTEND_URL` | *(empty)* | Frontend origin for CORS. Only needed if the UI is served from a different domain than the API. Leave empty for same-origin setups. |
|
||||
| `NODE_ENV` | `production` | Set automatically in the Docker image. Only change this for local development. |
|
||||
| `SENCHO_USER` | *(unset)* | Optional. When set to a username present inside the container (`sencho` is pre-created for this purpose), the entrypoint drops privileges to that user at startup instead of running as `root`. See [Running as a non-root user](#running-as-a-non-root-user) below. |
|
||||
| `SENCHO_USER` | *(unset)* | When set to a username present inside the container (`sencho` is pre-created for this purpose), the entrypoint drops privileges to that user at startup instead of running as `root`. See [Running as a non-root user](#running-as-a-non-root-user) below. |
|
||||
| `API_RATE_LIMIT` | `200` | Global API requests per minute per user session. Applies in production only; development uses a fixed higher cap. Authenticated requests are keyed by user ID, unauthenticated by IP. Internal node-to-node traffic bypasses this limit. |
|
||||
| `API_POLLING_RATE_LIMIT` | `300` | Rate limit for dashboard polling endpoints, in requests per minute. Applies in production only; development uses a fixed higher cap. Raise it for environments with many concurrent browser sessions behind shared NAT. |
|
||||
|
||||
## Listen port
|
||||
|
||||
Sencho always listens on `1852` inside the container. The port is fixed and is not read from an environment variable. To expose Sencho on a different host port, remap with Docker's `-p` flag (or the `ports:` key in your compose file):
|
||||
|
||||
```yaml
|
||||
ports:
|
||||
- "8080:1852" # host 8080 to container 1852
|
||||
```
|
||||
|
||||
Behind a reverse proxy you can keep the standard mapping and let the proxy own the public port.
|
||||
|
||||
## Container user
|
||||
|
||||
@@ -71,7 +83,7 @@ If you use SSO (Admiral), configure your identity providers via environment vari
|
||||
| `SSO_OIDC_OKTA_ENABLED` | Enable Okta SSO |
|
||||
| `SSO_CALLBACK_URL` | External base URL for OAuth callbacks (required behind reverse proxy) |
|
||||
|
||||
For the full SSO configuration reference and setup guides, see [SSO Authentication →](/features/sso).
|
||||
For end-to-end provider setup walkthroughs, see the [SSO Quickstart →](/getting-started/sso-quickstart). For the full feature reference, see [SSO Authentication →](/features/sso).
|
||||
|
||||
## Required volume mounts
|
||||
|
||||
@@ -94,7 +106,7 @@ volumes:
|
||||
```
|
||||
|
||||
<Warning>
|
||||
Without a persistent data mount, Sencho will lose all configuration - including registered nodes, alerts, and settings - every time the container restarts.
|
||||
Without a persistent data mount, Sencho will lose all configuration (including registered nodes, alerts, and settings) every time the container restarts.
|
||||
</Warning>
|
||||
|
||||
### Compose directory - the 1:1 path rule
|
||||
@@ -103,7 +115,7 @@ volumes:
|
||||
This is the most common source of deployment problems. Read carefully.
|
||||
</Warning>
|
||||
|
||||
When Sencho runs `docker compose up`, it does so on your **host machine**. Docker resolves relative volume paths in your Compose files relative to the **host** path of the stack directory - not the path inside the Sencho container.
|
||||
When Sencho runs `docker compose up`, it does so on your **host machine**. Docker resolves relative volume paths in your Compose files relative to the **host** path of the stack directory, not the path inside the Sencho container.
|
||||
|
||||
**The rule:** Mount your Compose directory at the **exact same path** inside the container as it exists on your host.
|
||||
|
||||
@@ -270,4 +282,21 @@ Caddy automatically obtains and renews SSL certificates via Let's Encrypt. WebSo
|
||||
|
||||
## First boot
|
||||
|
||||
After starting Sencho, open it in your browser. If no admin account exists yet, you'll be taken to a setup screen to create one. This only appears once - subsequent visits go directly to the login page.
|
||||
After starting Sencho, open `http://localhost:1852` in a browser. On a fresh install you land on the **Cold start** card to create the first admin account; every subsequent visit goes to the regular sign-in screen. The [Quickstart](/getting-started/quickstart#first-boot) shows it in detail.
|
||||
|
||||
## Where to next
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Stack management" icon="layer-group" href="/features/stack-management">
|
||||
Deploy, edit, restart, update, and roll back stacks from the cockpit.
|
||||
</Card>
|
||||
<Card title="Multi-node" icon="sitemap" href="/features/multi-node">
|
||||
Add a remote Sencho instance and manage it from the same console.
|
||||
</Card>
|
||||
<Card title="Self-hosting" icon="server" href="/operations/self-hosting">
|
||||
Resource recommendations, networking, and Docker socket security.
|
||||
</Card>
|
||||
<Card title="SSO Quickstart" icon="key" href="/getting-started/sso-quickstart">
|
||||
End-to-end provider setup for OIDC, LDAP, and Active Directory.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
@@ -3,56 +3,120 @@ title: Introduction
|
||||
description: What Sencho is and why you might want it.
|
||||
---
|
||||
|
||||
Sencho is a self-hosted Docker Compose management dashboard. It gives you a clean web UI to deploy, manage, and monitor your Docker Compose stacks - locally or across multiple remote servers - without touching a terminal.
|
||||
Sencho is a self-hosted Docker Compose dashboard. It puts a cockpit on top of one Docker host or a fleet of them, so you can deploy stacks, watch them run, and intervene when something goes sideways without leaving the browser.
|
||||
|
||||
There is no SSH and no remote Docker socket. Every node is a Sencho instance talking to its own local Docker, and Sencho-to-Sencho calls go over plain HTTP with a token.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/dashboard/dashboard-overview.png" alt="Sencho dashboard showing system stats and container metrics" />
|
||||
<img src="/images/dashboard/dashboard-overview.png" alt="Sencho cockpit dashboard with status masthead, system gauges, and stack health table" />
|
||||
</Frame>
|
||||
|
||||
## Key concepts
|
||||
|
||||
- **Stacks** - a Docker Compose project living in your `COMPOSE_DIR`. Sencho treats each subdirectory as a stack.
|
||||
- **Nodes** - a Sencho instance. Your local machine is always the default node. Add remote nodes by pointing Sencho at another Sencho instance's API URL.
|
||||
- **Resources** - images, volumes, and networks that belong to your stacks (managed) or exist outside them (external/unused).
|
||||
A few words show up everywhere in Sencho. Knowing them up front makes the rest of the docs (and the UI) easier to read.
|
||||
|
||||
- **Stack** is one Compose project: a directory under `COMPOSE_DIR` with a `compose.yaml` and friends. Each subdirectory is one stack.
|
||||
- **Node** is a Sencho instance. The local node is always present. Remote nodes are added by their Sencho URL plus an API token; Sencho never reaches into them with SSH or a remote Docker socket.
|
||||
- **Fleet** is the set of nodes you manage from one console.
|
||||
- **Resources** are the images, volumes, and networks Docker accumulates, classified as managed (created by a stack), external (attached but not owned), or unused (safe to prune).
|
||||
- **Blueprint** is a declarative spec for one or more stacks, applied across selected nodes by a reconciler that converges drift back to the spec.
|
||||
- **Mesh** is a managed sidecar overlay that gives stacks stable service discovery to each other across nodes.
|
||||
- **Pilot** is an outbound agent that lets a node be managed by the console without exposing an inbound port.
|
||||
|
||||
<Note>
|
||||
Sencho never accesses remote servers directly via SSH or Docker TCP. Remote management works by proxying API requests to another running Sencho instance.
|
||||
Remote management is HTTP between Sencho instances. Each remote runs the same Sencho binary against its own local Docker; the console only proxies requests with a long-lived token.
|
||||
</Note>
|
||||
|
||||
## What you can do
|
||||
|
||||
### Stack lifecycle
|
||||
- **Deploy and control stacks** - create, start, stop, restart, update, roll back, and delete Compose stacks with one click
|
||||
- **Edit files in-browser** - full Monaco editor for `compose.yaml` and `.env` files with syntax highlighting, save-and-deploy in one step
|
||||
- **Atomic deployments** - automatic backup and rollback on every deploy. If containers crash, the previous configuration is restored automatically
|
||||
- **Stack labels** - organize stacks with custom labels for quick filtering and grouping
|
||||
### Run stacks like a cockpit, not a pile of YAML
|
||||
|
||||
### Monitoring & observability
|
||||
- **Real-time dashboard** - live CPU, RAM, disk, and network stats with 24-hour historical charts
|
||||
- **Global log aggregation** - stream logs from all containers across all stacks in a single view, with filtering by stack, level, and keyword search
|
||||
- **Alerts & notifications** - threshold-based alerts (CPU, memory, network, restart count) routed to Discord, Slack, or any webhook endpoint
|
||||
- **Notification routing** - fine-grained control over which alerts go to which channels
|
||||
- **Audit log** - searchable trail of every mutating action with timestamps, user attribution, and node context
|
||||
A selected stack opens with its container, live metrics, full log stream, anatomy panel (entrypoints, mounts, networks), and a row of actions across the top.
|
||||
|
||||
### Infrastructure
|
||||
- **Multi-node management** - add remote Sencho instances as nodes and manage them identically to your local machine
|
||||
- **Fleet view** - monitor your entire infrastructure from a single screen with health metrics, container counts, and resource usage
|
||||
- **Fleet-wide backups** - point-in-time snapshots of every compose and env file across all nodes, with per-stack restore
|
||||
- **Remote updates** - check for and apply Sencho updates across your fleet from the dashboard
|
||||
<Frame>
|
||||
<img src="/images/introduction/stack-view.png" alt="Plex stack open in Sencho with running container, anatomy panel, and live log stream" />
|
||||
</Frame>
|
||||
|
||||
### Resources & registry
|
||||
- **Resource hub** - browse, filter, and prune Docker images, volumes, and networks with managed/external/unused classification
|
||||
- **App Store** - deploy from 190+ pre-configured application templates with category filtering and one-click setup
|
||||
- **Private registries** - store credentials for Docker Hub, GHCR, AWS ECR, or self-hosted registries with automatic injection during deploys
|
||||
- Deploy, start, stop, restart, update, and roll back from one bar of buttons. See [Stack management](/features/stack-management).
|
||||
- Edit `compose.yaml` and `.env` in a built-in [Monaco editor](/features/editor) with syntax highlighting and save-and-deploy in one step.
|
||||
- Browse the on-disk files of a stack, including bind mounts, with the [stack file explorer](/features/stack-file-explorer).
|
||||
- Every deploy snapshots the prior configuration and rolls back automatically if the new containers fail to come up. See [atomic deployments](/features/atomic-deployments) for the exact behavior.
|
||||
- Organize at scale with [stack labels](/features/stack-labels) and filter chips in the [sidebar](/features/sidebar). Paste any `docker run` command into the create-stack flow and it converts to a Compose stack.
|
||||
|
||||
### Automation & integration
|
||||
- **Webhooks** - trigger stack actions from CI/CD pipelines via HTTP with HMAC-SHA256 authentication
|
||||
- **Scheduled operations** - run stack actions on a cron schedule directly from the UI
|
||||
- **Auto-update policies** - configure automatic image update checks and apply updates on your terms
|
||||
- **API tokens** - create scoped tokens for programmatic access and external integrations
|
||||
### Run one machine or many
|
||||
|
||||
### Administration
|
||||
- **RBAC** - create viewer accounts with read-only access while keeping deploy and edit permissions locked to admins
|
||||
- **SSO** - authenticate via external identity providers
|
||||
- **Host console** - interactive terminal on the host OS directly in the browser; no SSH required
|
||||
- **Docker Run converter** - paste any `docker run` command and convert it to a Compose stack
|
||||
Add a remote Sencho instance by URL and token and it becomes another node in the same surface. The fleet view holds the whole picture: status masthead, per-node CPU / RAM / disk, container counts, and version drift.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/introduction/fleet-overview.png" alt="Sencho fleet view with three node cards and per-node metrics" />
|
||||
</Frame>
|
||||
|
||||
- [Fleet view](/features/fleet-view) and [multi-node management](/features/multi-node) cover the basics: search, sort, expand, drill in.
|
||||
- [Fleet snapshots](/features/fleet-backups) (a.k.a. Sencho Cloud Backup) take point-in-time copies of every `compose.yaml` and `.env` across the fleet, with per-stack restore.
|
||||
- [Remote updates](/features/remote-updates) check the Sencho version on every node and apply per-node updates from the console.
|
||||
- [Fleet Actions](/features/fleet-actions) bundles fleet-wide bulk operations: stop every stack with a given label across the fleet, or apply a label set to many stacks on one node in a single round trip.
|
||||
- [Federation](/features/fleet-federation) gives the operator explicit overrides on top of the blueprint reconciler: cordon a node out of rotation, pin a stack to a host, hold ground while you investigate.
|
||||
- [Fleet Secrets](/features/fleet-secrets) stores versioned env-var bundles encrypted at rest and pushes them to selected stacks on selected nodes with a diff preview before any write.
|
||||
|
||||
### Mesh
|
||||
|
||||
Stacks on different nodes need to call each other often enough that doing it by hand is tedious and error-prone. [Sencho Mesh](/features/sencho-mesh) plants a managed sidecar in opted-in stacks and gives services stable hostnames across the fleet, with an activity stream you can watch in real time.
|
||||
|
||||
### Blueprints
|
||||
|
||||
[Blueprints](/features/blueprint-model) describe one or more stacks declaratively and apply them to selected nodes through a reconciler. The reconciler captures a compose snapshot before any stateful eviction, so reapplying a Blueprint is safe even when it replaces an existing stack.
|
||||
|
||||
### Monitoring and observability
|
||||
|
||||
- The [dashboard](/features/dashboard) hits you with a status line, a unified gauge strip, a stack-health table sorted by load, and a fleet heartbeat.
|
||||
- [Global observability](/features/global-observability) streams logs from every container on every node into one searchable view.
|
||||
- [Alerts](/features/alerts-notifications) on CPU, memory, disk, restart count, and similar thresholds, [routed](/features/notification-routing) to Discord, Slack, or any webhook by rules.
|
||||
- [Audit log](/features/audit-log) keeps a searchable trail of every mutating action with actor and node attribution.
|
||||
|
||||
### Resources you can actually clean up
|
||||
|
||||
The Resources hub treats images, volumes, and networks as a single inventory, classified as managed, external, or unused, with a "you can reclaim X" header so it is obvious what cleanup is worth doing.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/introduction/resources-hub.png" alt="Sencho Resources hub showing reclaimable disk space and image inventory with severity badges" />
|
||||
</Frame>
|
||||
|
||||
See [Resources](/features/resources) for the full hub, the [App Store](/features/app-store) for a library of one-click templates, and [private registries](/features/private-registries) for credential storage that injects automatically at deploy time.
|
||||
|
||||
### Security and identity
|
||||
|
||||
- [RBAC](/features/rbac) with five roles (admin, viewer, deployer, node admin, auditor) and per-capability scoped permissions.
|
||||
- [SSO](/features/sso) with custom OIDC, one-click presets for common providers, and LDAP / Active Directory.
|
||||
- [Two-factor authentication](/features/two-factor-authentication) with TOTP and backup codes.
|
||||
- [Vulnerability scanning](/features/vulnerability-scanning) via Trivy with [CVE suppressions](/features/cve-suppressions) and [deploy-blocking scan policies](/features/deploy-enforcement) on paid tiers.
|
||||
- [Image signature verification](/operations/verifying-images) for cosign-signed releases.
|
||||
|
||||
### Automation and integration
|
||||
|
||||
- [Webhooks](/features/webhooks) trigger stack actions from CI / CD with HMAC-SHA256 signatures.
|
||||
- [API tokens](/features/api-tokens) cover programmatic access for scripts and external tools.
|
||||
- [Scheduled operations](/features/scheduled-operations) run deploys, restarts, scans, and snapshots on cron.
|
||||
- [Auto-update policies](/features/auto-update-policies) check registries on a schedule and apply updates only on the rules you set.
|
||||
- [Auto-heal policies](/features/auto-heal-policies) restart containers that stay in an unhealthy Docker healthcheck state past a threshold, with cooldown and per-hour caps.
|
||||
|
||||
### Pilot and remote ops
|
||||
|
||||
Some nodes can't accept an inbound connection (CG-NAT, locked-down VLAN, no public IP). The [Pilot agent](/features/pilot-agent) opens an outbound tunnel to the console node so it can be managed without exposing a port. When you are already on a node and want to drop into a shell, the [host console](/features/host-console) gives you an interactive terminal in the browser.
|
||||
|
||||
## Tiers at a glance
|
||||
|
||||
Sencho ships in three tiers: **Community**, **Skipper**, and **Admiral**. Community covers single- and multi-node deploy, monitor, and security basics. Skipper adds automation, fleet secrets, and advanced fleet management. Admiral covers enterprise-grade controls (audit log, host console, cross-node Mesh traffic management, federation overrides, fleet-wide policy push). The full matrix lives on the [licensing page](/features/licensing).
|
||||
|
||||
## Where to next
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Quickstart" icon="rocket" href="/getting-started/quickstart">
|
||||
Install Sencho, deploy a first stack, add a node.
|
||||
</Card>
|
||||
<Card title="Configuration" icon="sliders" href="/getting-started/configuration">
|
||||
Environment variables, compose dir, and core settings.
|
||||
</Card>
|
||||
<Card title="Self-hosting" icon="server" href="/operations/self-hosting">
|
||||
Reverse proxy, TLS, backups, and production patterns.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
@@ -3,16 +3,46 @@ title: Quickstart
|
||||
description: Get Sencho running in under five minutes.
|
||||
---
|
||||
|
||||
This walks you from a clean Docker host to a working Sencho cockpit. Five minutes if your Compose directory is already in the right place, ten if you need to lay it out first.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Docker and Docker Compose installed on the host
|
||||
- A directory where your Compose projects live (e.g. `/opt/compose`)
|
||||
- Docker and Docker Compose installed on the host.
|
||||
- A directory where your Compose projects live (for example `/opt/compose`). Each subdirectory inside becomes one stack in Sencho.
|
||||
|
||||
## Run with Docker
|
||||
## Run with Docker Compose
|
||||
|
||||
Drop this into a `docker-compose.yml` next to your Compose tree (or anywhere convenient) and bring it up:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
sencho:
|
||||
image: saelix/sencho:latest
|
||||
container_name: sencho
|
||||
restart: unless-stopped
|
||||
ports:
|
||||
- "1852:1852"
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
- /opt/compose:/opt/compose # 1:1 path rule, see below
|
||||
- sencho_data:/app/data
|
||||
environment:
|
||||
- COMPOSE_DIR=/opt/compose
|
||||
|
||||
volumes:
|
||||
sencho_data:
|
||||
```
|
||||
|
||||
```bash
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
<Accordion title="Prefer docker run?">
|
||||
|
||||
```bash
|
||||
docker run -d \
|
||||
--name sencho \
|
||||
--restart unless-stopped \
|
||||
-p 1852:1852 \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
-v /opt/compose:/opt/compose \
|
||||
@@ -21,24 +51,63 @@ docker run -d \
|
||||
saelix/sencho:latest
|
||||
```
|
||||
|
||||
Open `http://localhost:1852` in your browser. On first boot you'll be prompted to create an admin account.
|
||||
|
||||
<Note>
|
||||
Replace `/opt/compose` with the path to your Compose projects directory. Every subdirectory inside it becomes a stack in Sencho. A `JWT_SECRET` is generated automatically on first boot; you do not need to provide one.
|
||||
</Note>
|
||||
</Accordion>
|
||||
|
||||
<Tip>
|
||||
Sencho is also published on GitHub Container Registry at `ghcr.io/studio-saelix/sencho:latest` with the same tags and content as Docker Hub. Pull from whichever registry your environment prefers.
|
||||
Sencho is mirrored on GitHub Container Registry at `ghcr.io/studio-saelix/sencho:latest` with the same tags and digests as Docker Hub. Pull from whichever registry your environment prefers.
|
||||
</Tip>
|
||||
|
||||
## Important: the 1:1 path rule
|
||||
<Note>
|
||||
`JWT_SECRET` is generated on first boot and persisted to the database. You do not need to provide one.
|
||||
</Note>
|
||||
|
||||
The compose directory must be mounted at the **same path** inside and outside the container. The example above mounts `/opt/compose` to `/opt/compose`, which is correct. If your stacks live at a different path, adjust both sides of the mount to match. See the [Configuration guide](/getting-started/configuration#compose-directory-the-11-path-rule) for details.
|
||||
## The 1:1 path rule
|
||||
|
||||
## Next steps
|
||||
The Compose directory must be mounted at the **same path** inside and outside the container. The example above mounts `/opt/compose` to `/opt/compose`, which is correct. If your stacks live somewhere else, adjust both sides of the mount to match.
|
||||
|
||||
- [Configuration](/getting-started/configuration) - environment variables, volume mounts, reverse proxy setup
|
||||
- [Features Overview](/features/overview) - tour of everything Sencho can do
|
||||
- [Stack Management](/features/stack-management) - create and deploy your first stack
|
||||
- [Multi-Node](/features/multi-node) - add a remote server to manage from this dashboard
|
||||
- [App Store](/features/app-store) - deploy from 190+ pre-configured templates
|
||||
<Warning>
|
||||
This is the most common source of deployment problems. If the host and container paths differ, every relative volume in your Compose files will resolve to the wrong location once Sencho asks Docker to bring a stack up. See the [Configuration guide](/getting-started/configuration#compose-directory-the-11-path-rule) for the full explanation.
|
||||
</Warning>
|
||||
|
||||
## First boot
|
||||
|
||||
Open `http://localhost:1852` in a browser. On a fresh install you land on the **Cold start** card, where Sencho asks you to create the first admin account.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/quickstart/setup-cold-start.png" alt="Sencho first-boot Cold start card with Username, Password, and Confirm password fields, and an Initialize console button" />
|
||||
</Frame>
|
||||
|
||||
Pick a username (the placeholder shows `admin`), choose a password, confirm it, and click **Initialize console**. The strength indicator under the password field expects at least eight characters.
|
||||
|
||||
<Note>
|
||||
The Cold start card only appears the first time you open Sencho. Once the admin account exists, every subsequent visit goes to the regular sign-in screen.
|
||||
</Note>
|
||||
|
||||
## After signing in
|
||||
|
||||
You land on the dashboard. A status bar across the top tells you whether the fleet is healthy, the gauge strip below it shows CPU, memory, disk, and network at a glance, and the **Stack health** table sorts your stacks by load.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/quickstart/dashboard.png" alt="Sencho dashboard with status bar across the top, CPU/MEMORY/DISK/NETWORK gauges, and a Stack health table sorted by load" />
|
||||
</Frame>
|
||||
|
||||
The top nav (HOME, FLEET, RESOURCES, APP STORE, LOGS, AUTO-UPDATE, CONSOLE, AUDIT, SCHEDULES) is your map of the cockpit. The sidebar on the left lists every stack Sencho discovered under `COMPOSE_DIR`; on a fresh install it is empty until you create one.
|
||||
|
||||
Click **Create Stack** in the sidebar to deploy your first stack, or open **App Store** in the top nav for a one-click template.
|
||||
|
||||
## Where to next
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Configuration" icon="sliders" href="/getting-started/configuration">
|
||||
Environment variables, volume mounts, reverse proxy, and the 1:1 path rule in detail.
|
||||
</Card>
|
||||
<Card title="Stack management" icon="layer-group" href="/features/stack-management">
|
||||
Deploy, edit, restart, update, and roll back stacks from the cockpit.
|
||||
</Card>
|
||||
<Card title="Multi-node" icon="server" href="/features/multi-node">
|
||||
Add a remote Sencho instance and manage it from the same console.
|
||||
</Card>
|
||||
<Card title="App Store" icon="grid-2" href="/features/app-store">
|
||||
Browse 190+ pre-configured templates and deploy in one click.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
@@ -3,12 +3,25 @@ title: SSO Setup Guide
|
||||
description: Step-by-step instructions for connecting Sencho to your identity provider.
|
||||
---
|
||||
|
||||
SSO can be configured via environment variables (shown below) or from the Settings UI after first boot.
|
||||
SSO can be configured from the Settings UI or seeded via environment variables (shown below).
|
||||
|
||||
<Note>
|
||||
**Tier availability.** Custom OIDC is available on every tier, including Community. The Google, GitHub, and Okta one-click presets require Skipper or higher. LDAP / Active Directory requires Admiral. See [Licensing & Billing](/features/licensing#feature-breakdown) for the full breakdown.
|
||||
**Tier availability.** Custom OIDC is available on every tier, including Community. The Google, GitHub, and Okta preset providers require Skipper or higher. LDAP / Active Directory requires Admiral. See [Licensing & Billing](/features/licensing#feature-breakdown) for the full breakdown.
|
||||
</Note>
|
||||
|
||||
<Frame>
|
||||
<img src="/images/sso/sso-quickstart-overview.png" alt="Settings > SSO panel showing all five provider cards with PROVIDERS and ENABLED stats in the masthead" />
|
||||
</Frame>
|
||||
|
||||
## How to configure
|
||||
|
||||
You can wire SSO two ways. Both reach the same database row, and you can mix and match.
|
||||
|
||||
- **Environment variables** seed the SSO configuration the first time Sencho boots with that variable set. They are useful for infrastructure-as-code, fresh deployments, and disaster recovery. After a configuration row exists in the database, the database is authoritative; subsequent restarts do not re-read the env vars or overwrite changes you made in the UI.
|
||||
- **Settings > SSO** in the dashboard lets admins enable, edit, save, and remove providers without restarting. Changes apply immediately. Each provider card has a **Test Connection** button that validates connectivity before you commit (LDAP bind plus search for LDAP, OIDC discovery plus token endpoint reachability for OIDC).
|
||||
|
||||
If you want a guided UI walkthrough rather than the env-var path below, jump to the [SSO feature page](/features/sso#configuration).
|
||||
|
||||
## Google OIDC
|
||||
|
||||
1. Go to the [Google Cloud Console](https://console.cloud.google.com/apis/credentials)
|
||||
@@ -33,7 +46,7 @@ services:
|
||||
- /opt/compose:/opt/compose
|
||||
```
|
||||
|
||||
Restart Sencho. A "Google" button will appear on the login page.
|
||||
A **Google** button appears on the login page after the first boot with these variables set. To override the button label, set `SSO_OIDC_GOOGLE_DISPLAY_NAME` (and the equivalent `_DISPLAY_NAME` variable for any other provider).
|
||||
|
||||
## GitHub OAuth
|
||||
|
||||
@@ -128,12 +141,20 @@ If your provider uses non-standard claim names, add claim mapping:
|
||||
- SSO_LDAP_DEFAULT_ROLE=viewer
|
||||
```
|
||||
|
||||
After starting Sencho, verify the connection in **Settings > SSO** using the **Test Connection** button.
|
||||
Once Sencho is running, open **Settings > SSO**, expand the LDAP card, and click **Test Connection**. Sencho binds with the service account, runs the search filter, and reports the result inline.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/sso/sso-quickstart-ldap-test.png" alt="LDAP provider card expanded showing the configuration form with example values, the Verify TLS certificate toggle, and Save and Test Connection buttons" />
|
||||
</Frame>
|
||||
|
||||
<Warning>
|
||||
If your LDAP server is on the Docker host (not in a container), use the host's LAN IP or `host.docker.internal` (Docker Desktop) instead of `localhost`.
|
||||
</Warning>
|
||||
|
||||
<Tip>
|
||||
For self-signed LDAPS certificates, set `SSO_LDAP_TLS_REJECT_UNAUTHORIZED=false` (or untick **Verify TLS certificate** in the UI). Use only when you control the certificate authority.
|
||||
</Tip>
|
||||
|
||||
## Role mapping
|
||||
|
||||
By default, all SSO users are assigned the **Viewer** role. To grant Admin to specific users:
|
||||
@@ -188,6 +209,7 @@ services:
|
||||
- SSO_LDAP_SEARCH_BASE=ou=users,dc=example,dc=com
|
||||
- SSO_LDAP_SEARCH_FILTER=(sAMAccountName={{username}})
|
||||
- SSO_LDAP_ADMIN_GROUP_DN=cn=sencho-admins,ou=groups,dc=example,dc=com
|
||||
# - SSO_LDAP_TLS_REJECT_UNAUTHORIZED=false # uncomment for self-signed LDAPS
|
||||
# Role mapping & callback
|
||||
- SSO_OIDC_ADMIN_CLAIM=groups
|
||||
- SSO_OIDC_ADMIN_CLAIM_VALUE=sencho-admins
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 243 KiB After Width: | Height: | Size: 252 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 120 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 119 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 117 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 185 KiB After Width: | Height: | Size: 123 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 122 KiB After Width: | Height: | Size: 141 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 222 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 192 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 198 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 200 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 132 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 123 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 105 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 142 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 216 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 104 KiB After Width: | Height: | Size: 180 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 153 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 191 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 180 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 112 KiB After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 140 KiB After Width: | Height: | Size: 62 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 53 KiB After Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 58 KiB After Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 116 KiB After Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 142 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 146 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 182 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 141 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 334 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 156 KiB After Width: | Height: | Size: 174 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 91 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 70 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.2 KiB After Width: | Height: | Size: 7.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 244 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 214 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 172 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 243 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 138 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 245 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 162 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 212 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 250 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 126 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 123 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 91 KiB After Width: | Height: | Size: 127 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 96 KiB After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 92 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 80 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 129 KiB After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 137 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 70 KiB |
Reference in New Issue
Block a user