Obsidian er kjempegod til én ting: å holde styr på tusen enkeltobjekter uten at det blir kaos. Songcards, prompts, notater, arkivstatus — alt som egne filer i en mappe du selv eier. Ingen database, ingen server. Ingen abonnement som forsvinner hvis selskapet bak går konkurs. Bare markdown på disk.

Det er derfor det er et bibliotek. Ikke fordi det har grafvisning eller ser fint ut — men fordi biblioteker er gode på nøyaktig én ting: ett objekt, én hylleplass, søkbart og lenkbart. Obsidian gjør den jobben bedre enn nesten alt annet.

Der Obsidian faktisk leverer

Vi bruker en obsidian katalog. Hver låt er en songcard. Èn fil, én kilde til sannhet, med status og metadata på plass. Legger jeg inn et songcard, vet jeg akkurat hvor det ligger og hva det inneholder, uten å lete gjennom regneark eller spørre en database. Samme med et prompt-bibliotek: “hver prompt er sitt eget objekt, med egen seksjon for variant, bruksområde og hvilken modell den er skrevet for”. Det er akkurat jobben Obsidian ble bygget for.

Der det butter

Den samme begrensningen som gjør Obsidian god på lagring, er nøyaktig den som gjør det elendig på arbeidsflyt. Ett objekt = én fil betyr at Obsidian ikke vet noe om rekkefølge, tilstand eller overgang mellom filer. Det finnes ingen innebygd “denne filen trigger den handlingen”, ingen kø, ingen orkestrering.

Du kan late som med Dataview-spørringer og dashboards, men da presser du en hammer til å bli en skiftenøkkel. Det er akkurat sånn det gikk med en gammel markedsføringsvault. Dashboards i markdown skulle styre statusflyt på tvers av prosjekter, det holdt en stund, og så kollapset strukturen og måtte ryddes helt bort.

Lærdommen: bruk Obsidian til det den er god på, og gi resten til et verktøy som faktisk forstår sekvens og tilstand. Pipelinen vi bruker er selve beviset. Songcards ligger i Obsidian som kilden til sannhet. Men, i det øyeblikket data skal bevege seg, gjennom import-songs.mjs, videre til Astro-build og ut via WinSCP, er Obsidian ute av bildet. Obsidian lagrer objektet. - Scriptet flytter det. To forskjellige jobber, - to forskjellige verktøy.

Gratis alternativer når AI skal inn i løkka

Trenger du ekte pipeline-styring — spesielt med AI-kall i flyten — ikke tving Obsidian til det. Tre selvhostede, gratis alternativer verdt å faktisk sette opp:

n8n — Community Edition er gratis å selvhoste, ingen lisenskostnad, ubegrenset kjøringer.

Fair-code-lisens, ikke en ren OSI-godkjent open source-lisens, men for en enkeltdriver er det irrelevant: du betaler ikke for softwaren, bare for serveren den kjører på. God til å kjede AI-kall, webhooks og API-integrasjoner uten å skrive alt fra bunnen.

Windmill — Ren open source (AGPL), gratis selvhostet, ubegrenset kjøringer, opptil 50 brukere selv på gratistieret.

Kodefokusert (Python/TypeScript/Bash), så hvis du uansett skriver scripts som song-normalizer.mjs, er dette et naturlig sted å legge selve orkestreringen, uten å bygge egen kø- og retry-logikk fra scratch.

Node-RED — Enklere, visuelt, node-basert.

Helt gratis og open source (OpenJS Foundation), lett å selvhoste på samme VPS du allerede har Listmonk på. Overkill for tunge AI-pipelines, men solid for enkle triggere: “når denne filen dukker opp, kjør det scriptet, post resultatet et sted.”

Ingen av disse krever at du forlater filosofien din. Alle tre kjører selvhostet, lokalt, uten SaaS-avhengighet. Bruk Obsidian til å eie objektene. Bruk ett av disse til å flytte dem.

  • HugByte