Drifta hela grejen själv på en maskin.

Installationen är inte den svåra delen, och har inte varit det på åratal. Klona repot, kopiera exempel-env-filen, kör ett kommando, och tre containrar kommer upp på en värd. Det svåra är de fjorton dagarna efter: platshållarhemligheterna du aldrig bytte ut, e-postavsändaren som fortfarande är en stubbe, Postgres-rollen som avgör om row-level security överhuvudtaget gör något. Det här är rundan som täcker dem, i den ordning maskinen tvingar fram.

Kan du själv drifta ett CRM och en supportdesk på en maskin?

Ja. Munin driftas själv som tre containrar — Postgres med pgvector, en backend på port 3001, en dashboard på port 3000 — startade av ett enda docker compose up mot det MIT-licensierade repot. Det finns inget platsantal, inget kontakttak och ingen funktionsspärr. Det självdriftade bygget är samma kod som kör Munin Cloud, sammansatt med enorganisationsautentisering i stället för flerhyresgäst.

Den sista poängen är värd att dröja vid, för den är ovanlig i den här kategorin. Det finns ingen enterprise/- eller ee/-katalog i repot som håller tillbaka de delar du faktiskt vill ha. MIT täcker alltihop — kunskapsbas, konversationer, CRM, CMS, utgående kontakt, analys, kuratorkön, revisionsloggen, webhooks och hela MCP-verktygskatalogen.

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

Vilket är det bästa självdriftade CRM:et och den bästa supportdesken 2026?

Det finns ingen enskild vinnare, och det ärliga sättet att dela fältet är efter hur många rörliga delar du är villig att äga. FreeScout och EspoCRM är de lättaste — båda kör på helt vanlig PHP-hosting. Twenty är det snyggaste självdriftade CRM:et. SuiteCRM är det mest anpassningsbara för företagssäljprocesser. Chatwoot har bredast kanaltäckning. Zammad är det djupaste ärendesystemet. ERPNext är det mest kompletta gratis affärssystemet. Munin lägger CRM och supportdesk på en post från ett kommando.

Den inramningen betyder mer än ett funktionsrutnät, för på din egen hårdvara kostar funktionen du aldrig använder ingenting, och tjänsten du måste hålla vid liv kostar varje vecka. Zammad vill ha PostgreSQL, Redis, en Rails-app och — starkt rekommenderat, om du vill att sökningen ska vara bra — Elasticsearch, som för med sig heap-dimensionering och indexhantering. ERPNext kör Gunicorn, en arbetarpool, Node, MariaDB och tre separata Redis-instanser för cache, kö och socketio. SuiteCRM ligger i andra änden: en Apache- och PHP-applikation med ett cron-jobb och en MySQL eller MariaDB bakom sig, vilket är varför det fortfarande dyker upp på delad hosting två decennier senare. Alla tre är utmärkt mjukvara; två av dem ber dig drifta infrastruktur motsvarande ett litet plattformsteam.

Den andra axeln är licensen, och den sorterar inte som märkena antyder. Chatwoot är MIT i roten med en enterprise/-katalog under en separat kommersiell licens — SLA-hantering, revisionsloggar och egna dashboards bor i den, och produktionsanvändning av den mappen kräver en prenumeration. Twenty är AGPL-3.0 med enskilda filer märkta @license Enterprise. FreeScout är AGPL-3.0 med officiella moduler — Knowledge Base, Workflows, Customer Portal — sålda per licensnyckel. SuiteCRM, Zammad, ERPNext och Dolibarr håller inget tillbaka alls. Inget av det är oärligt; allt är normalt. Det betyder bara att det du kan drifta själv inte alltid är det du fick demonstrerat.

Kontrollerat på nytt mot varje projekts egen utrullnings- och licensdokumentation den 3 september 2026; SuiteCRM-raden lades till den 16 september 2026. Paketering rör sig; kontrollera repot innan du binder dig, inklusive vårt.

Vad startar docker compose up egentligen?

Tre tjänster och två namngivna volymer. Postgres 16 med vektortillägget, backenden och webbdashboarden. Ingen Redis, ingen separat köprocess, inget sökkluster — både kuratorns jobbkö och den hybrida fulltext- och pgvector-sökningen bor i samma Postgres som resten av datan.

