OpenCode session archiválás frontenddel

Self-hosted session archive hero banner
Session archive hero

Ha nap mint nap AI-kódoló asszisztensekkel dolgozol, ismered a problémát: a beszélgetési napló — minden munkamenet, minden prompt, minden eszközhívás — csendben több gigabájtos adatbázissá növekszik. A keresés lassúvá válik, a biztonsági mentések örökké tartanak, és amire valójában emlékezni akarsz (az a javítás egy trükkös hibához, az a refaktor-minta, az az egy parancs) ezer másik sor alá temetődik.

Ez a cikk egy olyan példát mutat be, amelyet élesben is használunk: egy önüzemeltetett archívumrendszert, amely az opencode régi munkameneteket kimásolja az élő adatbázisból egy külön, kompakt, teljes szövegű kereshető archívumba — majd egy gyors webes felületen teszi elérhetővé, amit az egész csapat kereshet, egyszeri bejelentkezéssel (SSO) védve.

A legjobb az egészben: az egész unalmas, bevált építőelemekből áll — SQLite, FTS5, egy kis Python-szkript, cron és egy vékony webes réteg. Nincs Elasticsearch-fürt, nincs felügyelt keresőszolgáltatás, nincs szállítói bezártság.

Megmutatom, hogyan építheted meg.

„OpenCode session archiválás frontenddel” olvasásának folytatása

Hogyan építettünk egy AI használati reportot OpenCode platformunkhoz

Építettünk egy egyedi HTML reportot generáló scriptet, amely összegyűjti az AI használati statisztikákat az OpenCode-ból (munkamenetek, tokenek, költségek, MCP eszközhívások), és naponta e-mailben kézbesíti. Az adatok két forrásból származnak — egy REST API-ból a munkamenet-szintű mérőszámokhoz és közvetlen SQLite hozzáférésből az MCP eszközhívás telemetriához.

„Hogyan építettünk egy AI használati reportot OpenCode platformunkhoz” olvasásának folytatása

Self-Hosted Google Maps egy Raspberry Pi-n

Útvonaltervezés GraphHopper segítségével Budapest Széchenyi lánchídtól Debrecen Piac utcáig (231,5 km)

Mindig is lenyűgözött az a gondolat, hogy a saját négy falunk között is fusson egy olyan térkép szolgáltatás, ami nem függ az internetkapcsolattól. Egy olyan „Google Maps”, ami a saját gépemen fut, a saját adataimat használja, és akkor is működik, ha épp nincs net. Az inspiration a N.O.M.A.D. (Network of Offline Mapping and Discovery) projektből jött, akik egy teljes offline szolgáltatás stack-et álmodtak meg. Az ő nyomdokaikon haladva építettem meg a saját verziómat, ami egy Raspberry Pi-n fut, Docker konténerekben, és teljes Magyarországot lefedi.

„Self-Hosted Google Maps egy Raspberry Pi-n” olvasásának folytatása

IPv6 szolgáltatások biztosítása belső routolt IPv6 nélkül

Sok helyen az a cél, hogy a szolgáltatások IPv6-on is elérhetők legyenek, miközben a belső infrastruktúra és a meglévő IPv4-alapú működés minimálisan változzon. Az erre kínált tipikus megoldások egy külső IPv6 prefixet delegálnak a belső hálózat felé, így a korábban NAT mögött lévő és közvetlenül nem elérhető eszközök globálisan routolható IPv6 címet kapnak. Ekkor a védelem elsődlegesen a megfelelően kialakított tűzfalszabályokra hárul, ami hibás konfiguráció esetén jelentős biztonsági kockázatot jelenthet.

Ebben a cikkben egy olyan UniFi UDM-SE alapú megoldást mutatok be, amely lehetővé teszi az IPv6-os szolgáltatáselérést anélkül, hogy a belső hálózat bármely eszköze közvetlenül elérhetővé válna az internet felől. A megoldás ULA-alapú belső IPv6 címezést használ, így a belső rendszerek továbbra is elszigeteltek maradnak, miközben a kívánt szolgáltatások IPv6-on is publikálhatók.

„IPv6 szolgáltatások biztosítása belső routolt IPv6 nélkül” olvasásának folytatása