Driv hele molevitten selv på én maskine.

Installationen er ikke den svære del og har ikke været det i årevis. Klon repoet, kopiér eksempel-env-filen, kør én kommando, og tre containere kommer op på én vært. Det svære er de fjorten dage bagefter: de pladsholderhemmeligheder, du aldrig udskiftede, mailafsenderen der stadig er en stub, Postgres-rollen der afgør, om row-level security overhovedet gør noget. Det her er gennemgangen, der dækker dem, i den rækkefølge maskinen fremtvinger.

Kan du selv drive et CRM og en helpdesk på én maskine?

Ja. Munin drives selv som tre containere — Postgres med pgvector, en backend på port 3001, et dashboard på port 3000 — startet af ét enkelt docker compose up mod det MIT-licenserede repo. Der er intet pladsantal, intet kontaktloft og ingen funktionsspærre. Det selvdrevne build er den samme kode, der kører Munin Cloud, sammensat med enorganisationsautentificering i stedet for multi-tenant.

Det sidste punkt er værd at dvæle ved, fordi det er usædvanligt i denne kategori. Der er ingen enterprise/- eller ee/-mappe i repoet, der holder de dele tilbage, du faktisk vil have. MIT dækker det hele — videnbase, samtaler, CRM, CMS, udgående kontakt, analyse, kuratorkøen, revisionsloggen, webhooks og hele MCP-værktøjskataloget.

git clone https://github.com/getmunin/munin.git
cd munin
cp .env.example .env
docker compose up

Hvad er det bedste selvdrevne CRM og den bedste helpdesk i 2026?

Der er ingen enkelt vinder, og den ærlige måde at dele feltet på er efter, hvor mange bevægelige dele du er villig til at eje. FreeScout og EspoCRM er de letteste — begge kører på helt almindelig PHP-hosting. Twenty er det pæneste selvdrevne CRM. SuiteCRM er det mest tilpasselige til salgsprocesser i store virksomheder. Chatwoot har den bredeste kanaldækning. Zammad er det dybeste sagssystem. ERPNext er det mest komplette gratis ERP. Munin lægger CRM og helpdesk på én post fra én kommando.

Den indramning betyder mere end et funktionsgitter, fordi på din egen server koster den funktion, du aldrig bruger, ingenting, og den tjeneste, du skal holde i live, koster hver uge. Zammad vil have PostgreSQL, Redis, en Rails-app og — stærkt anbefalet, hvis du vil have en god søgning — Elasticsearch, som bringer heap-dimensionering og indekshåndtering med sig. ERPNext kører Gunicorn, en arbejderpulje, Node, MariaDB og tre separate Redis-instanser til cache, kø og socketio. SuiteCRM ligger i den anden ende: en Apache- og PHP-applikation med et cron-job og én MySQL eller MariaDB bag sig, hvilket er grunden til, at den stadig dukker op på delt hosting to årtier senere. Alle tre er glimrende software; to af dem beder dig drive infrastruktur svarende til et lille platformsteam.

Den anden akse er licensen, og den sorterer ikke, som mærkerne antyder. Chatwoot er MIT i roden med en enterprise/-mappe under en separat kommerciel licens — SLA-håndtering, revisionslogge og egne dashboards bor i den, og produktionsbrug af den mappe kræver et abonnement. Twenty er AGPL-3.0 med enkeltfiler mærket @license Enterprise. FreeScout er AGPL-3.0 med officielle moduler — Knowledge Base, Workflows, Customer Portal — solgt per licensnøgle. SuiteCRM, Zammad, ERPNext og Dolibarr holder slet intet tilbage. Intet af det er uhæderligt; det hele er normalt. Det betyder bare, at det, du kan drive selv, ikke altid er det, du fik demonstreret.

Tjekket igen mod hvert projekts egen udrulnings- og licensdokumentation den 3. september 2026; SuiteCRM-rækken blev tilføjet den 16. september 2026. Pakning flytter sig; tjek repoet, før du binder dig, også vores.