Backend-containern kör node dist/migrate.js före node dist/main.js, så migreringar tillämpas vid varje uppstart. Postgres rapporterar friskt innan backenden får starta.

• PGpgvector/pgvector:pg16 på volymen munin-pg. Den enda tillståndsbärande tjänsten i stacken, och den enda du behöver en säkerhetskopieplan för.
• APIBackenden på :3001 — MCP över Streamable HTTP, OAuth 2.1 med dynamisk klientregistrering, och REST-kontrollplanet. Resurser landar på volymen munin-data.
• WEBDashboarden på :3000 — inloggning, API-nycklar, granskningsköer, anslutningskort. Inte där arbetet sker. Agenten är där arbetet sker.

Hur mycket RAM behöver ett självdriftat CRM?

Mellan 1 GB och 8 GB, helt beroende på hur många tjänster projektet tvingar dig att köra. FreeScout kör på den billigaste VPS en leverantör säljer. EspoCRM har det bekvämt på 1 GB. Munin vill ha ungefär 2 GB för Postgres plus två Node-processer. Twenty ber om minst 2 GB. Zammad rekommenderar minst 4 GB för containrarna, mer om Elasticsearch delar lådan. ERPNext börjar på 4 GB för en liten produktionsinstans och 8 GB vid 25 till 50 användare.

Felbeteendet är alltid detsamma och det är värt att namnge: för lite minne ger inte ett felmeddelande, det ger swap. En sida som tog 200 ms tar fyra sekunder, bakgrundsjobb stannar tyst, och du ägnar en lördag åt att vara övertygad om att applikationen är trasig. Köp nästa VPS-storlek upp. Det är det billigaste beslutet på den här sidan.

Disk är den enklare hälften — databasen, uppladdade resurser, och plats att hålla en dump medan du återställer den. Tjugo gigabyte är en vettig startpunkt för vilken som helst av dessa, och Postgres kommer säga till långt innan det spelar roll.

Vilka hemligheter måste jag sätta innan någon annan kan nå den?

Fyra: MUNIN_AUTH_SECRET, MUNIN_KEY_PEPPER, MUNIN_ENCRYPTION_KEY och MUNIN_STORAGE_LOCAL_SECRET. Lämnade på sina replace-me-*-platshållare genererar docker compose up starka värden vid första uppstart och sparar dem i volymen munin-data. Det är fint på en laptop. För något som delas, sätt dem själv så att de överlever en volym du bestämmer dig för att slänga.

Två till styr vem som slipper in överhuvudtaget. MUNIN_ALLOWED_EMAIL_DOMAINS är tom som standard, vilket betyder endast inbjudan: den första som registrerar sig blir administratör för den enda organisationen, och alla efter det behöver en inbjudningstoken. MUNIN_AUTH_TRUSTED_ORIGINS är som standard localhost:3000 (och 127.0.0.1:3000) och måste sättas till din verkliga dashboard-URL i produktion, annars faller inloggningen på CSRF-kontrollen.

# En rad var, vid 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

# Vem som kan nå den
MUNIN_ALLOWED_EMAIL_DOMAINS=acme.io
MUNIN_AUTH_TRUSTED_ORIGINS=https://munin.acme.io

# Vad den kallar sig, överallt där den måste namnge sig
NEXT_PUBLIC_MCP_URL=https://munin.acme.io/mcp
NEXT_PUBLIC_AUTH_URL=https://munin.acme.io
MUNIN_API_URL=https://munin.acme.io

Varför finns det två databas-URL:er?

För att Postgres-superanvändare kringgår row-level security, oavsett FORCE. MUNIN_MIGRATE_URL är den privilegierade anslutningen som kör CREATE EXTENSION, tillämpar DDL och skapar den begränsade rollen munin_app. DATABASE_URL är den applikationen faktiskt använder, och den pekar på munin_app.

Slår du ihop de två till en superanvändar-URL för att det går snabbare finns RLS-policyerna fortfarande där och kompilerar fortfarande — och de slutar gälla. Tenancy i Munin bärs av databasen snarare än av applikationskod som kontrollerar ett orgId på vägen förbi, så den genvägen är skillnaden mellan isolering du kan peka på och isolering du hoppas på.

