Self-hosting evaluation backlog (from selfh.st/apps) #326
Labels
No labels
burndown-2026-06
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
coilyco-flight-deck/infrastructure#326
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Self-hosting evaluation backlog sourced from selfh.st/apps, filtered against the platform-engineer / kai-server stack. Each line is a candidate to evaluate and either deploy on kai-server or reject with a reason. Star counts are a popularity signal at time of filing (2026-06-14).
Secrets / Identity
Monitoring / Dashboard
Fleet / Deployment
--check --diffdrift runs. Backend (on Postgres) for the NocoDB drift-grid pipeline - see comment. Read/reporting layer, distinct from Semaphore's execute layer.Automation / Internal tooling
AI / LLM
Notes
Categories to pick a tool within (research + choose, then split into its own task)
Source: selfh.st/apps CDN catalog (1,297 apps), filtered 2026-06-14. Generated via Claude Code.
Decisions (2026-06-15)
Site analytics → Umami. Picked over Plausible (Plausible needs both Postgres and ClickHouse; Umami is single-Postgres) and the heavier PostHog/Matomo. Deployment is now tracked under the shared-Postgres work, since Umami is the cluster's second Postgres-needing app:
Error tracking → stay on Sentry cloud; drop the self-host-Sentry idea. Self-hosting real Sentry is a ~40-container, 16GB+ stack - not worth it on a homelab k3s node. Kai already uses Sentry SaaS and likes it, so the least-ops answer is to keep it. GlitchTip (Sentry-SDK-compatible, ~1-2GB) remains a fallback only if data-local self-hosting ever becomes a goal; the existing
docs/glitchtip-deploy-plan.mdis parked, not active.ARA → Postgres → NocoDB drift-grid pipeline
Concrete path for using ARA as the ansible run recorder and NocoDB as an Airtable-ish grid over it, for tracking the backfill/grandfather/rollout matrix. The trick is NocoDB's "connect to an existing database as an external source" feature, which lets us skip ETL entirely:
--check --diffdrift runs.(task, host)- latestchanged/okper backfill per host. That view is the drift matrix.No copy, no sync job, no cron shuffling records - NocoDB reads ARA's live tables and the matrix collapse is just SQL. The glue tools elsewhere on this issue (n8n/Windmill) are only needed if we want to push back (e.g. open/close Forgejo issues from the grid), not for the read view.
Notes / decisions this implies
infrastructure/ansible; an ansible role does the kai-server rollout of ARA/NocoDB.Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag:
burndown-2026-06.