Hvad starter docker compose up egentlig?

Tre tjenester og to navngivne volumener. Postgres 16 med vektorudvidelsen, backenden og webdashboardet. Ingen Redis, ingen separat køproces, ingen søgeklynge — både kuratorens jobkø og den hybride fuldtekst- og pgvector-søgning bor i den samme Postgres som resten af dataene.

Backend-containeren kører node dist/migrate.js før node dist/main.js, så migrationer anvendes ved hver opstart. Postgres melder sig rask, før backenden får lov at starte.

• PGpgvector/pgvector:pg16 på volumenet munin-pg. Den eneste tilstandsbærende tjeneste i stakken, og den eneste du behøver en sikkerhedskopiplan til.
• APIBackenden på :3001 — MCP over Streamable HTTP, OAuth 2.1 med dynamisk klientregistrering, og REST-kontrolplanet. Ressourcer lander på volumenet munin-data.
• WEBDashboardet på :3000 — login, API-nøgler, gennemgangskøer, forbindelseskort. Ikke der, hvor arbejdet sker. Agenten er der, hvor arbejdet sker.

Hvor meget RAM kræver et selvdrevet CRM?

Mellem 1 GB og 8 GB, helt afhængigt af hvor mange tjenester projektet tvinger dig til at køre. FreeScout kører på den billigste VPS, en udbyder sælger. EspoCRM har det behageligt på 1 GB. Munin vil have omkring 2 GB til Postgres plus to Node-processer. Twenty beder om mindst 2 GB. Zammad anbefaler mindst 4 GB til containerne, mere hvis Elasticsearch deler kassen. ERPNext starter ved 4 GB for en lille produktionsinstans og 8 GB ved 25 til 50 brugere.

Fejltilstanden er altid den samme, og den er værd at nævne: for lidt hukommelse giver ikke en fejl, det giver swap. En side, der tog 200 ms, tager fire sekunder, baggrundsjob går stille i stå, og du bruger en lørdag overbevist om, at applikationen er i stykker. Køb den næste VPS-størrelse op. Det er den billigste beslutning på denne side.

Disk er den nemmere halvdel — databasen, uploadede ressourcer, og plads til at holde en dump, mens du gendanner den. Tyve gigabyte er et fornuftigt udgangspunkt for enhver af disse, og Postgres siger til i god tid, før det betyder noget.

Hvilke hemmeligheder skal jeg sætte, før andre kan nå den?

Fire: MUNIN_AUTH_SECRET, MUNIN_KEY_PEPPER, MUNIN_ENCRYPTION_KEY og MUNIN_STORAGE_LOCAL_SECRET. Efterladt på deres replace-me-*-pladsholdere genererer docker compose up stærke værdier ved første opstart og gemmer dem i volumenet munin-data. Det er fint på en laptop. Til noget, der deles, sæt dem selv, så de overlever et volumen, du beslutter dig for at smide væk.

To mere styrer, hvem der overhovedet kommer ind. MUNIN_ALLOWED_EMAIL_DOMAINS er tom som standard, hvilket betyder kun-invitation: den første, der tilmelder sig, bliver administrator for den ene organisation, og alle efter det skal bruge en invitationstoken. MUNIN_AUTH_TRUSTED_ORIGINS er som standard localhost:3000 (og 127.0.0.1:3000) og skal sættes til din rigtige dashboard-URL i produktion, ellers fejler login på CSRF-tjekket.

# Én linje hver, ved installation.
openssl rand -base64 48   # MUNIN_AUTH_SECRET
openssl rand -base64 48   # MUNIN_KEY_PEPPER
openssl rand -base64 48   # MUNIN_ENCRYPTION_KEY
openssl rand -base64 48   # MUNIN_STORAGE_LOCAL_SECRET

