Drift hele greia selv på én maskin.

Installasjonen er ikke den vanskelige delen, og har ikke vært det på årevis. Klon repoet, kopier eksempel-env-fila, kjør én kommando, og tre containere kommer opp på én vert. Det vanskelige er de neste fjorten dagene: plassholderhemmelighetene du aldri byttet ut, e-postsenderen som fortsatt er en stubbe, Postgres-rollen som avgjør om row-level security i det hele tatt gjør noe. Dette er runden som dekker dem, i den rekkefølgen maskinen tvinger fram.

Kan du selvdrifte et CRM og en supportløsning på én maskin?

Ja. Munin selvdriftes som tre containere — Postgres med pgvector, en backend på port 3001, et dashbord på port 3000 — startet av én enkelt docker compose up mot det MIT-lisensierte repositoriet. Det finnes ingen seteantall, ingen kontakttak og ingen funksjonssperre. Det selvdriftede bygget er den samme koden som kjører Munin Cloud, satt sammen med enbrukerorganisasjons-auth i stedet for flerleietaker.

Det siste poenget er verdt å dvele ved, fordi det er uvanlig i denne kategorien. Det finnes ingen enterprise/- eller ee/-katalog i repoet som holder tilbake delene du faktisk vil ha. MIT dekker alt sammen — kunnskapsbase, samtaler, CRM, CMS, utgående kontakt, analyse, kuratorkøen, revisjonsloggen, webhooks og hele MCP-verktøykatalogen.

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

Hva er det beste selvdriftede CRM-et og den beste supportløsningen i 2026?

Det finnes ingen enkelt vinner, og den ærlige måten å dele feltet på er etter hvor mange bevegelige deler du er villig til å eie. FreeScout og EspoCRM er de letteste — begge kjører på helt vanlig PHP-hosting. Twenty er det peneste selvdriftede CRM-et. SuiteCRM er det mest tilpassbare for bedriftssalgsprosesser. Chatwoot har bredest kanaldekning. Zammad er det dypeste sakssystemet. ERPNext er det mest komplette gratis ERP-et. Munin legger CRM og supportløsning på én post fra én kommando.

Den innrammingen betyr mer enn et funksjonsrutenett, fordi på ditt eget jern koster funksjonen du aldri bruker ingenting, og tjenesten du må holde i live koster hver uke. Zammad vil ha PostgreSQL, Redis, en Rails-app og — sterkt anbefalt, om du vil at søket skal være godt — Elasticsearch, som fører med seg heap-dimensjonering og indekshåndtering. ERPNext kjører Gunicorn, en arbeiderpool, Node, MariaDB og tre separate Redis-instanser for cache, kø og socketio. SuiteCRM ligger i den andre enden: en Apache- og PHP-applikasjon med en cron-jobb og én MySQL eller MariaDB bak seg, som er grunnen til at det fortsatt dukker opp på delt hosting to tiår senere. Alle tre er utmerket programvare; to av dem ber deg drifte infrastruktur tilsvarende et lite plattformteam.

Den andre aksen er lisensen, og den sorterer ikke slik merkene antyder. Chatwoot er MIT i roten med en enterprise/-katalog under en separat kommersiell lisens — SLA-håndtering, revisjonslogger og egendefinerte dashbord bor i den, og produksjonsbruk av den mappa krever et abonnement. Twenty er AGPL-3.0 med enkeltfiler merket @license Enterprise. FreeScout er AGPL-3.0 med offisielle moduler — Knowledge Base, Workflows, Customer Portal — solgt per lisensnøkkel. SuiteCRM, Zammad, ERPNext og Dolibarr holder ingenting tilbake. Ingenting av det er uredelig; alt sammen er normalt. Det betyr bare at det du kan selvdrifte, ikke alltid er det du fikk demonstrert.

Kontrollert på nytt mot hvert prosjekts egen utrullings- og lisensdokumentasjon 3. september 2026; SuiteCRM-raden ble lagt til 16. september 2026. Pakking flytter seg; sjekk repositoriet før du binder deg, også vårt.

Hva starter docker compose up egentlig?

Tre tjenester og to navngitte volumer. Postgres 16 med vektorutvidelsen, backenden og web-dashbordet. Ingen Redis, ingen egen køprosess, ingen søkeklynge — både kurator-jobbkøen og det hybride fulltekst- og pgvector-søket bor i den samme Postgres som resten av dataene.

