n8n eller Make: selvdrift sparer lisens, men flytter hele driftsjobben

Velg Make hvis teamet vil automatisere uten å drifte plattformen selv. Velg selvhostet n8n hvis kontroll over installasjonen og fleksibiliteten veier opp for arbeidet med oppdateringer, sikkerhetskopi og feilretting. n8ns prisoversikt viser at Community-utgaven kan selvhostes uten plattformabonnement, mens betalte planer prises etter arbeidsflytkjøringer, uavhengig av antall trinn.

Lisensbesparelsen gjelder altså når Community-utgaven dekker behovet. Den sier ingenting om hva det koster å holde installasjonen i gang. Make er en administrert skytjeneste der prisoversikten for Make beskriver kreditter som betalingsenhet: De fleste modulhandlinger bruker én kreditt, mens enkelte avanserte funksjoner bruker mer. Teamet slipper plattformdriften, men må følge med på forbruket.

Prislogikken: arbeidsflytkjøring eller modulhandling

Forskjellen i måleenhet får størst betydning når en automatisering har mange handlinger eller behandler flere elementer per kjøring. I en betalt n8n-plan teller kjøringen som en enhet selv om arbeidsflyten har mange trinn. I Make kan hver modul som faktisk utfører en handling, bruke kreditter. En ruter eller et filter er ikke i seg selv det samme som en kredittbelagt handling; det er modulene som kjøres etter forgreningen, som kan øke forbruket.

Et uttrykkelig hypotetisk eksempel viser hvorfor prisen ikke kan sammenlignes ut fra antall scenarioer alene: Hvis en flyt utløses 2000 ganger i måneden og hver gang utfører fem kredittbelagte Make-handlinger, blir anslaget 10 000 kreditter. En tilsvarende flyt ville telle som 2000 arbeidsflytkjøringer i en betalt n8n-plan. Resultatet kan endre seg hvis en Make-modul behandler flere elementer separat, eller hvis en KI-funksjon har variabelt kredittforbruk. Dette er et sammenligningsgrunnlag for måleenhetene, ikke et pristilbud.

For selvhostet Community-utgave er spørsmålet et annet. Der må teamet dimensjonere egen kapasitet etter belastningen og betale for ressursene som brukes, selv om en ekstra kjøring ikke gir en egen plattformavgift. Trinnrike flyter kan derfor gjøre Make dyrere i kreditter uten at det automatisk gjør selvhosting billigere totalt.

Datakontroll betyr ansvar for installasjonen

Med selvhosting velger virksomheten hvor n8n-instansen kjører, hvem som administrerer den, og hvordan lagrede tilgangsopplysninger og kjøringsdata håndteres. For et norsk team med krav til lagring og tilgang kan den kontrollen være avgjørende. Den gjelder likevel selve installasjonen: Når en arbeidsflyt sender innhold til en ekstern app eller KI-modell, må også den mottakerens behandling av data vurderes.

Kontrollen krever rutiner som virker når noe går galt. En driftsansvarlig må kunne oppdatere programvaren, begrense tilganger, overvåke feil og gjenopprette en brukbar sikkerhetskopi. n8ns sikkerhetsrevisjon kan blant annet avdekke ubrukte tilgangsopplysninger, risikable noder, ubeskyttede webhooks, manglende sikkerhetsinnstillinger og en utdatert instans. Funksjonen erstatter ikke en person som følger opp funnene eller en testet plan for gjenoppretting.

Make håndterer infrastrukturen for sin tjeneste. Virksomheten må fremdeles bestemme hvem som får bygge scenarioer, hvilke apper som kobles til, og hvilke opplysninger som sendes videre. Skillet er dermed konkret: Ved selvhosting har teamet også ansvar for at automatiseringsplattformen er tilgjengelig og oppdatert; i Make ligger den delen hos leverandøren.

Integrasjoner og KI krever ulike typer arbeid

