mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-10 18:56:53 +00:00
Anso
efbd20fed5
* feat(labels): add stack_labels schema and DatabaseService CRUD methods
* feat(labels): add label CRUD, assignment, and bulk action API routes
* feat(labels): add oklch label color palette for light and dark themes
* feat(labels): add LabelPill and LabelDot reusable components
* feat(labels): add LabelAssignPopover component for inline label management
* feat(labels): add label pill bar, label dots, and label assignment to sidebar
* feat(labels): add label filtering and label dots to fleet view
* feat(labels): add label-scoped bulk actions (deploy/stop/restart all)
* docs: add Stack Labels feature documentation
* fix(labels): use context menu sub-menu for label assignment and add settings integration
Replace broken Popover-inside-ContextMenu pattern with native Radix
ContextMenuSub for reliable label toggling on right-click. Wrap
ContextMenuSubContent in a Portal to prevent overflow clipping. Add
"Manage labels..." item that opens Settings directly to Labels section.
Fix close button overlap in LabelsSection header. Add LabelsSection
settings component with full CRUD, assignment counts, and ProGate.
Add initialSection prop to SettingsModal for deep-linking. Include
screenshots for documentation.
* docs: update stack labels documentation with screenshots and corrected instructions
* fix(labels): address security and quality issues from code review
- Add NaN validation on parseInt(req.params.id) in label routes
- Scope updateLabel/deleteLabel by nodeId to prevent cross-node IDOR
- Validate labelIds belong to correct node in setStackLabels
- Add requireAdmin check on bulk action endpoint
- Replace error: any with error: unknown and proper narrowing
- Remove unused Label import from index.ts
- Remove unused isPro prop from LabelsSection
- Add strokeWidth={1.5} to Check icons per design system
* chore: update CHANGELOG with stack labels feature
* feat(nodes): add per-node scheduling and update visibility
Add Schedules and Updates columns to the Nodes table showing active
task counts, next run times, and auto-update status per node. A calendar
action button navigates to filtered schedule/auto-update views.
Backend changes:
- Add node_id to stack_update_status table (migration + unique index)
- Cascade cleanup on node deletion (scheduled_tasks + update status)
- Pre-check target node existence/status before executing scheduled tasks
- New GET /api/nodes/scheduling-summary endpoint
- New GET /api/image-updates/fleet endpoint with 2-minute cache
- Parallelize remote node fetches with Promise.allSettled
- Wrap deleteNode cascade in a transaction
Frontend changes:
- NodeManager: Schedules/Updates columns with summary data fetch
- EditorLayout: sencho-navigate event listener for cross-component nav
- ScheduledOperationsView/AutoUpdatePoliciesView: filterNodeId prop,
filter bar UI, pre-selected node in create dialog
120 lines
5.6 KiB
Plaintext
120 lines
5.6 KiB
Plaintext
---
|
|
title: "Auto-Update Policies"
|
|
description: "Automatically check for and apply container image updates on a schedule."
|
|
---
|
|
|
|
<Note>
|
|
Auto-Update Policies require a **Skipper** or **Admiral** license.
|
|
</Note>
|
|
|
|
## Overview
|
|
|
|
Auto-Update Policies let you define schedules for Sencho to automatically check your container images for updates and apply them when new versions are available. Think of it as a built-in Watchtower — but integrated directly into your Sencho dashboard with full visibility into what was updated and when.
|
|
|
|
Each policy targets a specific stack and runs on a cron schedule. When triggered, Sencho:
|
|
|
|
1. Inspects every container in the target stack
|
|
2. Compares local image digests against the remote registry
|
|
3. If any image has a newer version, pulls the update and recreates the stack with `docker compose up -d`
|
|
4. Records the result in run history for auditability
|
|
|
|
<Frame>
|
|
<img src="/images/auto-update-policies/overview.png" alt="Auto-Update Policies view showing the policies list" />
|
|
</Frame>
|
|
|
|
## Creating a Policy
|
|
|
|
Navigate to **Auto-Update** in the sidebar and click **New Policy**.
|
|
|
|
<Frame>
|
|
<img src="/images/auto-update-policies/create-dialog.png" alt="Create auto-update policy dialog" />
|
|
</Frame>
|
|
|
|
Fill in the following fields:
|
|
|
|
| Field | Description |
|
|
|-------|-------------|
|
|
| **Name** | A descriptive name for the policy (e.g., "Nightly media stack update") |
|
|
| **Node** | The node where the target stack runs |
|
|
| **Stack** | The stack to monitor and update |
|
|
| **Schedule** | A cron expression or preset defining how often to check |
|
|
|
|
### Schedule Presets
|
|
|
|
For convenience, Sencho offers common schedule presets:
|
|
|
|
| Preset | Cron Expression | Description |
|
|
|--------|----------------|-------------|
|
|
| Every 6 hours | `0 */6 * * *` | Check four times per day |
|
|
| Every 12 hours | `0 */12 * * *` | Check twice per day |
|
|
| Daily at 3 AM | `0 3 * * *` | Low-traffic window for most users |
|
|
| Daily at midnight | `0 0 * * *` | Start of each day |
|
|
| Weekly (Sunday 3 AM) | `0 3 * * 0` | Minimal disruption for stable stacks |
|
|
| Custom | User-defined | Any valid cron expression |
|
|
|
|
## Filtering by Node
|
|
|
|
In a multi-node environment, you can filter the policy list to show only policies targeting a specific node. Click the **calendar icon** on any node row in **Settings → Nodes** to jump directly to a filtered view. A filter bar at the top shows the active node, with a **Clear filter** button to return to the full list.
|
|
|
|
## Managing Policies
|
|
|
|
Each policy in the list shows:
|
|
|
|
- **Name** and target stack
|
|
- **Schedule** in human-readable form (e.g., "Every 6 hours")
|
|
- **Status** — enabled or disabled
|
|
- **Last run** — when it last executed and whether it succeeded
|
|
- **Next run** — when it will execute next
|
|
|
|
### Available Actions
|
|
|
|
- **Toggle** — Enable or disable a policy without deleting it
|
|
- **Run Now** — Trigger an immediate check-and-update cycle
|
|
- **Edit** — Modify the policy name, target, or schedule
|
|
- **Delete** — Permanently remove the policy
|
|
|
|
## Run History
|
|
|
|
Click the clock icon on any policy to view its run history. Each entry shows:
|
|
|
|
- **Timestamp** — When the run started
|
|
- **Status** — Success or failure
|
|
- **Output** — Detailed log of what was checked and whether updates were applied
|
|
|
|
This gives you full auditability over what changed and when.
|
|
|
|
## How It Works
|
|
|
|
Under the hood, Auto-Update Policies are built on the same scheduling engine as [Scheduled Operations](/features/scheduled-operations). The key difference is that auto-update policies:
|
|
|
|
- Are available to **Skipper** tier (Scheduled Operations requires Admiral)
|
|
- Always target a **stack** (not individual containers)
|
|
- Perform a **check-then-update** flow rather than a blind restart
|
|
|
|
### The Check-Then-Update Flow
|
|
|
|
1. **Enumerate images** — Sencho lists all unique images used by containers in the target stack
|
|
2. **Check digests** — For each image, Sencho compares the local `RepoDigests` against the remote registry manifest digest
|
|
3. **Conditional update** — Only if at least one image has a newer version does Sencho run `docker compose up -d` to pull and recreate
|
|
4. **Clear indicators** — After a successful update, the blue update indicator dot is automatically cleared
|
|
|
|
If no updates are found, the run completes with a "No updates available" message and no containers are restarted.
|
|
|
|
## Relationship to Image Update Detection
|
|
|
|
Sencho has two complementary features for keeping your images current:
|
|
|
|
| Feature | Purpose | Tier |
|
|
|---------|---------|------|
|
|
| **Image Update Detection** | Passive — shows a blue dot on stacks with available updates | All tiers |
|
|
| **Auto-Update Policies** | Active — automatically applies updates on a schedule | Skipper+ |
|
|
|
|
Image Update Detection runs in the background every 6 hours and highlights stacks that have newer images available. Auto-Update Policies take this a step further by automatically applying those updates based on your defined schedule.
|
|
|
|
## Best Practices
|
|
|
|
- **Start with longer intervals** — Use "Daily at 3 AM" or "Weekly" for production stacks. Reserve shorter intervals for dev/staging environments.
|
|
- **Pin critical images** — If a stack uses `image: postgres:16.2` (pinned tag), auto-update will only detect updates to that exact tag. Use floating tags like `postgres:16` if you want minor version updates.
|
|
- **Monitor run history** — Check run history periodically to ensure updates are applying cleanly. Failed runs may indicate registry authentication issues or compose file problems.
|
|
- **Combine with notifications** — Sencho sends alert notifications when auto-updates are applied, so you stay informed even when updates happen automatically.
|