Backend-containeren kjører node dist/migrate.js før node dist/main.js, så migrasjoner anvendes ved hver oppstart. Postgres melder seg frisk før backenden får lov å starte.

• PGpgvector/pgvector:pg16 på munin-pg-volumet. Den eneste tilstandsførende tjenesten i stakken, og den eneste du trenger en sikkerhetskopiplan for.
• APIBackenden på :3001 — MCP over Streamable HTTP, OAuth 2.1 med dynamisk klientregistrering, og REST-kontrollplanet. Ressurser lander på munin-data-volumet.
• WEBDashbordet på :3000 — innlogging, API-nøkler, gjennomgangskøer, tilkoblingskort. Ikke der arbeidet skjer. Agenten er der arbeidet skjer.

Hvor mye RAM trenger et selvdriftet CRM?

Mellom 1 GB og 8 GB, helt avhengig av hvor mange tjenester prosjektet tvinger deg til å kjøre. FreeScout kjører på den billigste VPS-en en leverandør selger. EspoCRM har det behagelig på 1 GB. Munin vil ha omtrent 2 GB til Postgres pluss to Node-prosesser. Twenty ber om minst 2 GB. Zammad anbefaler minst 4 GB til containerne, mer hvis Elasticsearch deler maskinen. ERPNext starter på 4 GB for en liten produksjonsinstans og 8 GB ved 25 til 50 brukere.

Feilmodusen er alltid den samme, og den er verdt å navngi: for lite minne gir ikke en feilmelding, det gir swap. En side som tok 200 ms tar fire sekunder, bakgrunnsjobber stopper stille opp, og du bruker en lørdag overbevist om at applikasjonen er ødelagt. Kjøp neste VPS-størrelse opp. Det er den billigste beslutningen på denne siden.

Disk er den enklere halvdelen — databasen, opplastede ressurser, og plass til å holde en dump mens du gjenoppretter den. Tjue gigabyte er et fornuftig utgangspunkt for alle disse, og Postgres vil si fra i god tid før det betyr noe.

Hvilke hemmeligheter må jeg sette før noen andre kan nå den?

Fire: MUNIN_AUTH_SECRET, MUNIN_KEY_PEPPER, MUNIN_ENCRYPTION_KEY og MUNIN_STORAGE_LOCAL_SECRET. Lar du dem stå på replace-me-*-plassholderne, genererer docker compose up sterke verdier ved første oppstart og lagrer dem i munin-data-volumet. Det er greit på en laptop. For noe som deles, sett dem selv, så de overlever et volum du bestemmer deg for å kaste.

To til styrer hvem som slipper inn i det hele tatt. MUNIN_ALLOWED_EMAIL_DOMAINS er tom som standard, som betyr kun-invitasjon: den første som registrerer seg blir administrator for den ene organisasjonen, og alle etter det trenger et invitasjonstoken. MUNIN_AUTH_TRUSTED_ORIGINS er som standard localhost:3000 (og 127.0.0.1:3000) og må settes til din reelle dashbord-URL i produksjon, ellers feiler innlogging på CSRF-sjekken.

# Én linje hver, ved installasjon.
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 som kan nå den
MUNIN_ALLOWED_EMAIL_DOMAINS=acme.io
MUNIN_AUTH_TRUSTED_ORIGINS=https://munin.acme.io

# Hva den kaller seg, overalt der den må navngi seg 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 finnes det to database-URL-er?

Fordi Postgres-superbrukere omgår row-level security, uansett FORCE. MUNIN_MIGRATE_URL er den privilegerte tilkoblingen som kjører CREATE EXTENSION, anvender DDL og oppretter den begrensede munin_app-rollen. DATABASE_URL er den applikasjonen faktisk bruker, og den peker på munin_app.

Slår du de to sammen til én superbruker-URL fordi det går raskere, er RLS-policyene fortsatt der og kompilerer fortsatt — og de slutter å gjelde. Tenancy i Munin bæres av databasen framfor av applikasjonskode som sjekker en orgId på veien forbi, så den ene snarveien er forskjellen mellom isolasjon du kan peke på og isolasjon du håper på.

Kan én selvdriftet installasjon betjene flere kunder eller selskaper?