# Hvem der kan nå den
MUNIN_ALLOWED_EMAIL_DOMAINS=acme.io
MUNIN_AUTH_TRUSTED_ORIGINS=https://munin.acme.io

# Hvad den kalder sig, alle steder hvor den skal navngive sig selv
NEXT_PUBLIC_MCP_URL=https://munin.acme.io/mcp
NEXT_PUBLIC_AUTH_URL=https://munin.acme.io
MUNIN_API_URL=https://munin.acme.io

Hvorfor findes der to database-URL'er?

Fordi Postgres-superbrugere omgår row-level security, uanset FORCE. MUNIN_MIGRATE_URL er den privilegerede forbindelse, der kører CREATE EXTENSION, anvender DDL og opretter den begrænsede rolle munin_app. DATABASE_URL er den, applikationen faktisk bruger, og den peger på munin_app.

Slår du de to sammen til én superbruger-URL, fordi det går hurtigere, er RLS-politikkerne der stadig og kompilerer stadig — og de holder op med at gælde. Tenancy i Munin bæres af databasen frem for af applikationskode, der tjekker et orgId på vejen forbi, så den ene genvej er forskellen mellem isolation, du kan pege på, og isolation, du håber på.

Kan én selvdrevet installation betjene flere kunder eller virksomheder?

Én installation betjener én organisation. Buildet med åben kildekode er enkelt-tenant og kun-invitation: den første, der tilmelder sig, bliver administrator for den organisation, og alle efter det skal bruge en invitationstoken eller et tilladt e-maildomæne. Til flere kundeorganisationer kører du én stak per kunde, eller du bruger Munin Cloud, som er multi-tenant-buildet af den samme kode.

En stak per kunde er en lettere byrde, end det lyder, fordi en stak her er tre containere og en Postgres frem for en platform. Ti kunder er ti compose-filer bag én omvendt proxy, hver med sit eget volumen, sin egen pg_dump, sit eget opgraderingsvindue og sin egen MCP-URL at give den kundes agent. Det er også den isolationsfortælling, du vil kunne sige højt, når en kunde spørger, hvor deres data er: ikke et filter, en maskine. Grænsen inde i skemaet gør sit arbejde uanset — row-level security-politikkerne ligger i migrationerne, og applikationen forbinder som den begrænsede rolle munin_app — og en separat udrulning lægger en separat skaderadius oven i det.

Værd at vide er, at det er der, hele kategorien står, frem for der, hvor vi står alene. EspoCRM's eget forum er direkte om, at flere virksomheder ikke understøttes, og at separate installationer er svaret. Odoo har to delvise svar frem for ét rent: multi-company inde i én database, hvor isolationen kun er så god som postreglerne, eller én Odoo-proces, der betjener flere databaser gennem dbfilter, hvor én tenants langsomme forespørgsel stadig er alles langsomme forespørgsel. På tværs af dette felt bliver »en tenant« som regel til »en udrulning« — hvilket gør fodaftrykket per udrulning i tabellen ovenfor til det tal, der afgør, hvad ti kunder koster dig. Bureauversionen af dette spørgsmål gennemgår, hvad alternativet koster, når du skriver under på den tiende.

• MUMunin — én organisation per installation, kun invitation. Flere kunder betyder flere stakke: tre containere hver, én omvendt proxy foran, én sikkerhedskopi hver. Munin Cloud er multi-tenant-buildet, hvis du hellere vil slippe for at eje det.
• ESEspoCRM — separate installationer per virksomhed. Flere instanser på én vært under separate underdomæner er mønsteret, dets community dokumenterer; cookies er værtsbundne, så sessionerne holdes adskilt.
• ODOdoo — multi-company inde i én database, isoleret af postregler, eller én proces på tværs af flere databaser via dbfilter. To forskellige afvejninger, begge med fælles fejldomæne.
• RLSUanset hvad du vælger, så spørg, hvor grænsen faktisk håndhæves — i databasen, eller i applikationskode, der skal huske det. Det svar overlever enhver funktionsliste.

