Changeset 2dd1dc4 in Klonkt for deploy

Timestamp:

07/31/2026 12:48:10 PM (6 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

ccaa530

Parents:

e2c3d09

Message:

Scheid gebruikersdata van code voor self-hosters

Een instance bewaarde zijn database, uploads en .env binnen de checkout. Daardoor
bevatte de codemap levende gebruikersdata: opruimen bij een deploy kon uploads
raken, een back-up moest de data tussen de code vandaan vissen, en een tweede
site vroeg een tweede kopie van alles, inclusief node_modules, die apart
bijgewerkt moest worden.

Nu staat de code in /opt/klonkt en de data per instance in /var/lib/klonkt/<slug>.
De checkout is daarmee wegwerpbaar: weggooien en opnieuw klonen laat elke
instance intact. Een site toevoegen is een map plus een .env, zonder tweede
kopie van de code, en klonkt-update brengt ze in een keer allemaal naar de
nieuwe versie.

De systemd-template draait als de klonkt-gebruiker met ProtectSystem=strict en
ReadWritePaths op alleen de eigen datamap. Een instance kan dus niet in de code
schrijven en niet bij de data van een andere instance, ook niet als er in de app
iets misgaat.

Changed files:
scripts/install.sh

• KLONKT_DATA_ROOT en KLONKT_SLUG toegevoegd, slug afgeleid van het domein
• verse installatie zet data in /var/lib/klonkt/<slug> en start klonkt@<slug>
• bestaande installaties met een .env in de checkout blijven ongemoeid, opnieuw draaien mag nooit een levende database verplaatsen
• weigert bij een database in de checkout zonder .env, te dubbelzinnig
• klonkt-update herstart voortaan elke instance, niet alleen klonkt.service

deploy/DEPLOY.md

• sectie 9b: meerdere zelfstandige Klonkts naast elkaar, met verwijzing
• onderscheid verduidelijkt met de bestaande multi-tenant sectie, die gaat over sites binnen een instance

New file:
deploy/klonkt@.service

• systemd template-unit, een service per instance, gedeelde code

scripts/klonkt-migrate-data.sh

• zet een bestaande installatie om, met --dry-run en een rollback-pad
• weigert op code zonder src/config/paths.js, anders schrijft de app alsnog naast zijn eigen code

scripts/klonkt-add-instance.sh

• nieuwe instance: datamap, .env met verse SESSION_SECRET en vrije poort, service en Caddy-blok

deploy/MULTI-INSTANCE.md

• indeling, eigenaarschap en rechten, migratie, instances toevoegen, updaten, back-up en verwijderen

Nog te doen: dit is getest op de fleet en met een lokale rooktest, maar de
verse-installatiestap zelf is nog niet op een schone VPS gedraaid.

-robo
Co-Authored-By: Claude Opus 5 <noreply@…>

Location:

deploy

Files:

• DEPLOY.md (modified) (1 diff)
• MULTI-INSTANCE.md (added)
• klonkt@.service (added)

deploy/DEPLOY.md

@@ -198 +198 @@
 (`/sites/<slug>/`) and its own PWA scope, so installing the PWA from one
 site won't navigate into another.
+
+These sites live inside one Klonkt, sharing one database and one process. For
+separate domains with separate databases, see the next section instead.
+
+---
+
+## 9b. Several independent Klonkts on one server
+
+A different question from the one above: not several sites inside one Klonkt,
+but several Klonkts side by side, each with its own domain, database and
+uploads, all sharing a single copy of the code.
+
+That layout keeps user data out of the checkout:
+
+```
+/opt/klonkt/                 the code, shared by every instance
+/var/lib/klonkt/<slug>/      one instance: .env, database, uploads
+```
+
+Adding a site is then a directory plus an `.env`, and `klonkt-update` moves all
+of them to the new code in one step. Existing single site installs can be
+converted with `scripts/klonkt-migrate-data.sh`.
+
+See **[MULTI-INSTANCE.md](MULTI-INSTANCE.md)** for the layout, the migration,
+the file ownership and the backup routine.
 
 ---