Én installasjon betjener én organisasjon. Bygget med åpen kildekode har én leietaker og er kun-invitasjon: den første som registrerer seg blir administrator for den organisasjonen, og alle etter det trenger et invitasjonstoken eller et tillatt e-postdomene. For flere kundeorganisasjoner kjører du én stakk per kunde, eller du bruker Munin Cloud, som er flerleietakerbygget av den samme koden.

En stakk per kunde er en lettere byrde enn det høres ut som, fordi en stakk her er tre containere og en Postgres framfor en plattform. Ti kunder er ti compose-filer bak én omvendt proxy, hver med sitt eget volum, sin egen pg_dump, sitt eget oppgraderingsvindu og sin egen MCP-URL å gi den kundens agent. Det er også isolasjonsfortellingen du vil kunne si høyt når en kunde spør hvor dataene deres er: ikke et filter, en maskin. Grensen inne i skjemaet gjør jobben sin uansett — row-level security-policyene ligger i migrasjonene, og applikasjonen kobler til som den begrensede munin_app-rollen — og en egen utrulling legger en egen skaderadius oppe på det.

Verdt å vite at det er der hele kategorien står, framfor der vi står alene. EspoCRMs eget forum er tydelig på at flere selskaper ikke støttes, og at separate installasjoner er svaret. Odoo har to delvise svar framfor ett rent: flerselskap inne i én database, der isolasjonen bare er så god som postreglene, eller én Odoo-prosess som betjener flere databaser gjennom dbfilter, der én leietakers trege spørring fortsatt er alles trege spørring. På tvers av dette feltet blir «en leietaker» som regel til «en utrulling» — som gjør fotavtrykket per utrulling i tabellen over til tallet som avgjør hva ti kunder koster deg. Byråversjonen av dette spørsmålet går gjennom hva alternativet koster når du signerer den tiende.

• MUMunin — én organisasjon per installasjon, kun invitasjon. Flere kunder betyr flere stakker: tre containere hver, én omvendt proxy foran, én sikkerhetskopi hver. Munin Cloud er flerleietakerbygget om du heller ikke vil eie det.
• ESEspoCRM — separate installasjoner per selskap. Flere instanser på én vert under separate underdomener er mønsteret fellesskapet dokumenterer; informasjonskapsler er vertsbundne, så øktene holder seg fra hverandre.
• ODOdoo — flerselskap inne i én database, isolert av postregler, eller én prosess på tvers av flere databaser via dbfilter. To ulike byttehandler, begge med felles feilområde.
• RLSUansett hva du velger, spør hvor grensen faktisk håndheves — i databasen, eller i applikasjonskode som må huske det. Det svaret overlever enhver funksjonsliste.

Hva er fortsatt en stubbe etter første oppstart?

Tre ting, med vilje. Transaksjonell e-post er en stubbe i minnet som standard, embeddinger er en deterministisk lokal stubbe som standard, og ressurslagring er lokal disk som standard. Ingenting i en fersk installasjon når et tredjeparts-API, som betyr at du kan vurdere hele plattformen på en laptop uten å opprette en eneste leverandørkonto først.

Hver enkelt er et par linjer når du vil ha den ekte varen.

• Transaksjonell e-postMUNIN_MAIL_PROVIDER=stub til du setter den til resend og oppgir RESEND_API_KEY. Verifiserings-, tilbakestillings- og invitasjonslenker bygges mot MUNIN_WEB_URL, så sett den til din reelle dashbordvert samtidig.
• EmbeddingerEn deterministisk stubbe til OPENAI_API_KEY er satt. OPENAI_BASE_URL peker mot hva som helst OpenAI-kompatibelt — LM Studio, vLLM eller llama.cpp på den samme maskinen om du vil at vektorene skal bli i bygget, eller en driftet EU-leverandør om du ikke vil det.
• VektordimensjonMUNIN_EMBEDDING_DIMENSIONS er 1536 som standard og matcher migrasjonene som følger med. Det finnes ingen levende ALTER-vei for den i migrasjonene med åpen kildekode, så velg embedding-modell før du laster inn dokumenter framfor etterpå.
• Ressurslagringlocal skriver til /var/munin/assets på munin-data-volumet og serverer gjennom backenden. Bytt MUNIN_STORAGE_PROVIDER til s3 for hvilken som helst S3-kompatibel tjeneste — Scaleway, R2, MinIO, AWS — via SigV4-presignerte URL-er.

Hva forlater egentlig maskinen?