Hvad er stadig en stub efter første opstart?

Tre ting, med vilje. Transaktionsmail er en stub i hukommelsen som standard, embeddings er en deterministisk lokal stub som standard, og ressourcelagring er lokal disk som standard. Intet i en frisk installation når et tredjeparts-API, hvilket betyder, at du kan evaluere hele platformen på en laptop uden at oprette en eneste leverandørkonto først.

Hver enkelt er et par linjer, når du vil have den rigtige vare.

• TransaktionsmailMUNIN_MAIL_PROVIDER=stub, indtil du sætter den til resend og angiver RESEND_API_KEY. Verifikations-, nulstillings- og invitationslinks bygges mod MUNIN_WEB_URL, så sæt den til din rigtige dashboardvært samtidig.
• EmbeddingsEn deterministisk stub, indtil OPENAI_API_KEY er sat. OPENAI_BASE_URL peger mod hvad som helst OpenAI-kompatibelt — LM Studio, vLLM eller llama.cpp på samme kasse, hvis du vil have vektorerne til at blive i huset, eller en hostet EU-udbyder hvis ikke.
• VektordimensionMUNIN_EMBEDDING_DIMENSIONS er 1536 som standard og matcher de medfølgende migrationer. Der findes ingen levende ALTER-vej for den i migrationerne med åben kildekode, så vælg embedding-model, før du indlæser dokumenter, frem for bagefter.
• Ressourcelagringlocal skriver til /var/munin/assets på volumenet munin-data og serverer gennem backenden. Skift MUNIN_STORAGE_PROVIDER til s3 for enhver S3-kompatibel tjeneste — Scaleway, R2, MinIO, AWS — via SigV4-forsignerede URL'er.

Hvad forlader faktisk maskinen?

Intet, indtil du beslutter, at det skal. En frisk installation når slet intet tredjeparts-API: mail er en stub i hukommelsen, embeddings er en deterministisk lokal stub, og ressourcer skrives til et lokalt volumen. Søgning virker, dashboardet virker, MCP-endpointet virker, og der findes ingen leverandørkonto nogen steder i opsætningen. Det er det bogstavelige svar på »privat CRM« — ikke en politikside, en standardindstilling.

Fire kontakter ændrer det, og de er værd at skrive ned som en liste, fordi den liste er dit dataflowdiagram, og det er det, en revisor beder om. At sætte MUNIN_MAIL_PROVIDER=resend sender modtageradresser og beskedtekster til Resend. At sætte OPENAI_API_KEY sender dokument- og beskedtekst til en embeddingudbyder — eller peg OPENAI_BASE_URL mod LM Studio, vLLM eller llama.cpp på samme kasse, og vektorerne forlader aldrig huset. At skifte MUNIN_STORAGE_PROVIDER til s3 sender ressourcer til den bucket, du navngiver, som kan være MinIO på samme vært. Og den LLM-udbyder, du konfigurerer til den indbyggede agentkører, er den fjerde.

Alt andet bliver, hvor du lagde det. Legitimationer til de udbydere — API-nøgler, IMAP- og SMTP-adgangskoder — krypteres i hvile gennem pgcrypto med MUNIN_ENCRYPTION_KEY, så forbindelsesstrengene i din database ikke er læsbare for nogen, der ender med en dump af den. Er din grund til at drive selv en jurisdiktion frem for en regning, har residensargumentet sin egen tekst, og den korte version er, at på din egen server er underdatabehandlerlisten, hvad de fire kontakter siger.

Hvordan peger jeg Claude, Cursor eller ChatGPT mod en selvdrevet installation?

Mod én URL: NEXT_PUBLIC_MCP_URL. Den værdi er, hvad Munin annoncerer gennem RFC 9728 protected-resource-metadata, hvad dashboardets forbindelsesuddrag viser, og hvad enhver MCP-klient får. Sæt den én gang til den adresse, klienterne faktisk kan nå, så klarer OAuth-flowet resten.