Kan en självdriftad installation betjäna flera kunder eller företag?

En installation betjänar en organisation. Bygget med öppen källkod är enhyresgäst och endast inbjudan: den första som registrerar sig blir administratör för den organisationen, och alla efter det behöver en inbjudningstoken eller en tillåten e-postdomän. För flera kundorganisationer kör du en stack per kund, eller så använder du Munin Cloud, som är flerhyresgästbygget av samma kod.

En stack per kund är en lättare börda än det låter, för en stack här är tre containrar och en Postgres snarare än en plattform. Tio kunder är tio compose-filer bakom en omvänd proxy, var och en med sin egen volym, sin egen pg_dump, sitt eget uppgraderingsfönster och sin egen MCP-URL att ge den kundens agent. Det är också den isoleringsberättelse du vill kunna säga högt när en kund frågar var deras data finns: inte ett filter, en maskin. Gränsen inne i schemat gör sitt jobb oavsett — row-level security-policyerna ligger i migreringarna och applikationen ansluter som den begränsade rollen munin_app — och en separat utrullning lägger en separat skaderadie ovanpå det.

Värt att veta är att det är där hela kategorin står, snarare än där vi står ensamma. EspoCRM:s eget forum är tydligt med att flera företag inte stöds och att separata installationer är svaret. Odoo har två delvisa svar snarare än ett rent: flerföretag inne i en databas, där isoleringen bara är så bra som postreglerna, eller en Odoo-process som betjänar flera databaser genom dbfilter, där en hyresgästs långsamma fråga fortfarande är allas långsamma fråga. Över hela det här fältet blir ”en hyresgäst” oftast ”en utrullning” — vilket gör fotavtrycket per utrullning i tabellen ovan till den siffra som avgör vad tio kunder kostar dig. Byråversionen av den här frågan går igenom vad alternativet kostar när du skriver på den tionde.

• MUMunin — en organisation per installation, endast inbjudan. Flera kunder betyder flera stackar: tre containrar var, en omvänd proxy framför, en säkerhetskopia var. Munin Cloud är flerhyresgästbygget om du hellre slipper äga det.
• ESEspoCRM — separata installationer per företag. Flera instanser på en värd under separata underdomäner är mönstret dess community dokumenterar; kakor är värdbundna, så sessionerna hålls isär.
• ODOdoo — flerföretag inne i en databas, isolerat av postregler, eller en process över flera databaser via dbfilter. Två olika avvägningar, båda med gemensam feldomän.
• RLSVilket du än väljer, fråga var gränsen faktiskt tillämpas — i databasen, eller i applikationskod som måste komma ihåg. Det svaret överlever varje funktionslista.

Vad är fortfarande en stubbe efter första uppstarten?

Tre saker, med flit. Transaktionsmejl är en stubbe i minnet som standard, embeddingar är en deterministisk lokal stubbe som standard, och resurslagring är lokal disk som standard. Inget i en färsk installation når ett tredjeparts-API, vilket betyder att du kan utvärdera hela plattformen på en laptop utan att skapa ett enda leverantörskonto först.

Var och en är ett par rader när du vill ha den riktiga varan.

• TransaktionsmejlMUNIN_MAIL_PROVIDER=stub tills du sätter den till resend och anger RESEND_API_KEY. Verifierings-, återställnings- och inbjudningslänkar byggs mot MUNIN_WEB_URL, så sätt den till din verkliga dashboardvärd samtidigt.
• EmbeddingarEn deterministisk stubbe tills OPENAI_API_KEY är satt. OPENAI_BASE_URL pekar mot vad som helst OpenAI-kompatibelt — LM Studio, vLLM eller llama.cpp på samma låda om du vill att vektorerna ska stanna i byggnaden, eller en driftad EU-leverantör om du inte vill det.
• VektordimensionMUNIN_EMBEDDING_DIMENSIONS är 1536 som standard och matchar de medföljande migreringarna. Det finns ingen levande ALTER-väg för den i migreringarna med öppen källkod, så välj embeddingmodell innan du laddar in dokument snarare än efteråt.
• Resurslagringlocal skriver till /var/munin/assets på volymen munin-data och serverar genom backenden. Växla MUNIN_STORAGE_PROVIDER till s3 för vilken S3-kompatibel tjänst som helst — Scaleway, R2, MinIO, AWS — via SigV4-försignerade URL:er.

