Documentation Reorganization

Major upgrade to the documentation.
This commit is contained in:
kelinfoxy
2026-01-20 19:01:21 -05:00
parent 15582a36ad
commit 16b7e1f1a7
31 changed files with 2784 additions and 3026 deletions

View File

@@ -588,3 +588,15 @@ Authelia is your homelab's security layer. It:
- Integrates seamlessly with Traefik
Setting up Authelia properly is one of the most important security steps for your homelab. Take time to understand access control rules and test your configuration thoroughly. Always keep the `users_database.yml` and `db.sqlite3` backed up, as they contain critical authentication data.
## Related Services
- **[Traefik](traefik.md)** - Reverse proxy that integrates with Authelia for authentication
- **[DuckDNS](duckdns.md)** - Dynamic DNS required for SSL certificates
- **[Sablier](sablier.md)** - Lazy loading that can work with Authelia-protected services
## See Also
- **[SSO Bypass Guide](../docker-guidelines.md#when-to-use-authelia-sso)** - When to disable authentication for services
- **[2FA Setup](../getting-started.md#set-up-2fa-with-authelia)** - Enable two-factor authentication
- **[Access Control Rules](../docker-guidelines.md#authelia-bypass-example-jellyfin)** - Configure bypass rules for specific services

View File

@@ -1,151 +1,244 @@
# Backrest - Backup Solution
# Backrest - Comprehensive Backup Solution
## Table of Contents
- [Overview](#overview)
- [What is Backrest?](#what-is-backrest)
- [Why Use Backrest?](#why-use-backrest)
- [Configuration in AI-Homelab](#configuration-in-ai-homelab)
- [Official Resources](#official-resources)
- [Docker Configuration](#docker-configuration)
**Category:** Backup & Recovery
**Description:** Backrest is a web-based UI for Restic, providing scheduled backups, retention policies, and a beautiful interface for managing backups across multiple repositories and destinations. It serves as the default backup strategy for AI-Homelab.
**Docker Image:** `garethgeorge/backrest:latest`
**Documentation:** [Backrest GitHub](https://github.com/garethgeorge/backrest)
## Overview
**Category:** Backup & Recovery
**Docker Image:** [garethgeorge/backrest](https://hub.docker.com/r/garethgeorge/backrest)
**Default Stack:** `utilities.yml`
**Web UI:** `http://SERVER_IP:9898`
**Backend:** Restic
**Ports:** 9898
### What is Backrest?
Backrest (latest: v1.10.1) is a web-based UI for Restic, built with Go and SvelteKit. It simplifies Restic management:
- **Web Interface**: Create repos, plans, and monitor backups.
- **Automation**: Scheduled backups, hooks (pre/post commands).
- **Integration**: Runs Restic under the hood.
- **Features**: Multi-repo support, retention policies, notifications.
## What is Backrest?
### What is Restic?
Restic (latest: v0.18.1) is a modern, open-source backup program written in Go. It provides:
- **Deduplication**: Efficiently stores only changed data.
- **Encryption**: All data is encrypted with AES-256.
- **Snapshots**: Point-in-time backups with metadata.
- **Cross-Platform**: Works on Linux, macOS, Windows.
- **Backends**: Supports local, SFTP, S3, etc.
- **Features**: Compression, locking, pruning, mounting snapshots.
Backrest is a web UI and orchestration layer for Restic, a powerful backup tool. It provides scheduled backups, retention policies, and a beautiful interface for managing backups across multiple repositories and destinations. Think of it as a user-friendly wrapper around Restic's power.
## Configuration
### Key Features
- **Web Interface:** Manage backups visually
- **Multiple Repos:** Backup to different locations
- **Schedules:** Cron-based automatic backups
- **Retention Policies:** Keep last N backups
- **Compression:** Automatic compression
- **Deduplication:** Save storage space
- **Encryption:** AES-256 encryption
- **Destinations:** Local, S3, B2, SFTP, WebDAV
- **Notifications:** Alerts on failure
- **Browse & Restore:** Visual file restoration
### Environment Variables
## Why Use Backrest?
| Variable | Description | Default |
|----------|-------------|---------|
| `BACKREST_DATA` | Internal data directory | `/data` |
| `BACKREST_CONFIG` | Configuration file path | `/config/config.json` |
| `BACKREST_UI_CONFIG` | UI configuration JSON | `{"baseURL": "https://backrest.${DOMAIN}"}` |
1. **Easy Backups:** Simple web interface
2. **Restic Power:** Proven backup engine
3. **Automated:** Set and forget
4. **Multiple Destinations:** Flexibility
5. **Encrypted:** Secure backups
6. **Deduplicated:** Efficient storage
7. **Free & Open Source:** No cost
### Ports
## Configuration in AI-Homelab
- **9898** - Web UI port
```
/opt/stacks/utilities/backrest/data/ # Backrest config
/opt/stacks/utilities/backrest/cache/ # Restic cache
### Volumes
- `./data:/data` - Backrest internal data and repositories
- `./config:/config` - Configuration files
- `./cache:/cache` - Restic cache for performance
- `/var/lib/docker/volumes:/docker_volumes:ro` - Access to Docker volumes
- `/opt/stacks:/opt/stacks:ro` - Access to service configurations
- `/var/run/docker.sock:/var/run/docker.sock` - Docker API access for hooks
## Usage
### Accessing Backrest
- **URL**: `https://backrest.${DOMAIN}`
- **Authentication**: Via Authelia SSO
- **UI Sections**: Repos, Plans, Logs
### Managing Repositories
Repositories store your backups. Create one for your main backup location.
#### Create Repository
1. Go to **Repos****Add Repo**
2. **Name**: `main-backup-repo`
3. **Storage**: Choose backend (Local, SFTP, S3, etc.)
4. **Password**: Set strong encryption password
5. **Initialize**: Backrest runs `restic init`
### Creating Backup Plans
Plans define what, when, and how to back up.
#### Database Backup Plan (Recommended)
```json
{
"id": "database-backup",
"repo": "main-backup-repo",
"paths": [
"/docker_volumes/*_mysql/_data",
"/docker_volumes/*_postgres/_data"
],
"schedule": {
"maxFrequencyDays": 1
},
"hooks": [
{
"actionCommand": {
"command": "for vol in $(docker volume ls -q | grep '_mysql$'); do docker ps -q --filter volume=$vol | xargs -r docker stop || true; done"
},
"conditions": ["CONDITION_SNAPSHOT_START"]
},
{
"actionCommand": {
"command": "for vol in $(docker volume ls -q | grep '_mysql$'); do docker ps -a -q --filter volume=$vol | xargs -r docker start || true; done"
},
"conditions": ["CONDITION_SNAPSHOT_END"]
}
],
"retention": {
"policyKeepLastN": 30
}
}
```
## Official Resources
#### Service Configuration Backup Plan
```json
{
"id": "config-backup",
"repo": "main-backup-repo",
"paths": [
"/opt/stacks"
],
"excludes": [
"**/cache",
"**/tmp",
"**/log"
],
"schedule": {
"maxFrequencyDays": 1
},
"retention": {
"policyKeepLastN": 14
}
}
```
- **GitHub:** https://github.com/garethgeorge/backrest
- **Restic:** https://restic.net
### Running Backups
- **Manual**: Plans → Select plan → **Run Backup Now**
- **Scheduled**: Runs automatically per plan schedule
- **Monitor**: Check **Logs** tab for status and errors
## Docker Configuration
### Restoring Data
1. Go to **Repos** → Select repo → **Snapshots**
2. Choose snapshot → **Restore**
3. Select paths/files → Set target directory
4. Run restore operation
## Best Practices
### Security
- Use strong repository passwords
- Limit Backrest UI access via Authelia
- Store passwords securely (not in config files)
### Performance
- Schedule backups during low-usage hours
- Use compression for large backups
- Monitor repository size growth
### Retention
- Keep 30 daily snapshots for critical data
- Keep 14 snapshots for configurations
- Regularly prune old snapshots
### Testing
- Test restore procedures regularly
- Verify backup integrity
- Document restore processes
## Integration with AI-Homelab
### Homepage Dashboard
Add Backrest to your Homepage dashboard:
```yaml
backrest:
image: garethgeorge/backrest:latest
container_name: backrest
restart: unless-stopped
networks:
- traefik-network
ports:
- "9898:9898"
environment:
- BACKREST_DATA=/data
- BACKREST_CONFIG=/config/config.json
- XDG_CACHE_HOME=/cache
volumes:
- /opt/stacks/utilities/backrest/data:/data
- /opt/stacks/utilities/backrest/config:/config
- /opt/stacks/utilities/backrest/cache:/cache
- /opt/stacks:/backup-source:ro # What to backup
labels:
- "traefik.enable=true"
- "traefik.http.routers.backrest.rule=Host(`backrest.${DOMAIN}`)"
# In homepage/services.yaml
- Infrastructure:
- Backrest:
icon: backup.png
href: https://backrest.${DOMAIN}
description: Backup management
widget:
type: iframe
url: https://backrest.${DOMAIN}
```
## Setup
### Monitoring
Monitor backup success with Uptime Kuma or Grafana alerts.
1. **Start Container:**
```bash
docker compose up -d backrest
```
## Troubleshooting
2. **Access UI:** `http://SERVER_IP:9898`
### Common Issues
3. **Create Repository:**
- Add Repository
- Location: Local, S3, B2, etc.
- Encryption password
- Initialize repository
**Backup Failures**
- Check repository access and credentials
- Verify source paths exist and are readable
- Review hook commands for syntax errors
4. **Create Plan:**
- Add backup plan
- Source: `/backup-source` (mounted volume)
- Repository: Select created repo
- Schedule: `0 2 * * *` (2 AM daily)
- Retention: Keep last 7 daily, 4 weekly, 12 monthly
**Hook Issues**
- Ensure Docker socket is accessible
- Check that containers can be stopped/started
- Verify hook commands work manually
5. **Run Backup:**
- Manual: Click "Backup Now"
- Or wait for schedule
**Performance Problems**
- Check available disk space
- Monitor CPU/memory usage during backups
- Consider excluding large, frequently changing files
6. **Restore:**
- Browse backups
- Select snapshot
- Browse files
- Restore to location
**Restore Issues**
- Ensure target directory exists and is writable
- Check file permissions
- Verify snapshot integrity
## Summary
## Advanced Features
Backrest provides web-based backup management offering:
- Visual Restic interface
- Scheduled automated backups
- Multiple backup destinations
- Retention policies
- Encryption and deduplication
- Easy restore
- Free and open-source
### Multiple Repositories
- **Local**: For fast, local backups
- **Remote**: SFTP/S3 for offsite storage
- **Hybrid**: Local for speed, remote for safety
**Perfect for:**
- Homelab backups
- Docker volume backups
- Off-site backup management
- Automated backup schedules
- Visual backup management
### Custom Hooks
```bash
# Pre-backup: Stop services
docker compose -f /opt/stacks/core/docker-compose.yml stop
**Key Points:**
- Built on Restic
- Web interface
- Supports many backends
- Encryption by default
- Deduplication saves space
- Cron-based scheduling
- Easy restore interface
# Post-backup: Start services
docker compose -f /opt/stacks/core/docker-compose.yml start
```
**Remember:**
- Mount volumes to backup
- Set retention policies
- Test restores regularly
- Off-site backup recommended
- Keep repository password safe
- Monitor backup success
- Schedule during low usage
### Notifications
Configure webhooks in Backrest settings for backup status alerts.
Backrest makes Restic backups manageable!
## Migration from Other Solutions
### From Duplicati
1. Export Duplicati configurations
2. Create equivalent Backrest plans
3. Test backups and restores
4. Decommission Duplicati
### From Manual Scripts
1. Identify current backup sources and schedules
2. Create Backrest plans with same parameters
3. Add appropriate hooks for service management
4. Test and validate
## Related Documentation
- **[Backup Strategy Guide](../Restic-BackRest-Backup-Guide.md)** - Comprehensive setup and usage guide
- **[Docker Guidelines](../docker-guidelines.md)** - Volume management and persistence
- **[Quick Reference](../quick-reference.md)** - Command reference and troubleshooting
---
**Backrest provides enterprise-grade backup capabilities with an intuitive web interface, making it the perfect default backup solution for AI-Homelab.**

View File

@@ -0,0 +1,532 @@
# Sablier - Lazy Loading Service
## Table of Contents
- [Overview](#overview)
- [What is Sablier?](#what-is-sablier)
- [Why Use Sablier?](#why-use-sablier)
- [How It Works](#how-it-works)
- [Configuration in AI-Homelab](#configuration-in-ai-homelab)
- [Official Resources](#official-resources)
- [Educational Resources](#educational-resources)
- [Docker Configuration](#docker-configuration)
- [Using Sablier](#using-sablier)
- [Advanced Topics](#advanced-topics)
- [Troubleshooting](#troubleshooting)
## Overview
**Category:** Core Infrastructure
**Docker Image:** [sablierapp/sablier](https://hub.docker.com/r/sablierapp/sablier)
**Default Stack:** `core.yml`
**Web UI:** No web UI (API only)
**Authentication:** None required
**Purpose:** On-demand container startup and resource management
## What is Sablier?
Sablier is a lightweight service that enables lazy loading for Docker containers. It automatically starts containers when they're accessed through Traefik and stops them after a period of inactivity, helping to conserve system resources and reduce power consumption.
### Key Features
- **On-Demand Startup:** Containers start automatically when accessed
- **Automatic Shutdown:** Containers stop after configurable inactivity periods
- **Traefik Integration:** Works seamlessly with Traefik reverse proxy
- **Resource Conservation:** Reduces memory and CPU usage for unused services
- **Group Management:** Related services can be managed as groups
- **Health Checks:** Waits for services to be ready before forwarding traffic
- **Minimal Overhead:** Lightweight with low resource requirements
## Why Use Sablier?
1. **Resource Efficiency:** Save memory and CPU by only running services when needed
2. **Power Savings:** Reduce power consumption on always-on systems
3. **Faster Boot:** Services start quickly when accessed vs. waiting for full system startup
4. **Scalability:** Handle more services than would fit in memory simultaneously
5. **Cost Effective:** Lower resource requirements mean smaller/fewer servers needed
6. **Environmental:** Reduce energy consumption and carbon footprint
## How It Works
```
User Request → Traefik → Sablier Check → Container Start → Health Check → Forward Traffic
Container Stop (after timeout)
```
When a request comes in for a service with Sablier enabled:
1. **Route Detection:** Sablier monitors Traefik routes for configured services
2. **Container Check:** Verifies if the target container is running
3. **Startup Process:** If not running, starts the container via Docker API
4. **Health Verification:** Waits for the service to report healthy
5. **Traffic Forwarding:** Routes traffic to the now-running service
6. **Timeout Monitoring:** Tracks inactivity and stops containers after timeout
## Configuration in AI-Homelab
Sablier is deployed as part of the core infrastructure stack and requires no additional configuration for basic operation. It automatically discovers services with the appropriate labels.
### Service Integration
Add these labels to any service that should use lazy loading:
```yaml
services:
myservice:
# ... other configuration ...
labels:
- "sablier.enable=true"
- "sablier.group=core-myservice" # Optional: group related services
- "traefik.enable=true"
- "traefik.http.routers.myservice.rule=Host(`myservice.${DOMAIN}`)"
# ... other Traefik labels ...
```
### Advanced Configuration
For services requiring custom timeouts or group management:
```yaml
labels:
- "sablier.enable=true"
- "sablier.group=media-services" # Group name for related services
- "sablier.timeout=300" # 5 minutes inactivity timeout (default: 300)
- "sablier.theme=dark" # Optional: theme for Sablier UI (if used)
```
## Official Resources
- **GitHub Repository:** https://github.com/sablierapp/sablier
- **Docker Hub:** https://hub.docker.com/r/sablierapp/sablier
- **Documentation:** https://sablierapp.github.io/sablier/
## Educational Resources
- **Traefik Integration:** https://doc.traefik.io/traefik/middlewares/http/forwardauth/
- **Docker Lazy Loading:** Search for "docker lazy loading" or "container on-demand"
- **Resource Management:** Linux container resource management best practices
## Docker Configuration
### Environment Variables
| Variable | Description | Default | Required |
|----------|-------------|---------|----------|
| `SABLIER_PROVIDER` | Container runtime provider | `docker` | Yes |
| `SABLIER_DOCKER_API_VERSION` | Docker API version | `1.53` | No |
| `SABLIER_DOCKER_NETWORK` | Docker network for containers | `traefik-network` | Yes |
| `SABLIER_LOG_LEVEL` | Logging level (debug, info, warn, error) | `debug` | No |
| `DOCKER_HOST` | Docker socket endpoint | `tcp://docker-proxy:2375` | Yes |
### Ports
- **10000** - Sablier API endpoint (internal use only)
### Volumes
None required - Sablier communicates with Docker via API
### Networks
- **traefik-network** - Required for communication with Traefik
- **homelab-network** - Required for Docker API access
## Using Sablier
### Basic Usage
1. **Enable on Service:** Add `sablier.enable=true` label to any service
2. **Access Service:** Navigate to the service URL in your browser
3. **Automatic Startup:** Sablier detects the request and starts the container
4. **Wait for Ready:** Service starts and health checks pass
5. **Use Service:** Container is now running and accessible
6. **Automatic Shutdown:** Container stops after 5 minutes of inactivity
### Monitoring Lazy Loading
Check which services are managed by Sablier:
```bash
# View all containers with Sablier labels
docker ps --filter "label=sablier.enable=true" --format "table {{.Names}}\t{{.Status}}"
# Check Sablier logs
docker logs sablier
# View Traefik routes that trigger lazy loading
docker logs traefik | grep sablier
```
### Service Groups
Group related services that should start/stop together:
```yaml
# Database and web app in same group
services:
myapp:
labels:
- "sablier.enable=true"
- "sablier.group=myapp-stack"
myapp-db:
labels:
- "sablier.enable=true"
- "sablier.group=myapp-stack"
```
### Custom Timeouts
Set different inactivity timeouts per service:
```yaml
labels:
- "sablier.enable=true"
- "sablier.timeout=600" # 10 minutes
```
## Advanced Topics
### Performance Considerations
- **Startup Time:** Services take longer to respond on first access
- **Resource Spikes:** Multiple services starting simultaneously can cause load
- **Health Checks:** Ensure services have proper health checks for reliable startup
### Troubleshooting Startup Issues
- **Container Won't Start:** Check Docker logs for the failing container
- **Health Check Fails:** Verify service health endpoints are working
- **Network Issues:** Ensure containers are on the correct Docker network
### Integration with Monitoring
Sablier works with existing monitoring:
- **Prometheus:** Can monitor Sablier API metrics
- **Grafana:** Visualize container start/stop events
- **Dozzle:** View logs from lazy-loaded containers
## Troubleshooting
### Service Won't Start Automatically
**Symptoms:** Accessing service URL shows connection error
**Solutions:**
```bash
# Check if Sablier is running
docker ps | grep sablier
# Verify service has correct labels
docker inspect container-name | grep sablier
# Check Sablier logs
docker logs sablier
# Test manual container start
docker start container-name
```
### Containers Not Stopping
**Symptoms:** Containers remain running after inactivity timeout
**Solutions:**
```bash
# Check timeout configuration
docker inspect container-name | grep sablier.timeout
# Verify Sablier has access to Docker API
docker exec sablier curl -f http://docker-proxy:2375/_ping
# Check for active connections
netstat -tlnp | grep :port
```
### Traefik Routing Issues
**Symptoms:** Service accessible but Sablier not triggering
**Solutions:**
```bash
# Verify Traefik labels
docker inspect container-name | grep traefik
# Check Traefik configuration
docker logs traefik | grep "Creating router"
# Test direct access (bypass Sablier)
curl http://container-name:port/health
```
### Common Issues
**Issue:** Services start but are not accessible
**Fix:** Ensure services are on the `traefik-network`
**Issue:** Sablier can't connect to Docker API
**Fix:** Verify `DOCKER_HOST` environment variable and network connectivity
**Issue:** Containers start but health checks fail
**Fix:** Add proper health checks to service configurations
**Issue:** High resource usage during startup
**Fix:** Stagger service startups or increase system resources
### Performance Tuning
- **Increase Timeouts:** For services that need longer inactivity periods
- **Group Services:** Related services can share startup/shutdown cycles
- **Monitor Resources:** Use Glances or Prometheus to track resource usage
- **Optimize Health Checks:** Ensure health checks are fast and reliable
### Getting Help
- **GitHub Issues:** https://github.com/sablierapp/sablier/issues
- **Community:** Check Traefik and Docker forums for lazy loading discussions
- **Logs:** Enable debug logging with `SABLIER_LOG_LEVEL=debug`
- "sablier.start-on-demand=true" # Enable lazy loading
```
### Traefik Middleware
Configure Sablier middleware in Traefik dynamic configuration:
```yaml
http:
middlewares:
sablier-service:
plugin:
sablier:
sablierUrl: http://sablier-service:10000
group: core-service-name
sessionDuration: 2m # How long to keep service running after access
ignoreUserAgent: curl # Don't start service for curl requests
dynamic:
displayName: Service Name
theme: ghost
show-details-by-default: true
```
## Examples
### Basic Service with Lazy Loading
```yaml
services:
my-service:
image: my-service:latest
container_name: my-service
restart: "no" # Important: Must be "no" for Sablier to control start/stop
networks:
- traefik-network
labels:
- "traefik.enable=true"
- "traefik.http.routers.my-service.rule=Host(`my-service.${DOMAIN}`)"
- "traefik.http.routers.my-service.entrypoints=websecure"
- "traefik.http.routers.my-service.tls.certresolver=letsencrypt"
- "traefik.http.routers.my-service.middlewares=authelia@docker"
- "traefik.http.services.my-service.loadbalancer.server.port=8080"
# Sablier lazy loading
- "sablier.enable=true"
- "sablier.group=core-my-service"
- "sablier.start-on-demand=true"
```
### Remote Service Proxy
For services on remote servers, configure Traefik routes with Sablier middleware:
```yaml
# In /opt/stacks/core/traefik/dynamic/remote-services.yml
http:
routers:
remote-service:
rule: "Host(`remote-service.${DOMAIN}`)"
entryPoints:
- websecure
service: remote-service
tls:
certResolver: letsencrypt
middlewares:
- sablier-remote-service@file
services:
remote-service:
loadBalancer:
servers:
- url: "http://remote-server-ip:port"
middlewares:
sablier-remote-service:
plugin:
sablier:
sablierUrl: http://sablier-service:10000
group: remote-server-group
sessionDuration: 5m
displayName: Remote Service
```
## Troubleshooting
### Service Won't Start
**Check Sablier logs:**
```bash
cd /opt/stacks/core
docker compose logs sablier-service
```
**Verify container permissions:**
```bash
# Check if Sablier can access Docker API
docker exec sablier-service curl -f http://localhost:10000/health
```
### Services Not Starting on Demand
**Check Traefik middleware configuration:**
```bash
# Verify middleware is loaded
docker logs traefik | grep sablier
```
**Check service labels:**
```bash
# Verify Sablier labels are present
docker inspect service-name | grep sablier
```
### Services Stop Too Quickly
**Increase session duration:**
```yaml
middlewares:
sablier-service:
plugin:
sablier:
sessionDuration: 10m # Increase from default
```
### Performance Issues
**Check resource usage:**
```bash
docker stats sablier-service
```
**Monitor Docker API calls:**
```bash
docker logs sablier-service | grep "API call"
```
## Best Practices
### Resource Management
- Use lazy loading for services that aren't accessed frequently
- Set appropriate session durations based on usage patterns
- Monitor resource usage to ensure adequate system capacity
### Configuration
- **Always set `restart: "no"`** for Sablier-managed services to allow full lifecycle control
- Group related services together for coordinated startup
- Use descriptive display names for the loading page
- Configure appropriate timeouts for your use case
### Security
- Sablier runs with Docker API access - ensure proper network isolation
- Use Docker socket proxy for additional security
- Monitor Sablier logs for unauthorized access attempts
## Integration with Other Services
### Homepage Dashboard
Add Sablier status to Homepage:
```yaml
# In homepage config
- Core Infrastructure:
- Sablier:
icon: docker.png
href: http://sablier-service:10000
description: Lazy loading service
widget:
type: iframe
url: http://sablier-service:10000
```
### Monitoring
Monitor Sablier with Prometheus metrics (if available) or basic health checks:
```yaml
# Health check
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:10000/health"]
interval: 30s
timeout: 10s
retries: 3
```
## Advanced Configuration
### Custom Themes
Sablier supports different loading page themes:
```yaml
dynamic:
displayName: My Service
theme: ghost # Options: ghost, hacker, ocean, etc.
show-details-by-default: true
```
### Group Management
Services can be grouped for coordinated startup:
```yaml
# All services in the same group start together
labels:
- "sablier.group=media-stack"
- "sablier.enable=true"
- "sablier.start-on-demand=true"
```
### API Access
Sablier provides a REST API for programmatic control:
```bash
# Get service status
curl http://sablier-service:10000/api/groups
# Start a service group
curl -X POST http://sablier-service:10000/api/groups/media-stack/start
# Stop a service group
curl -X POST http://sablier-service:10000/api/groups/media-stack/stop
```
## Migration from Manual Management
When adding Sablier to existing services:
1. **Change restart policy** to `"no"` in the compose file (critical for Sablier control)
2. **Add Sablier labels** to the service compose file
3. **Configure Traefik middleware** for the service
4. **Stop the service** initially (let Sablier manage it)
5. **Test access** - service should start automatically
6. **Monitor logs** to ensure proper operation
> **Important**: Services managed by Sablier must have `restart: "no"` to allow Sablier full control over container lifecycle. Do not use `unless-stopped`, `always`, or `on-failure` restart policies.
## Related Documentation
- [Traefik Documentation](traefik.md) - Reverse proxy configuration
- [Authelia Documentation](authelia.md) - SSO authentication
- [On-Demand Remote Services](../Ondemand-Remote-Services.md) - Remote service setup guide

View File

@@ -502,3 +502,16 @@ Traefik is the heart of your homelab's networking infrastructure. It:
- Scales from simple to complex setups
Understanding Traefik is crucial for managing your homelab effectively. Take time to explore the dashboard and understand how routing works - it will make troubleshooting and adding new services much easier.
## Related Services
- **[Authelia](authelia.md)** - SSO authentication that integrates with Traefik
- **[Sablier](sablier.md)** - Lazy loading that works with Traefik routing
- **[DuckDNS](duckdns.md)** - Dynamic DNS for SSL certificate validation
- **[Gluetun](gluetun.md)** - VPN routing that can work alongside Traefik
## See Also
- **[Traefik Labels Guide](../docker-guidelines.md#traefik-label-patterns)** - How to configure services for Traefik
- **[SSL Certificate Setup](../getting-started.md#notes-about-ssl-certificates-from-letsencrypt-with-duckdns)** - How SSL certificates work with Traefik
- **[External Host Proxying](../proxying-external-hosts.md)** - Route non-Docker services through Traefik

View File

@@ -209,7 +209,7 @@ tar -czf vaultwarden-backup-$(date +%Y%m%d).tar.gz \
# Start container
docker start vaultwarden
# Or use Backrest/Duplicati for automatic backups
# Or use Backrest (default) for automatic backups
```
## Summary