Formen til lokal udvikling er http://localhost:3001/mcp. Produktionsformen er dit eget værtsnavn bag TLS. Intet andet i klientkonfigurationen ændrer sig — det er den samme kobling som at køre dit CRM fra Claude Code mod Cloud, med værtsnavnet skiftet ud.

# Claude Code
claude mcp add munin-local http://localhost:3001/mcp

# Gennemse værktøjsfladen interaktivt
npx @modelcontextprotocol/inspector
# URL = http://localhost:3001/mcp   Auth = Bearer mn_admin_...

# Tjek transporten i hånden
curl -N -X POST http://localhost:3001/mcp \
  -H "Authorization: Bearer mn_admin_..." \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Kræver en selvdrevet installation en ekstern AI-tjeneste for at besvare noget?

Den kræver en LLM-udbyder, du vælger, og intet andet. Munin leverer sin egen agentkører i processen — per organisation, inde i backenden, ingen ekstra container — som besvarer levende samtaler på alle kanaler og arbejder en persistent baggrundskø: videnbasekuratering, CRM-hygiejne, kontaktudtræk fra lukkede tråde, udgående udkast. Eksterne MCP-klienter er valgfrie frem for påkrævede.

Det er den del, der overrasker folk, som har udrullet resten af dette felt, hvor »og nu kører du arbejderen« er fjerde punkt i enhver installationsguide. Der er ingen arbejdercontainer her og ingen Redis til at mægle køen; jobkøen er persistent i den samme Postgres, som dataene bor i, med genforsøg og dead-letter-håndtering, hvilket er det meste af grunden til, at containertallet er tre. Peg OPENAI_BASE_URL mod en lokal server, og hele sløjfen — svare, skrive udkast, kuratere — kører, uden at en pakke forlader værten.

Gennemgangsholdningen løsner ikke, fordi køreren er lokal. Udgående kontakt er foreslå-kun, uanset hvor den kører: hver besked venter i en kø på et menneske, og modtagere hentes kun fra kontakter med registreret samtykke. Vi skrev op, hvorfor den kø er den interessante del frem for skrivningen.

Hvordan sikkerhedskopierer jeg et selvdrevet CRM?

Én database og ét ressourcevolumen, på en tidsplan, gendannet et andet sted mindst én gang. For Munin er det en pg_dump af volumenet munin-pg og en kopi af munin-data; ethvert andet projekt på denne side er de samme to objekter med andre navne. Der findes ingen håndteret sikkerhedskopitjeneste i noget selvdrevet build, inklusive vores. Det job er dit.

Den del, folk springer over, er gendannelsen. En sikkerhedskopi, du aldrig har gendannet, er en fil, ikke en sikkerhedskopi, og fejlen opdages altid på den værst tænkelige morgen. Gendan ind i en midlertidig container én gang, bekræft rækketallene, og læg en påmindelse i kalenderen om et halvt år.

# Dump databasen
docker compose exec -T postgres \
  pg_dump -U munin -Fc munin > munin-$(date +%F).dump

# Kopiér ressourcevolumenet
docker run --rm -v munin-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/munin-data-$(date +%F).tar.gz -C /data .

# Gendan ind i en midlertidig database og tæl rækkerne
docker compose exec -T postgres createdb -U munin munin_restore_test
docker compose exec -T postgres \
  pg_restore -U munin -d munin_restore_test < munin-$(date +%F).dump

Hvad går i stykker, når du opgraderer?

Som regel intet, og undtagelsen er altid Postgres. Munin anvender sine egne migrationer ved hver opstart, så at hente et nyt image og genstarte er hele opgraderingsvejen for applikationen. En hovedversionsændring i Postgres er noget andet: datakatalogens format ændrer sig, containeren nægter at starte mod det gamle volumen, og du skal bruge en dump-og-genindlæs. Det gælder hvert projekt her, der leverer en databasecontainer, hvilket er de fleste af dem.