Vad lämnar faktiskt maskinen?

Inget, tills du bestämmer att det ska. En färsk installation når inget tredjeparts-API alls: mejl är en stubbe i minnet, embeddingar är en deterministisk lokal stubbe, och resurser skrivs till en lokal volym. Sök fungerar, dashboarden fungerar, MCP-ändpunkten fungerar, och det finns inget leverantörskonto någonstans i uppsättningen. Det är det bokstavliga svaret på ”privat CRM” — inte en policysida, en standardinställning.

Fyra strömbrytare ändrar det, och de är värda att skriva ner som en lista, för den listan är ditt dataflödesdiagram och det är det en revisor ber om. Att sätta MUNIN_MAIL_PROVIDER=resend skickar mottagaradresser och meddelandetexter till Resend. Att sätta OPENAI_API_KEY skickar dokument- och meddelandetext till en embeddingleverantör — eller rikta OPENAI_BASE_URL mot LM Studio, vLLM eller llama.cpp på samma låda och vektorerna lämnar aldrig byggnaden. Att växla MUNIN_STORAGE_PROVIDER till s3 skickar resurser till den bucket du namnger, som kan vara MinIO på samma värd. Och LLM-leverantören du konfigurerar för den inbyggda agentköraren är den fjärde.

Allt annat stannar där du lade det. Legitimationer för de leverantörerna — API-nycklar, IMAP- och SMTP-lösenord — krypteras i vila genom pgcrypto med MUNIN_ENCRYPTION_KEY, så anslutningssträngarna i din databas inte är läsbara för någon som får tag i en dump av den. Är ditt skäl att drifta själv en jurisdiktion snarare än en faktura har residensargumentet sin egen text, och kortversionen är att på din egen hårdvara är underbiträdeslistan vad de fyra strömbrytarna säger.

Hur riktar jag Claude, Cursor eller ChatGPT mot en självdriftad installation?

Mot en URL: NEXT_PUBLIC_MCP_URL. Det värdet är vad Munin annonserar genom RFC 9728 protected-resource-metadata, vad dashboardens anslutningsutdrag visar, och vad varje MCP-klient får. Sätt den en gång till adressen klienterna faktiskt når, så gör OAuth-flödet resten.

Formen för lokal utveckling är http://localhost:3001/mcp. Produktionsformen är ditt eget värdnamn bakom TLS. Inget annat i klientkonfigurationen ändras — det här är samma koppling som att köra ditt CRM från Claude Code mot Cloud, med värdnamnet utbytt.

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

# Bläddra i verktygsytan interaktivt
npx @modelcontextprotocol/inspector
# URL = http://localhost:3001/mcp   Auth = Bearer mn_admin_...

# Kontrollera transporten för hand
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"}'

Behöver en självdriftad installation en extern AI-tjänst för att besvara något?

Den behöver en LLM-leverantör du väljer, och inget annat. Munin levererar sin egen agentkörare i processen — per organisation, inne i backenden, ingen extra container — som besvarar levande konversationer på varje kanal och arbetar en beständig bakgrundskö: kunskapsbaskurering, CRM-hygien, kontaktextraktion från stängda trådar, utgående utkast. Externa MCP-klienter är valfria snarare än nödvändiga.

Det här är den del som överraskar folk som rullat ut resten av det här fältet, där ”och nu kör du arbetaren” är fjärde punkten i varje installationsguide. Det finns ingen arbetarcontainer här och ingen Redis att mäkla kön; jobbkön är hållbar i samma Postgres som datan bor i, med omförsök och hantering av döda brev, vilket är det mesta av varför containerantalet är tre. Rikta OPENAI_BASE_URL mot en lokal server och hela slingan — svara, skriva utkast, kurera — kör utan att ett paket lämnar värden.

Granskningshållningen lossnar inte för att köraren är lokal. Utgående kontakt är föreslå-bara var den än kör: varje meddelande väntar i en kö på en människa, och mottagare hämtas bara från kontakter med registrerat samtycke. Vi skrev upp varför den kön är den intressanta delen snarare än skrivandet.

