1/ launching https://t.co/320ApbJWvA today.
one VPS. one Go binary. one SQLite file. continuous backup to R2. caddy for HTTPS. systemd to keep it alive. a shell script to deploy.
this is the whole stack. the rest is what each piece is doing and what it replaces.
๐งต
@MarvellousDev That green badge is only a write result. A restore drill should start on a fresh host and prove the app, credentials, and data come back.
`ProtectSystem=strict` makes the appโs filesystem read-only. Add one deliberate hole with `ReadWritePaths=/home/deploy/app/data`; SQLite and uploads can write there, nothing else can.
@BasedMustelid SpatiaLite is fine if the write pattern stays SQLite-shaped. Iโd load-test the spatial queries, run WAL, set `busy_timeout`, and prove backup/restore on a fresh host before calling it production.
@MykoalaAI@awscloud Those $2k credits hide the unit economics. Track each service at list price now, or the first real invoice becomes the architecture review.
@ErSonusaini1 The software line item stops scaling with seats; the ops work doesn't. Count restores, upgrades, and incident time before calling the cost flat.
@lnxsec Before deleting the unit, save `systemctl cat <name>`, `systemctl show <name>`, and `journalctl -u <name>`. The unit file is evidence; preserve it before cleanup.
@iAjittiwari Make the healthcheck hit a workflow-owned sentinel, not just /healthz: create a tiny scheduled workflow that writes a timestamp, then alert when it is older than 2ร the schedule. That catches a responsive n8n process with a dead executor.
@studio_hungry A nightly SQLite rebuild is perfect for this if readers open the DB read-only and you swap the completed file into place atomically. It avoids locking a live index while the docs crawler is halfway through a refresh.
@fromcodetocloud For a $5 VPS, node_exporter + Grafana is plenty. Alert on failed restore drills too; green backup jobs can still hide unusable backups.
@mriganka_94 WAL removes reader/writer blocking, not SQLite's single-writer limit. 100K writes/sec is possible with batched transactions; one fsync per row changes that by orders of magnitude.
@dunik_7 The install is three commands; the backup and restore path is the part worth proving before production. A $6 VPS is the entire bill only if Postgres, storage metadata, and secrets can be restored onto a clean box.
@mike_pendon Yes - an opt-in SQLite extension that sets journal_mode=WAL, applies a sensible busy_timeout, and exposes both as config would be valuable. Bonus if it reports the active values on startup so production can not silently fall back.
@TheKidBuilds For the SQLite path, run an integrity check after import and before swapping the live DB. A backup that was never restored is still untested.
Mocks for unit tests; real Postgres for anything touching SQL semantics. Swapping in SQLite hides the exact JSONB and locking behavior the integration test should catch. Mocks for unit tests; real Postgres for anything touching SQL semantics. Swapping in SQLite hides the exact JSONB and locking behavior the integration test should catch.
@botmonster SQLite-in-tests is fine when production is SQLite. If prod is Postgres, it is not a test optimization; it is testing a different locking and type system.
@MaybeEdward The install matters less than the update path. For agency clients, atomic releases plus rollbackable DB migrations beat a self-hosted stack that still needs vendor SSH.