To vaner gør det her udramatisk. Lås image-tags frem for at følge latest, så en genstart klokken to om natten ikke også er en versionsopgradering. Og tag dumpen ovenfor umiddelbart før enhver opgradering, ikke på den sædvanlige tidsplan — de fem minutter, det koster, er forskellen mellem en tilbagerulning og en hændelse.

Hvad koster egen drift, som Munin Cloud ikke gør?

Driftsarbejde, der intet har med kunder at gøre. Sikkerhedskopier af volumenet munin-pg, TLS-terminering foran port 3001, opgraderinger på din egen tidsplan, og den, der svarer, når Postgres fylder disken klokken tre om natten. Munin leverer ingen håndteret sikkerhedskopitjeneste; det job er dit, og det er et rigtigt job.

Hvad du får for det, er den version af ejerskab, der overlever en prisside. Ingen lofter på kontakter, kald eller lagring, fordi der ikke findes nogen måler i koden til at håndhæve dem. Datalagring der, hvor du stiller maskinen, besluttet af dig frem for af en underdatabehandlerliste. Og en revisionslog, en gennemgangskø og 226 MCP-værktøjer, der opfører sig identisk med det hostede build, fordi det er det samme build. Hvert modul leverer også symmetriske eksport- og importværktøjer, så at flytte mellem din maskine og Cloud er en scriptet operation i begge retninger frem for en forhandling — hvilket er hele pointen med licensen.

Hvordan er fodaftrykket sammenlignet med Chatwoot, Zammad eller EspoCRM?

Alle kører på én vært. Forskellen er, hvor mange tjenester du holder i live, og hvor meget af kunden hver af dem rummer.

Chatwoot er den mest komplette selvdrevne indbakke i feltet, og det er ikke tæt på kanalbredde: WhatsApp, Instagram, Facebook og Telegram har alle førsteklasses indbakker. Bor din support allerede på WhatsApp, så installér Chatwoot — Munins fire kanaler er e-mail, chatwidget, SMS og tale, og det er den køber, Chatwoot bør vinde. Dens udrulning tilføjer en Rails-webproces, en Sidekiq-arbejder, Postgres og Redis, og dens enterprise/-mappe ligger under en separat kommerciel licens.

Zammad er den dybeste sagsmotor her og holder intet tilbage under AGPL-3.0. Den vil også have Elasticsearch ved siden af Postgres og Redis for en søgning, der er værd at have, hvilket er en fjerde tjeneste med sin egen hukommelsesprofil og sine egne holdninger.

EspoCRM er den letteste af de tre og den mest konventionelle — et modent CRM, der kører på en 1 GB-kasse, med en jobdæmon, en valgfri WebSocket-server og MariaDB ved siden af. Det er AGPL-3.0 med en kommerciel licens solgt separat, og dets Advanced Pack er en betalt udvidelse licenseret per installation.

Munin er tre containere, fordi der er ét datalager og én kunde under alle seks moduler. En supporttråd, en handel, en videnartikel, et udgivet opslag og et udgående udkast, der rører den samme person, er rækker, der allerede ved om hinanden — intet synkjob, ingen afstemning, intet andet kildesystem, der stille er uenigt med det første. Det er det, der gør værktøjsfladen værd at pege en agent mod: agenten læser en samtale og opdaterer en kontakt og citerer et dokument i én session, fordi der intet er mellem de tre ting. Vil du have den fyldigere rangering på hver side, har vi skrevet begge — feltet for CRM med åben kildekode og feltet for helpdesks med åben kildekode, med licenserne læst ordentligt i begge.

Kan du drive et CRM selv gratis?

Licensen, ja. Maskinen, nej. Hvert projekt i tabellen ovenfor koster intet at installere, og Munin, Zammad, ERPNext og Dolibarr holder slet intet tilbage bag et betalt niveau. Hvad du betaler i stedet, er en VPS — realistisk 5 til 20 € om måneden for en af disse — plus de timer, ingen fører ind i regnearket.