Hur säkerhetskopierar jag ett självdriftat CRM?

En databas och en resursvolym, på schema, återställda någon annanstans minst en gång. För Munin är det en pg_dump av volymen munin-pg och en kopia av munin-data; varje annat projekt på den här sidan är samma två objekt med andra namn. Det finns ingen hanterad säkerhetskopieringstjänst i något självdriftat bygge, inklusive vårt. Det jobbet är ditt.

Delen folk hoppar över är återställningen. En säkerhetskopia du aldrig återställt är en fil, inte en säkerhetskopia, och felet upptäcks alltid på den värsta tänkbara morgonen. Återställ in i en tillfällig container en gång, bekräfta radantalen, och lägg en påminnelse i kalendern om ett halvår.

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

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

# Återställ in i en tillfällig databas och räkna raderna
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

Vad går sönder när du uppgraderar?

Oftast inget, och undantaget är alltid Postgres. Munin tillämpar sina egna migreringar vid varje uppstart, så att hämta en ny avbild och starta om är hela uppgraderingsvägen för applikationen. En huvudversionsändring i Postgres är något annat: datakatalogens format ändras, containern vägrar starta mot den gamla volymen, och du behöver en dump-och-ladda-om. Det gäller varje projekt här som levererar en databascontainer, vilket är de flesta av dem.

Två vanor gör det här odramatiskt. Lås avbildstaggarna i stället för att följa latest, så att en omstart klockan två på natten inte också är en versionsuppgradering. Och ta dumpen ovan omedelbart före varje uppgradering, inte på det vanliga schemat — de fem minuter det kostar är skillnaden mellan en återrullning och en incident.

Vad kostar egen drift som Munin Cloud inte gör?

Driftarbete som inte har med kunder att göra. Säkerhetskopior av volymen munin-pg, TLS-terminering framför port 3001, uppgraderingar på ditt eget schema, och den som svarar när Postgres fyller disken klockan tre på natten. Munin levererar ingen hanterad säkerhetskopieringstjänst; det jobbet är ditt, och det är ett riktigt jobb.

Vad du får för det är den version av ägande som överlever en prissida. Inga tak på kontakter, anrop eller lagring, för det finns ingen mätare i koden att tillämpa dem med. Datalagring där du ställer maskinen, bestämd av dig snarare än av en underbiträdeslista. Och en revisionslogg, en granskningskö och 226 MCP-verktyg som beter sig identiskt med det driftade bygget, för det är samma bygge. Varje modul levererar också symmetriska export- och importverktyg, så att flytta mellan din hårdvara och Cloud är en skriptad operation i båda riktningar snarare än en förhandling — vilket är hela poängen med licensen.

Hur jämförs fotavtrycket med Chatwoot, Zammad eller EspoCRM?

Alla kör på en värd. Skillnaden är hur många tjänster du håller vid liv och hur mycket av kunden var och en rymmer.

Chatwoot är den mest kompletta självdriftade inkorgen i fältet, och det är inte jämnt på kanalbredd: WhatsApp, Instagram, Facebook och Telegram har alla förstklassiga inkorgar. Bor din support redan på WhatsApp, installera Chatwoot — Munins fyra kanaler är e-post, chattwidget, SMS och röst, och det är den köparen Chatwoot bör vinna. Dess utrullning lägger till en Rails-webbprocess, en Sidekiq-arbetare, Postgres och Redis, och dess enterprise/-katalog ligger under en separat kommersiell licens.

Zammad är den djupaste ärendemotorn här och håller inget tillbaka under AGPL-3.0. Den vill också ha Elasticsearch bredvid Postgres och Redis för en sökning värd namnet, vilket är en fjärde tjänst med sin egen minnesprofil och sina egna åsikter.

EspoCRM är den lättaste av de tre och den mest konventionella — ett moget CRM som kör på en 1 GB-låda, med en jobbdemon, en valfri WebSocket-server och MariaDB bredvid. Det är AGPL-3.0 med en kommersiell licens såld separat, och dess Advanced Pack är ett betalt tillägg licensierat per installation.