Ingenting, før du bestemmer at det skal. En fersk installasjon når ikke noe tredjeparts-API i det hele tatt: e-post er en stubbe i minnet, embeddinger er en deterministisk lokal stubbe, og ressurser skrives til et lokalt volum. Søk virker, dashbordet virker, MCP-endepunktet virker, og det finnes ingen leverandørkonto noe sted i oppsettet. Det er det bokstavelige svaret på «privat CRM» — ikke en policyside, en standardinnstilling.

Fire brytere endrer det, og de er verdt å skrive ned som en liste, fordi den lista er dataflytdiagrammet ditt og det er det en revisor ber om. Å sette MUNIN_MAIL_PROVIDER=resend sender mottakeradresser og meldingstekster til Resend. Å sette OPENAI_API_KEY sender dokument- og meldingstekst til en embedding-leverandør — eller pek OPENAI_BASE_URL mot LM Studio, vLLM eller llama.cpp på den samme maskinen, og vektorene forlater aldri bygget. Å bytte MUNIN_STORAGE_PROVIDER til s3 sender ressurser til bøtta du navngir, som kan være MinIO på den samme verten. Og LLM-leverandøren du konfigurerer for den innebygde agentkjøreren er den fjerde.

Alt annet blir der du la det. Legitimasjon for de leverandørene — API-nøkler, IMAP- og SMTP-passord — krypteres i ro gjennom pgcrypto med MUNIN_ENCRYPTION_KEY, så tilkoblingsstrengene i databasen din ikke er lesbare for noen som ender opp med en dump av den. Er grunnen din til å selvdrifte en jurisdiksjon framfor en regning, har residensargumentet sin egen tekst, og kortversjonen er at på ditt eget jern er underleverandørlista det de fire bryterne sier.

Hvordan peker jeg Claude, Cursor eller ChatGPT mot en selvdriftet installasjon?

Mot én URL: NEXT_PUBLIC_MCP_URL. Den verdien er det Munin annonserer gjennom RFC 9728 protected-resource-metadata, det dashbordets tilkoblingsutdrag viser, og det hver MCP-klient blir gitt. Sett den én gang til adressen klientene faktisk kan nå, så gjør OAuth-flyten resten.

Formen for lokal utvikling er http://localhost:3001/mcp. Produksjonsformen er ditt eget vertsnavn bak TLS. Ingenting annet i klientkonfigurasjonen endrer seg — dette er den samme oppkoblingen som å kjøre CRM-et ditt fra Claude Code mot Cloud, med vertsnavnet byttet ut.

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

# Bla i verktøyflaten interaktivt
npx @modelcontextprotocol/inspector
# URL = http://localhost:3001/mcp   Auth = Bearer mn_admin_...

# Sjekk transporten for hånd
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"}'

Trenger en selvdriftet installasjon en ekstern AI-tjeneste for å svare på noe?

Den trenger en LLM-leverandør du velger, og ingenting annet. Munin leverer sin egen agentkjører i prosessen — per organisasjon, inne i backenden, ingen ekstra container — som svarer på levende samtaler på alle kanaler og jobber en varig bakgrunnskø: kunnskapsbasekurering, CRM-hygiene, kontaktuttrekk fra lukkede tråder, utgående utkast. Eksterne MCP-klienter er valgfrie framfor påkrevd.

Dette er delen som overrasker folk som har rullet ut resten av dette feltet, der «og nå kjører du arbeideren» er fjerde kulepunkt i hver installasjonsveiledning. Det finnes ingen arbeidercontainer her og ingen Redis å megle køen; jobbkøen er varig i den samme Postgres som dataene bor i, med ny-forsøk og håndtering av dødbrev, som er mesteparten av grunnen til at containertallet er tre. Pek OPENAI_BASE_URL mot en lokal server, og hele sløyfen — svare, skrive utkast, kurere — kjører uten at en pakke forlater verten.

Gjennomgangsholdningen løsner ikke fordi kjøreren er lokal. Utgående kontakt er foreslå-bare uansett hvor den kjører: hver melding venter i en kø på et menneske, og mottakere hentes bare fra kontakter med registrert samtykke. Vi skrev opp hvorfor den køen er den interessante delen framfor skrivingen.

Hvordan sikkerhetskopierer jeg et selvdriftet CRM?