En analyse fra Open Source Alternatives beregnede et selvdrevet CRM til omtrent 4.500 til 10.800 dollar over tre år, det meste af det ingeniørtid til 100 dollar i timen og to til fem timers vedligehold om måneden, mod 86.000 til 132.000 dollar for Salesforce Enterprise i samme vindue. Behandl begge som vejledende frem for som tilbud. Kløften er stadig grunden til, at hele denne kategori findes, og sammenligningen licens for licens er der, hvor den gratis halvdel bliver læst ordentligt.

Den ærlige version af afvejningen: egen drift laver et abonnement om til et ansvar. Er nogen på dit team glad for at eje en Postgres, er det en god handel, og softwaren er reelt gratis. Er ingen det, er en hostet plan billigere end nedbruddet.

Hvem bør drive selv, og hvem bør ikke?

Driv selv, hvis du har en datalagringsforpligtelse, der navngiver en jurisdiktion eller en maskine, hvis du allerede kører Postgres til noget andet, og vagtordningen findes, eller hvis du har tænkt dig at ændre koden — MIT betyder, at du kan forke den, levere den og aldrig fortælle os det.

Driv ikke selv, hvis du er én person. Sikkerhedskopier, opgraderinger og opkaldet klokken tre om natten er et job nummer to, og en stifter har allerede ét. Cloud Free koster 0 € om måneden med alle seks moduler og alle fire kanaler låst op, begrænset til 5.000 MCP-kald, 250 kontakter og 100 MB — nok til på en eftermiddag at finde ud af, om formen passer dig, på nøjagtigt koden i denne artikel. Flyt til din egen maskine senere, hvis du vil; eksportværktøjerne ligger i repoet, og de virker begge veje.

Ofte stillede spørgsmål

Hvad er det bedste selvdrevne CRM? Til en salgspipeline, Twenty. Til dyb tilpasning af en salgsproces i en stor virksomhed, SuiteCRM. Til bredde uden noget spærret, Dolibarr eller ERPNext. Til den letteste mulige kasse, EspoCRM. Til CRM og helpdesk på én kundepost under en tilladende licens, Munin — tre containere, MIT hele vejen, ét docker compose up. Dit reelle udvælgelseskriterium er, hvilket du stadig patcher om seks måneder.

Hvad er den bedste selvdrevne helpdesk? Chatwoot, hvis du har brug for WhatsApp-, Instagram- og Telegram-indbakker. Zammad, hvis du har brug for det dybeste sags- og workflowsystem og kan drive Elasticsearch. FreeScout, hvis du vil have en delt postkasse på billig PHP-hosting. Munin, hvis supporttråden og CRM-posten bør være den samme kunde frem for to systemer, der synkroniserer.

Hvad er systemkravene for selv at drive Munin? En Linux-vært med Docker og Docker Compose, omkring 2 GB RAM, og nok disk til Postgres og dine CMS-ressourcer — 20 GB er en fornuftig start. Stakken er tre containere, uden Redis, kømægler eller søgeklynge at skaffe ved siden af.

Hvor meget RAM kræver et selvdrevet CRM? Én til otte gigabyte, sat af hvor mange tjenester projektet kører frem for af hvor mange kontakter du har. EspoCRM, SuiteCRM og FreeScout er glade for 1 GB. Munin vil have omkring 2 GB. Twenty beder om mindst 2 GB. Zammad anbefaler mindst 4 GB, mere hvis Elasticsearch deler værten. ERPNext starter ved 4 GB og vil have 8 GB ved 25 til 50 brugere.