Munin är tre containrar för att det finns ett datalager och en kund under alla sex moduler. En supporttråd, en affär, en kunskapsartikel, ett publicerat inlägg och ett utgående utkast som rör samma person är rader som redan vet om varandra — inget synkjobb, ingen avstämning, inget andra källsystem som tyst är oense med det första. Det är vad som gör verktygsytan värd att rikta en agent mot: agenten läser en konversation och uppdaterar en kontakt och citerar ett dokument i en session, för det finns inget mellan de tre sakerna. Vill du ha den fylligare rangordningen på endera sidan har vi skrivit båda — fältet för CRM med öppen källkod och fältet för supportdeskar med öppen källkod, med licenserna lästa ordentligt i båda.

Kan du drifta ett CRM själv gratis?

Licensen, ja. Maskinen, nej. Varje projekt i tabellen ovan kostar inget att installera, och Munin, Zammad, ERPNext och Dolibarr håller inget tillbaka bakom en betald nivå alls. Vad du betalar i stället är en VPS — realistiskt 5 till 20 € i månaden för en av dessa — plus timmarna ingen för in i kalkylbladet.

En analys från Open Source Alternatives kostnadsberäknade ett självdriftat CRM till ungefär 4 500 till 10 800 dollar över tre år, det mesta av det ingenjörstid till 100 dollar i timmen och två till fem timmars underhåll i månaden, mot 86 000 till 132 000 dollar för Salesforce Enterprise i samma fönster. Behandla båda som vägledande snarare än som offerter. Gapet är fortfarande skälet till att hela den här kategorin finns, och jämförelsen licens för licens är där den gratis hälften blir ordentligt läst.

Den ärliga versionen av avvägningen: egen drift gör om en prenumeration till ett ansvar. Är någon i ditt team glad över att äga en Postgres är det en bra affär, och mjukvaran är genuint gratis. Är ingen det är en driftad plan billigare än avbrottet.

Vem bör drifta själv, och vem bör inte?

Drifta själv om du har en datalagringsskyldighet som namnger en jurisdiktion eller en maskin, om du redan kör Postgres för något annat och jourlistan finns, eller om du tänker ändra koden — MIT betyder att du kan forka den, leverera den och aldrig berätta för oss.

Drifta inte själv om du är en person. Säkerhetskopior, uppgraderingar och samtalet klockan tre på natten är ett andra jobb, och en grundare har redan ett. Cloud Free kostar 0 € i månaden med alla sex moduler och alla fyra kanaler upplåsta, med tak på 5 000 MCP-anrop, 250 kontakter och 100 MB — nog för att på en eftermiddag ta reda på om formen passar dig, på exakt koden i den här artikeln. Flytta till din egen maskin senare om du vill; exportverktygen finns i repot, och de fungerar åt båda hållen.

Vanliga frågor

Vilket är det bästa självdriftade CRM:et? För en säljpipeline, Twenty. För djup anpassning av en företagssäljprocess, SuiteCRM. För bredd utan något spärrat, Dolibarr eller ERPNext. För den lättast möjliga lådan, EspoCRM. För CRM och supportdesk på en kundpost under en tillåtande licens, Munin — tre containrar, MIT hela vägen, ett docker compose up. Ditt verkliga urvalskriterium är vilket du fortfarande kommer att patcha om sex månader.

Vilken är den bästa självdriftade supportdesken? Chatwoot om du behöver WhatsApp-, Instagram- och Telegram-inkorgar. Zammad om du behöver det djupaste ärende- och arbetsflödessystemet och kan drifta Elasticsearch. FreeScout om du vill ha en delad brevlåda på billig PHP-hosting. Munin om supporttråden och CRM-posten bör vara samma kund snarare än två system som synkar.

Vilka är systemkraven för att drifta Munin själv? En Linux-värd med Docker och Docker Compose, omkring 2 GB RAM, och tillräckligt med disk för Postgres och dina CMS-resurser — 20 GB är en vettig start. Stacken är tre containrar, utan Redis, kömäklare eller sökkluster att förse bredvid.

Hur mycket RAM behöver ett självdriftat CRM? Ett till åtta gigabyte, bestämt av hur många tjänster projektet kör snarare än av hur många kontakter du har. EspoCRM, SuiteCRM och FreeScout är nöjda på 1 GB. Munin vill ha omkring 2 GB. Twenty ber om minst 2 GB. Zammad rekommenderar minst 4 GB, mer om Elasticsearch delar värden. ERPNext börjar på 4 GB och vill ha 8 GB vid 25 till 50 användare.