Én database og ett ressursvolum, på en tidsplan, gjenopprettet et annet sted minst én gang. For Munin er det en pg_dump av munin-pg-volumet og en kopi av munin-data; hvert eneste andre prosjekt på denne siden er de samme to objektene med andre navn. Det finnes ingen driftet sikkerhetskopitjeneste i noe selvdriftet bygg, inkludert vårt. Den jobben er din.

Delen folk hopper over, er gjenopprettingen. En sikkerhetskopi du aldri har gjenopprettet, er en fil, ikke en sikkerhetskopi, og feilen oppdages alltid på den verst tenkelige morgenen. Gjenopprett inn i en midlertidig container én gang, bekreft radantallene, og legg en påminnelse i kalenderen om et halvt år.

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

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

# Gjenopprett inn i en midlertidig database og tell radene
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

Hva ryker når du oppgraderer?

Som regel ingenting, og unntaket er alltid Postgres. Munin anvender sine egne migrasjoner ved hver oppstart, så å hente et nytt image og starte på nytt er hele oppgraderingsveien for applikasjonen. En hovedversjonsendring i Postgres er noe annet: formatet på datakatalogen endrer seg, containeren nekter å starte mot det gamle volumet, og du trenger en dump-og-last-inn. Det gjelder hvert prosjekt her som leverer en databasecontainer, som er de fleste av dem.

To vaner gjør dette udramatisk. Pinn image-tagger framfor å følge latest, så en omstart klokka to om natta ikke også er en versjonsoppgradering. Og ta dumpen over rett før enhver oppgradering, ikke på den vanlige tidsplanen — de fem minuttene det koster, er forskjellen mellom en tilbakerulling og en hendelse.

Hva koster selvdrift som Munin Cloud ikke gjør?

Driftsarbeid som ikke har noe med kunder å gjøre. Sikkerhetskopier av munin-pg-volumet, TLS-terminering foran port 3001, oppgraderinger på din egen tidsplan, og den som svarer når Postgres fyller disken klokka tre om natta. Munin leverer ingen driftet sikkerhetskopitjeneste; den jobben er din, og den er en reell jobb.

Det du får for det, er den versjonen av eierskap som overlever en prisside. Ingen tak på kontakter, kall eller lagring, fordi det ikke finnes noen måler i koden til å håndheve dem. Datalagring der du setter maskinen, avgjort av deg framfor av en underleverandørliste. Og en revisjonslogg, en gjennomgangskø og 226 MCP-verktøy som oppfører seg identisk med det driftede bygget, fordi det er det samme bygget. Hver modul leverer også symmetriske eksport- og importverktøy, så å flytte mellom ditt jern og Cloud er en skriptet operasjon i begge retninger framfor en forhandling — som er hele poenget med lisensen.

Hvordan er fotavtrykket sammenliknet med Chatwoot, Zammad eller EspoCRM?

Alle kjører på én vert. Forskjellen er hvor mange tjenester du holder i live og hvor mye av kunden hver av dem rommer.

Chatwoot er den mest komplette selvdriftede innboksen i feltet, og det er ikke jevnt på kanalbredde: WhatsApp, Instagram, Facebook og Telegram har alle førsteklasses innbokser. Bor supporten din allerede på WhatsApp, installer Chatwoot — Munins fire kanaler er e-post, chat-widget, SMS og tale, og det er kjøperen Chatwoot bør vinne. Utrullingen legger til en Rails-webprosess, en Sidekiq-arbeider, Postgres og Redis, og enterprise/-katalogen ligger under en separat kommersiell lisens.

Zammad er den dypeste saksmotoren her og holder ingenting tilbake under AGPL-3.0. Den vil også ha Elasticsearch ved siden av Postgres og Redis for et søk som er verdt å ha, som er en fjerde tjeneste med sin egen minneprofil og sine egne meninger.

EspoCRM er den letteste av de tre og den mest konvensjonelle — et modent CRM som kjører på en 1 GB-maskin, med en jobbdemon, en valgfri WebSocket-server og MariaDB ved siden av. Det er AGPL-3.0 med en kommersiell lisens solgt separat, og Advanced Pack er en betalt utvidelse lisensiert per installasjon.

