Boring Stack

Build web apps the boring way.

[Boring Stack @boringstack]

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.

🧵

[Boring Stack @boringstack]

`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.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@ibocodes SQLite usually fails on write topology, not user count. If you only need one writer, WAL plus a tested restore path buys a lot of runway.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@RealShresth_ Combine both with `journalctl -u app.service -f`; add a `--since` window when a restart buries the useful lines.

[Boring Stack @boringstack]

@MykoalaAI @awscloud Credits buy runway, not a cost model. Price the same stack at month 13 before you lock it in.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@fromcodetocloud For a $5 VPS, node_exporter + Grafana is plenty. Alert on failed restore drills too; green backup jobs can still hide unusable backups.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@colinbreeding Show ‘last checked’ and the raw vendor incident URL on every tile. A green tile from a stale poll is worse than a red one.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

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.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@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.

[Boring Stack @boringstack]

@MaybeEdward The installer is where self-hosted SaaS succeeds or dies: one command, explicit backup/restore, and an upgrade path with rollback. If Laravel Cloud owns those three, self-hosted stops feeling like a support tax.