Kan en självdriftad installation betjäna flera kunder? En installation betjänar en organisation. Bygget med öppen källkod är enhyresgäst och endast inbjudan, så flera kunder betyder flera stackar — tre containrar var, bakom en omvänd proxy — eller Munin Cloud, som är flerhyresgästbygget av samma kod. Det ligger nära kategorins norm: EspoCRM dokumenterar separata installationer per företag, och Odoos svar är flerföretag inne i en databas eller dbfilter över flera.

Vad lämnar maskinen på en självdriftad installation? Inget som standard. Mejl, embeddingar och resurslagring levereras alla som lokala stubbar, så en färsk installation når inget tredjeparts-API. Fyra inställningar ändrar det — en mejlleverantör, en embeddingnyckel, S3-lagring och LLM-leverantören för agentköraren — och var och en har ett lokalt alternativ: llama.cpp eller vLLM för embeddingar, MinIO för resurser, en lokal modell för köraren.

Behöver jag en OpenAI-nyckel för att köra det? Nej. Embeddingar faller tillbaka på en deterministisk lokal stubbe, så sök fungerar direkt. Sätt OPENAI_BASE_URL till en lokal server — LM Studio, vLLM, llama.cpp — om du vill ha riktiga vektorer utan att något lämnar värden.

Behöver den en separat arbetar- eller köcontainer? Nej. Agentköraren är i processen, per organisation, och dess jobbkö är hållbar i samma Postgres som allt annat, med omförsök och hantering av döda brev. Det är huvudskälet till att stacken är tre containrar snarare än fem.

Är självdriftad Munin samma sak som Munin Cloud? Samma kod. Bygget med öppen källkod sätter samman de delade modulerna med enorganisationsautentisering; Cloud sätter samman de identiska modulerna med flerhyresgästautentisering. Hela katalogen — 226 MCP-verktyg, mer än 250 REST-ändpunkter och 60 medföljande färdigheter — finns i båda.

Är Munin verkligen MIT, eller är det open core? MIT, utan en enterprise-katalog i repot och utan en funktion hållen tillbaka för en betald nivå. Det är en medveten skillnad från det mesta av den här kategorin, där märket på förstasidan säger öppen källkod och den användbara hälften bor under en separat licens — ibland i en katalog, ibland i en licensrubrik på enskilda filer, ibland i ett repo du inte kan se. Den fullständiga jämförelsen licens för licens finns här.

Vilken containeravbild bör jag låsa? Kontrollera vem som publicerar den. Den 28 augusti 2025 flyttade Bitnami sin befintliga katalog till docker.io/bitnamilegacy, som inte får fler uppdateringar eller säkerhetsrättningar, och för flera projekt i det här fältet var det den mest hämtade avbilden på Docker Hub. Föredra en avbild projektet självt bygger; finns ingen, vet vems bygge du litar på.

Hur säkerhetskopierar jag en självdriftad installation? En pg_dump av databasen och en kopia av resursvolymen, på schema. Återställ den sedan in i en tillfällig databas en gång och kontrollera radantalen, för en oåterställd säkerhetskopia är en fil snarare än en säkerhetskopia.

Hur ansluter jag Claude eller Cursor till en självdriftad instans? Sätt NEXT_PUBLIC_MCP_URL till adressen dina klienter når, och lägg sedan till den URL:en i klienten. Munin annonserar den genom RFC 9728, och det första anropet utlöser samtyckesskärmen i din webbläsare.

Kan jag flytta till Munin Cloud senare, eller tillbaka igen? Ja, åt båda hållen. Varje modul levererar symmetriska *_export- och *_import-verktyg över MCP, och den medföljande färdigheten playbooks/data-migration sekvenserar dem i främmandenyckelordning så att beroende poster hittar sina föräldrar på målet.

Repot finns på GitHub under MIT, och vill du hellre slippa köra Postgres själv är Munin Cloud Free samma kod utan jouren.

Kör det inte på en maskin du äger är det inte självdriftat. Då är det bara driftat.