Make er ofte det enklere valget for et forretningsteam som vil koble vanlige tjenester med ferdige moduler. n8n gir et teknisk team større rom for egne API-kall, kode og særskilt logikk, men det kan også bety mer arbeid når en kobling må bygges eller vedlikeholdes. Zapiers sammenligning beskriver Make som lettere tilgjengelig for forretningsteam og n8n som mer fleksibelt for utviklere, med oppsett, oppdateringer og skalering som ekstra ansvar ved selvhosting.

Antallet tilgjengelige integrasjoner er mindre nyttig enn dekningen av tjenestene teamet faktisk bruker. En ferdig modul kan forkorte arbeidet med en vanlig prosess, mens et API-kall kan gi tilgang til funksjoner som en standardmodul ikke dekker. Den friheten har en vedlikeholdskostnad: Når en ekstern tjeneste endrer API eller tilgangskrav, må noen eie rettingen uansett hvilken plattform som brukes.

For KI-flyter må plattformkostnaden skilles fra modellkostnaden. En arbeidsflyt kan hente data, sende dem til en modell og bruke svaret i en annen tjeneste. Makes forklaring av KI-kreditter skiller mellom egen modelltilkobling, der Make tar betalt for operasjoner og modellleverandøren for tokenbruk, og Makes KI-leverandør, der tokenbruk kan inngå i kredittforbruket. En n8n-flyt som bruker en ekstern modell, får på samme måte en modellregning ved siden av plattform- og driftskostnadene.

Regn med server, kopier og beredskap

En sammenligning av totalkostnad bør bruke samme forventede trafikk og samme periode på begge sider. For selvhostet n8n består månedsregnestykket av eventuell betalt n8n-plan, server og lagring, sikkerhetskopi, overvåking, arbeid med oppgraderinger og sikkerhet, samt beredskap og forventet feilretting. KI-modeller og betalte eksterne tjenester legges til separat. En gratis Community-utgave fjerner bare den første posten.

For Make er utgangspunktet abonnement, forventede kreditter og eventuelle ekstrakreditter. Legg til tiden det tar å bygge, endre og følge opp scenarioene, samt betaling til en egen KI-leverandør der det er aktuelt. Arbeid med forretningslogikken finnes i begge løsninger. Kostnadsforskjellen som lett overses, er tiden og ansvaret for infrastrukturen rundt en selvhostet instans.

Et hypotetisk månedsbudsjett gjør terskelen synlig: Sett server til 400 kroner, sikkerhetskopi til 200 kroner, tre driftstimer à 900 kroner og beredskap til 1200 kroner. Driftsdelen blir da 4500 kroner før feilretting, eventuell betalt n8n-plan og KI-bruk. Hvis Make-abonnementet og forventet kredittforbruk ligger under denne summen, gir bortfallet av plattformabonnementet alene ingen besparelse. Et team som allerede har driftspersonell og kapasitet, kan få et annet regnestykke.

Tre teamprofiler, tre ulike terskler

Et lite forretningsteam uten driftsansvarlig vil normalt ha mest nytte av Make. Teamet kan bygge og endre scenarioer uten å etablere rutiner for plattformoppdateringer og gjenoppretting. Før abonnement velges, bør forventet kredittforbruk beregnes ut fra handlingene i de konkrete scenarioene, særlig hvis de gjentas ofte eller behandler mange elementer.

Et teknisk team med etablert drift kan ha større utbytte av selvhostet n8n. Egen infrastruktur og kompetanse gjør driftsarbeidet lettere å ta inn i eksisterende rutiner, mens egne API-integrasjoner og sammensatte KI-flyter kan gi verdi av fleksibiliteten. Beslutningen avhenger fortsatt av faktisk kapasitet til oppdatering, overvåking og gjenoppretting når en viktig flyt stopper.

Et større team med krav til roller, støtte og styring må sammenligne konkrete betalte planer med den selvhostede Community-utgaven. Selvhosting betyr ikke at alle samarbeids- og styringsfunksjoner følger gratis med, og en administrert tjeneste fjerner ikke ansvaret for tilganger og datadeling. Her kan kravene til funksjoner og ansvar ved driftsstans veie tyngre enn prisen per kjøring eller kreditt.