mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-28 04:38:59 +00:00
32a7d53b2b
* feat: add RBAC viewer accounts, atomic deployments, and fleet-wide backups (Pro) Introduces three Pro-tier features: - RBAC: Multi-user system with admin/viewer roles, user management UI, automatic migration from single-admin credentials, viewer restrictions across the entire UI (read-only editor, hidden action buttons) - Atomic Deployments: Pre-deploy file backup to .sencho-backup/, automatic rollback on health probe failure, manual rollback button, health probes added to stack updates, webhook-triggered deploys use atomic rollback - Fleet-Wide Backups: Point-in-time snapshots of compose files across all nodes (local + remote), stored centrally in SQLite, per-stack restore with optional redeploy, graceful handling of offline nodes * fix(settings): use correct ProGate prop name in UsersSection * fix(settings): remove unused isPro prop from UsersSection * fix(auth): fetch user info after login and setup so isAdmin is set correctly * feat(pricing): revise pricing strategy and enforce variant-based seat limits Raise Personal Pro from $49/yr to $69/yr with 3 viewer seats (up from 1). Add $15/mo billing option for Team Pro. Mark lifetime pricing as a 90-day early-adopter offer. Store Lemon Squeezy variant_name on activation/validation and enforce seat limits server-side per variant. * feat(licensing): add Lemon Squeezy checkout, webhook, and billing portal integration Server-side checkout URL generation (POST /api/checkout) with admin email pre-fill and instance_id custom data. HMAC-SHA256 verified webhook endpoint (POST /api/webhooks/lemonsqueezy) handling order, subscription, and payment lifecycle events for automatic license activation. Customer billing portal link stored from webhook events and exposed via GET /api/billing/portal. In-app checkout buttons in Settings with manual license key fallback. * fix(licensing): exempt Lemon Squeezy webhook from auth middleware The catch-all auth middleware on /api/* was blocking the public webhook endpoint. Added /webhooks/lemonsqueezy to the exemption list alongside /auth/* and /webhooks/:id/trigger. * feat(pricing): update pricing to final live rates Personal Pro: $7.99/month, $69.99/year, $249 lifetime. Team Pro: $49.99/month, $499.99/year, $1,499 lifetime. Added personal_monthly checkout variant across backend, frontend, and website. * refactor(licensing): remove server-side checkout/webhook for self-hosted model Sencho is self-hosted — each user runs their own instance, so there is no central server to receive webhooks or hold the store API key. Replaced in-app checkout buttons with a "View Pricing" redirect to sencho.io and kept manual license key activation as the primary flow. - Delete LemonSqueezyService (checkout, webhook, HMAC verification) - Remove POST /api/checkout, GET /api/billing/portal, POST /api/webhooks/lemonsqueezy - Remove raw body parser and auth exemption for webhook route - Remove all LEMONSQUEEZY_* env vars from .env.example - Replace checkout buttons in SettingsModal with single "View Pricing" button - Simplify LicenseContext checkout to open sencho.io pricing page - Update licensing docs to reflect website-based purchase flow * chore: normalize em-dashes to hyphens across codebase (linter) * chore: remove accidentally tracked directories from index
128 lines
4.0 KiB
Plaintext
128 lines
4.0 KiB
Plaintext
---
|
|
title: Webhooks
|
|
description: Trigger stack actions from CI/CD pipelines via HTTP webhooks with HMAC signature authentication.
|
|
---
|
|
|
|
<Note>
|
|
Webhooks require a Sencho Pro license.
|
|
</Note>
|
|
|
|
Sencho webhooks let external systems trigger stack actions over HTTP. The typical use case: your CI pipeline builds a new image, then calls a Sencho webhook to deploy the updated stack - no manual intervention required.
|
|
|
|
## How it works
|
|
|
|
1. You create a webhook in **Settings → Webhooks**, targeting a specific stack and action
|
|
2. Sencho generates a unique secret for HMAC-SHA256 signature validation
|
|
3. Your CI/CD system sends a `POST` request to the trigger URL with the correct signature
|
|
4. Sencho validates the signature and executes the action asynchronously
|
|
|
|
## Creating a webhook
|
|
|
|
Open **Settings → Webhooks** and click **Create Webhook**. Fill in:
|
|
|
|
| Field | Description |
|
|
|-------|-------------|
|
|
| **Name** | A display name (e.g. "Deploy on push") |
|
|
| **Stack** | The target stack to act on |
|
|
| **Action** | One of: `deploy`, `restart`, `stop`, `start`, `pull` |
|
|
|
|
After creation, Sencho shows the webhook secret **once**. Copy it immediately - it cannot be retrieved later.
|
|
|
|
### Actions explained
|
|
|
|
| Action | What it does |
|
|
|--------|-------------|
|
|
| **Deploy** | Runs `docker compose down` then `docker compose up -d` (full redeploy) |
|
|
| **Restart** | Runs `docker compose restart` |
|
|
| **Stop** | Runs `docker compose stop` |
|
|
| **Start** | Runs `docker compose start` |
|
|
| **Pull** | Pulls latest images and recreates changed containers |
|
|
|
|
## Triggering a webhook
|
|
|
|
Send a POST request to the trigger URL with an HMAC-SHA256 signature:
|
|
|
|
```
|
|
POST /api/webhooks/{id}/trigger
|
|
Content-Type: application/json
|
|
X-Webhook-Signature: sha256={hmac}
|
|
```
|
|
|
|
The signature is computed as `HMAC-SHA256(request_body, webhook_secret)` and sent in the `X-Webhook-Signature` header with a `sha256=` prefix.
|
|
|
|
### Example with curl
|
|
|
|
```bash
|
|
SECRET="your-webhook-secret"
|
|
BODY='{}'
|
|
SIGNATURE=$(echo -n "$BODY" | openssl dgst -sha256 -hmac "$SECRET" | cut -d' ' -f2)
|
|
|
|
curl -X POST https://your-sencho.com/api/webhooks/3/trigger \
|
|
-H "Content-Type: application/json" \
|
|
-H "X-Webhook-Signature: sha256=$SIGNATURE" \
|
|
-d "$BODY"
|
|
```
|
|
|
|
### Overriding the action
|
|
|
|
By default, the webhook executes the action configured at creation time. You can override it per-request by including an `action` field in the body:
|
|
|
|
```json
|
|
{ "action": "restart" }
|
|
```
|
|
|
|
### Response
|
|
|
|
A successful trigger returns `202 Accepted` immediately. The action executes asynchronously in the background.
|
|
|
|
```json
|
|
{ "message": "Webhook accepted", "action": "deploy" }
|
|
```
|
|
|
|
## CI/CD integration examples
|
|
|
|
### GitHub Actions
|
|
|
|
```yaml
|
|
- name: Deploy via Sencho
|
|
run: |
|
|
BODY='{}'
|
|
SIGNATURE=$(echo -n "$BODY" | openssl dgst -sha256 -hmac "${{ secrets.SENCHO_WEBHOOK_SECRET }}" | cut -d' ' -f2)
|
|
curl -X POST "${{ secrets.SENCHO_URL }}/api/webhooks/${{ secrets.SENCHO_WEBHOOK_ID }}/trigger" \
|
|
-H "Content-Type: application/json" \
|
|
-H "X-Webhook-Signature: sha256=$SIGNATURE" \
|
|
-d "$BODY"
|
|
```
|
|
|
|
### GitLab CI
|
|
|
|
```yaml
|
|
deploy:
|
|
stage: deploy
|
|
script:
|
|
- BODY='{}'
|
|
- SIGNATURE=$(echo -n "$BODY" | openssl dgst -sha256 -hmac "$SENCHO_WEBHOOK_SECRET" | cut -d' ' -f2)
|
|
- 'curl -X POST "$SENCHO_URL/api/webhooks/$SENCHO_WEBHOOK_ID/trigger"
|
|
-H "Content-Type: application/json"
|
|
-H "X-Webhook-Signature: sha256=$SIGNATURE"
|
|
-d "$BODY"'
|
|
```
|
|
|
|
## Execution history
|
|
|
|
Each webhook tracks its last 100 executions. Click **Recent executions** on any webhook row to see:
|
|
|
|
- Status (success/failure)
|
|
- Action performed
|
|
- Execution time
|
|
- Duration
|
|
- Error message (if failed)
|
|
|
|
## Security
|
|
|
|
- Webhook secrets are 64-character hex strings generated with `crypto.randomBytes(32)`
|
|
- Signature validation uses `crypto.timingSafeEqual` to prevent timing attacks
|
|
- Secrets are shown only once at creation - API responses return masked values
|
|
- Webhook trigger endpoints are public (no session cookie required) but protected by HMAC signature validation
|
|
- Each webhook targets a single stack - there is no way to execute arbitrary commands
|