Kan én selvdrevet installation betjene flere kunder? Én installation betjener én organisation. Buildet med åben kildekode er enkelt-tenant og kun-invitation, så flere kunder betyder flere stakke — tre containere hver, bag én omvendt proxy — eller Munin Cloud, som er multi-tenant-buildet af den samme kode. Det ligger tæt på kategoriens norm: EspoCRM dokumenterer separate installationer per virksomhed, og Odoos svar er multi-company inde i én database eller dbfilter på tværs af flere.

Hvad forlader maskinen på en selvdrevet installation? Intet som standard. Mail, embeddings og ressourcelagring leveres alle som lokale stubs, så en frisk installation når intet tredjeparts-API. Fire indstillinger ændrer det — en mailudbyder, en embeddingnøgle, S3-lagring og LLM-udbyderen til agentkøreren — og hver har en lokal mulighed: llama.cpp eller vLLM til embeddings, MinIO til ressourcer, en lokal model til køreren.

Skal jeg bruge en OpenAI-nøgle for at køre det? Nej. Embeddings falder tilbage på en deterministisk lokal stub, så søgning virker fra starten. Sæt OPENAI_BASE_URL til en lokal server — LM Studio, vLLM, llama.cpp — hvis du vil have rigtige vektorer, uden at noget forlader værten.

Kræver den en separat arbejder- eller køcontainer? Nej. Agentkøreren er i processen, per organisation, og dens jobkø er persistent i den samme Postgres som alt andet, med genforsøg og dead-letter-håndtering. Det er hovedgrunden til, at stakken er tre containere frem for fem.

Er selvdrevet Munin det samme som Munin Cloud? Samme kode. Buildet med åben kildekode sætter de delte moduler sammen med enorganisationsautentificering; Cloud sætter de identiske moduler sammen med multi-tenant-autentificering. Hele kataloget — 226 MCP-værktøjer, mere end 250 REST-endpoints og 60 medfølgende færdigheder — findes i begge.

Er Munin virkelig MIT, eller er det open core? MIT, uden en enterprise-mappe i repoet og uden en funktion holdt tilbage til et betalt niveau. Det er en bevidst forskel fra det meste af denne kategori, hvor mærket på forsiden siger åben kildekode, og den nyttige halvdel bor under en separat licens — nogle gange i en mappe, nogle gange i en licensoverskrift på enkeltfiler, nogle gange i et repo, du ikke kan se. Den fulde sammenligning licens for licens findes her.

Hvilket containerimage bør jeg låse? Tjek, hvem der publicerer det. Den 28. august 2025 flyttede Bitnami sit eksisterende katalog til docker.io/bitnamilegacy, som ikke modtager flere opdateringer eller sikkerhedsrettelser, og for flere projekter i dette felt var det det mest hentede image på Docker Hub. Foretræk et image, projektet selv bygger; findes der intet, så vid, hvis build du stoler på.

Hvordan sikkerhedskopierer jeg en selvdrevet installation? En pg_dump af databasen og en kopi af ressourcevolumenet, på en tidsplan. Gendan den derefter ind i en midlertidig database én gang, og tjek rækketallene, fordi en ugendannet sikkerhedskopi er en fil frem for en sikkerhedskopi.

Hvordan forbinder jeg Claude eller Cursor til en selvdrevet instans? Sæt NEXT_PUBLIC_MCP_URL til den adresse, dine klienter kan nå, og tilføj derefter den URL i klienten. Munin annoncerer den gennem RFC 9728, og det første kald udløser samtykkeskærmen i din browser.

Kan jeg flytte til Munin Cloud senere, eller tilbage igen? Ja, begge veje. Hvert modul leverer symmetriske *_export- og *_import-værktøjer over MCP, og den medfølgende færdighed playbooks/data-migration sekvenserer dem i fremmednøglerækkefølge, så afhængige poster finder deres forældre på målet.

Repoet ligger på GitHub under MIT, og vil du hellere slippe for selv at køre Postgres, er Munin Cloud Free den samme kode uden vagttelefonen.

Kører det ikke på én maskine, du ejer, er det ikke selvdrevet. Så er det bare hostet.