Munin er tre containere fordi det er ett datalager og én kunde under alle seks moduler. En supporttråd, en avtale, en kunnskapsartikkel, et publisert innlegg og et utgående utkast som berører den samme personen, er rader som allerede vet om hverandre — ingen synkjobb, ingen avstemming, intet andre kildesystem som stille er uenig med det første. Det er det som gjør verktøyflaten verdt å peke en agent mot: agenten leser en samtale, oppdaterer en kontakt og siterer et dokument i én økt, fordi det ikke er noe mellom de tre tingene. Vil du ha den fyldigere rangeringen på hver side, har vi skrevet begge — feltet for CRM med åpen kildekode og feltet for supportløsninger med åpen kildekode, med lisensene lest ordentlig i begge.

Kan du selvdrifte et CRM gratis?

Lisensen, ja. Maskinen, nei. Hvert prosjekt i tabellen over koster ingenting å installere, og Munin, Zammad, ERPNext og Dolibarr holder ingenting tilbake bak et betalt nivå i det hele tatt. Det du betaler i stedet, er en VPS — realistisk 5 til 20 € i måneden for en av disse — pluss timene ingen fører opp i regnearket.

En analyse fra Open Source Alternatives kostnadsberegnet et selvdriftet CRM til omtrent 4 500 til 10 800 dollar over tre år, mesteparten av det ingeniørtid til 100 dollar timen og to til fem timer i måneden med vedlikehold, mot 86 000 til 132 000 dollar for Salesforce Enterprise i det samme vinduet. Behandle begge som veiledende framfor som tilbud. Gapet er fortsatt grunnen til at hele denne kategorien finnes, og sammenlikningen lisens for lisens er der den gratis halvdelen blir lest ordentlig.

Den ærlige versjonen av byttehandelen: selvdrift gjør et abonnement om til et ansvar. Er noen på teamet ditt glad for å eie en Postgres, er det en god handel, og programvaren er genuint gratis. Er ingen det, er en driftet plan billigere enn nedetiden.

Hvem bør selvdrifte, og hvem bør ikke?

Selvdrift om du har en datalagringsforpliktelse som navngir en jurisdiksjon eller en maskin, om du allerede kjører Postgres til noe annet og vaktordningen finnes, eller om du har tenkt å endre koden — MIT betyr at du kan forke den, levere den og aldri fortelle oss om det.

Ikke selvdrift om du er én person. Sikkerhetskopier, oppgraderinger og telefonen klokka tre om natta er en jobb nummer to, og en gründer har allerede én. Cloud Free koster 0 € i måneden med alle seks moduler og alle fire kanaler åpne, begrenset til 5 000 MCP-kall, 250 kontakter og 100 MB — nok til å finne ut på en ettermiddag om formen passer deg, på nøyaktig koden i denne teksten. Flytt til din egen maskin senere om du vil; eksportverktøyene ligger i repoet, og de virker begge veier.

Ofte stilte spørsmål

Hva er det beste selvdriftede CRM-et? For en salgspipeline, Twenty. For dyp tilpasning av en bedriftssalgsprosess, SuiteCRM. For bredde uten noe sperret, Dolibarr eller ERPNext. For den letteste mulige maskinen, EspoCRM. For CRM og supportløsning på én kundepost under en tillatende lisens, Munin — tre containere, MIT hele veien, én docker compose up. Ditt reelle utvalgskriterium er hvilket du fortsatt vil patche om seks måneder.

Hva er den beste selvdriftede supportløsningen? Chatwoot om du trenger WhatsApp-, Instagram- og Telegram-innbokser. Zammad om du trenger det dypeste sakssystemet og arbeidsflytmotoren og kan drifte Elasticsearch. FreeScout om du vil ha en delt postkasse på billig PHP-hosting. Munin om supporttråden og CRM-posten bør være den samme kunden framfor to systemer som synkroniserer.

Hva er systemkravene for å selvdrifte Munin? En Linux-vert med Docker og Docker Compose, rundt 2 GB RAM, og nok disk til Postgres og CMS-ressursene dine — 20 GB er et fornuftig utgangspunkt. Stakken er tre containere, uten Redis, kømegler eller søkeklynge å skaffe ved siden av.

Hvor mye RAM trenger et selvdriftet CRM? Én til åtte gigabyte, satt av hvor mange tjenester prosjektet kjører framfor av hvor mange kontakter du har. EspoCRM, SuiteCRM og FreeScout er fornøyde på 1 GB. Munin vil ha omtrent 2 GB. Twenty ber om minst 2 GB. Zammad anbefaler minst 4 GB, mer om Elasticsearch deler verten. ERPNext starter på 4 GB og vil ha 8 GB ved 25 til 50 brukere.

Kan én selvdriftet installasjon betjene flere kunder? Én installasjon betjener én organisasjon. Bygget med åpen kildekode har én leietaker og er kun-invitasjon, så flere kunder betyr flere stakker — tre containere hver, bak én omvendt proxy — eller Munin Cloud, som er flerleietakerbygget av den samme koden. Det ligger nært normen i kategorien: EspoCRM dokumenterer separate installasjoner per selskap, og Odoos svar er flerselskap inne i én database eller dbfilter på tvers av flere.

Hva forlater maskinen på en selvdriftet installasjon? Ingenting som standard. E-post, embeddinger og ressurslagring leveres alle som lokale stubber, så en fersk installasjon når intet tredjeparts-API. Fire innstillinger endrer det — en e-postleverandør, en embedding-nøkkel, S3-lagring og LLM-leverandøren for agentkjøreren — og hver av dem har et lokalt alternativ: llama.cpp eller vLLM for embeddinger, MinIO for ressurser, en lokal modell for kjøreren.

Trenger jeg en OpenAI-nøkkel for å kjøre det? Nei. Embeddinger faller tilbake på en deterministisk lokal stubbe, så søk virker ut av boksen. Sett OPENAI_BASE_URL til en lokal server — LM Studio, vLLM, llama.cpp — om du vil ha ekte vektorer uten at noe forlater verten.

Trenger den en egen arbeider- eller køcontainer? Nei. Agentkjøreren er i prosessen, per organisasjon, og jobbkøen dens er varig i den samme Postgres som alt annet, med ny-forsøk og håndtering av dødbrev. Det er hovedgrunnen til at stakken er tre containere framfor fem.

Er selvdriftet Munin det samme som Munin Cloud? Samme kode. Bygget med åpen kildekode setter sammen de delte modulene med enorganisasjons-auth; Cloud setter sammen de identiske modulene med flerleietaker-auth. Hele katalogen — 226 MCP-verktøy, mer enn 250 REST-endepunkter og 60 medfølgende ferdigheter — finnes i begge.

Er Munin virkelig MIT, eller er det open core? MIT, uten en enterprise-katalog i repositoriet og uten en funksjon holdt tilbake for et betalt nivå. Det er en bevisst forskjell fra det meste av denne kategorien, der merket på forsiden sier åpen kildekode og den nyttige halvparten bor under en separat lisens — iblant i en katalog, iblant i en lisensoverskrift på enkeltfiler, iblant i et repositorium du ikke kan se. Den fulle sammenlikningen lisens for lisens ligger her.

Hvilket container-image bør jeg pinne? Sjekk hvem som publiserer det. 28. august 2025 flyttet Bitnami sin eksisterende katalog til docker.io/bitnamilegacy, som ikke får flere oppdateringer eller sikkerhetsfikser, og for flere prosjekter i dette feltet var det det mest nedlastede imaget på Docker Hub. Foretrekk et image prosjektet selv bygger; finnes det ikke, vit hvem sitt bygg du stoler på.

Hvordan sikkerhetskopierer jeg en selvdriftet installasjon? En pg_dump av databasen og en kopi av ressursvolumet, på en tidsplan. Gjenopprett den så inn i en midlertidig database én gang og sjekk radantallene, fordi en ugjenopprettet sikkerhetskopi er en fil framfor en sikkerhetskopi.

Hvordan kobler jeg Claude eller Cursor til en selvdriftet instans? Sett NEXT_PUBLIC_MCP_URL til adressen klientene dine kan nå, og legg så den URL-en til i klienten. Munin annonserer den gjennom RFC 9728, og det første kallet utløser samtykkeskjermen i nettleseren din.

Kan jeg flytte til Munin Cloud senere, eller tilbake igjen? Ja, i begge retninger. Hver modul leverer symmetriske *_export- og *_import-verktøy over MCP, og den medfølgende ferdigheten playbooks/data-migration sekvenserer dem i fremmednøkkelrekkefølge, så avhengige poster finner foreldrene sine på målet.

Repositoriet ligger på GitHub under MIT, og vil du heller slippe å kjøre Postgres selv, er Munin Cloud Free den samme koden uten vakttelefonen.

Kjører det ikke på én maskin du eier, er det ikke selvdriftet. Da er det bare driftet.