SSD Nodes Learn 🎉 VPS vanaf $5.50/mnd
Gidsen Matt ConnorDoor Matt Connor · Bijgewerkt 2026-08-13

Beste zelfgehoste n8n alternatieven vergeleken

Vergelijk Activepieces, Windmill, Node-RED, Automatisch en Huginn met n8n. Wij analyseren licenties, RAM-gebruik, database-eisen en de backup-fout die restores blokkeert.

Alternatieven voor n8n

De zelfgehoste n8n-alternatieven die het overwegen waard zijn op een VPS (virtual private server) zijn Activepieces, Windmill, Node-RED, Automatisch en Huginn. Activepieces is de meest directe vervanger voor de manier waarop de meeste mensen n8n gebruiken, en de kern ervan is MIT-gelicentieerd. Windmill is geschikt voor een team dat liever Python of TypeScript schrijft dan blokken op een canvas te verslepen. Node-RED is de lichtgewicht optie en vereist helemaal geen database.

Veel gebruikers kunnen het beste blijven waar ze zijn. De n8n-licentie staat intern zakelijk gebruik toe, dus als u flows voor uw eigen bedrijf draait, vormt de licentie geen probleem. Migratie is bovendien niet gratis. Niets in deze lijst kan een n8n-export inlezen, dus u moet elke flow handmatig opnieuw opbouwen en alle inloggegevens opnieuw invoeren. Het installeren van n8n zelf is een afzonderlijke taak, die wordt behandeld in de n8n-installatie op een VPS met Docker en HTTPS, en n8n vergeleken met Zapier en Make behandelt hoe deze hele categorie zich verhoudt tot de gehoste diensten.

Waarom mensen zoeken naar zelfgehoste alternatieven voor n8n

Twee redenen komen steeds opnieuw naar voren.

De eerste is de licentie. n8n wordt uitgebracht onder de Sustainable Use License v1.0, die door het project 'fair-code' wordt genoemd in plaats van open source. De licentie verleent het recht om "de software uitsluitend te gebruiken of aan te passen voor uw eigen interne bedrijfsdoeleinden of voor niet-commercieel of persoonlijk gebruik", en het verbiedt het commercieel aanbieden van de software aan anderen. Bestanden en mappen met .ee in de naam vallen onder een afzonderlijke n8n Enterprise License. Als u automatiseringen wilt uitvoeren namens betalende klanten, vormt dit een harde grens. Als u een intern operatieteam bent, verandert er niets aan uw dagelijkse werkzaamheden.

De tweede is het geheugengebruik. n8n is een Node.js-proces en workflowdata verblijft in het geheugen terwijl de uitvoering plaatsvindt. De documentatie van n8n benoemt de oorzaken: de hoeveelheid JSON-data, de grootte van binaire data, het aantal nodes in een workflow, de Code node, handmatige uitvoeringen (die de data opnieuw kopiëren voor de editor) en andere workflows die tegelijkertijd draaien. De gedocumenteerde oplossing is niet een ander product. Het is de queue mode met afzonderlijke worker-processen, plus Postgres in plaats van het standaard SQLite-bestand op ~/.n8n/database.sqlite. Bij grote taken is batching ook gewenst, omdat een Loop Over Items node die een sub-workflow voedt, slechts één deel van de data tegelijk in het geheugen houdt. Probeer dat eerst voordat u zestig flows ergens anders opnieuw opbouwt.

Welke zelfgehoste n8n-alternatieven worden nog onderhouden

Licentieteksten zijn eenvoudig te lezen, dus iedereen vergelijkt licenties. De gezondheid van een project wordt echter vaak over het hoofd gezien. Dit zijn de 6 projecten in deze vergelijking, met de meest recente getagde release op 4 augustus 2026.

ChartNewest tagged release, checked 4 August 2026
The data behind this chart
[
  {
    "tool": "n8n",
    "licence": "Sustainable Use License",
    "latest_release": "2.33.3",
    "released": "2026-07-31",
    "days_since_release": 4
  },
  {
    "tool": "Activepieces",
    "licence": "MIT core, commercial ee",
    "latest_release": "0.86.3",
    "released": "2026-07-17",
    "days_since_release": 18
  },
  {
    "tool": "Windmill",
    "licence": "AGPLv3 source, CE image",
    "latest_release": "v1.778.0",
    "released": "2026-08-04",
    "days_since_release": 0
  },
  {
    "tool": "Node-RED",
    "licence": "Apache 2.0",
    "latest_release": "5.0.4",
    "released": "2026-07-30",
    "days_since_release": 5
  },
  {
    "tool": "Automatisch",
    "licence": "AGPL-3.0, commercial ee",
    "latest_release": "v0.15.0",
    "released": "2025-08-08",
    "days_since_release": 361
  },
  {
    "tool": "Huginn",
    "licence": "MIT",
    "latest_release": "v2022.08.18",
    "released": "2022-08-18",
    "days_since_release": 1447
  }
]

Twee rijen veranderen de shortlist. Automatisch had de laatste tag op v0.15.0, wat 361 dagen geleden is, en de standaard branch heeft sinds 15 januari 2026 geen commits meer ontvangen. Huginn had de laatste release 1447 dagen geleden, maar het commit-logboek is deze maand actief. Dat is het tegenovergestelde patroon: de code wordt bijgewerkt, maar er zijn geen releases. Het draaien van dit project betekent dus dat u een niet-getagde image gebruikt.

Controleer dit zelf voordat u een vergelijking vertrouwt, inclusief deze. Open de releases-pagina van het project op GitHub en bekijk vervolgens de lijst met commits voor de standaard branch. Een project met een recente release en een stil commit-logboek is aan het uitbollen. Een project met recente commits en al jaren geen release vraagt u om code te draaien waarvoor niemand een versie heeft vrijgegeven.

Activepieces: de meest vergelijkbare optie, met een MIT-kern

Activepieces is de meest directe keuze. Het is een visuele builder met triggers en stappen, die zij 'pieces' noemen; de README vermeldt er meer dan 280. Elke 'piece' wordt ook aangeboden als een MCP-server (model context protocol), waardoor een LLM-client (large language model) dezelfde connectoren als tools kan aanroepen. De kern is gelicentieerd onder de MIT-licentie. Twee mappen, packages/ee/ en packages/server/api/src/app/ee, vallen onder een commerciële licentie; voor het gebruik van de inhoud daarvan op uw eigen server is een betaalde overeenkomst vereist.

Bestudeer deze splitsing voordat u migreert, aangezien deze ingrijpender is dan bij de meeste MIT-projecten. De Activepieces-prijspagina beschrijft de Community Edition als "open source, voor altijd gratis, zonder limiet op runs, gebruikers of flows", en plaatst Agents en Chat, Projects, API-toegang en de volledige beheerlaag (single sign-on, gebruikersrollen, audit logs, secret managers, branding, Git sync) daarbuiten. De Community Edition is dus een volledige automatiseringsengine met onbeperkte flows en gebruikers, maar het is geen platform dat u via een API kunt aansturen. Als u van plan was om flows programmatisch te genereren, dan vereist dat plan een licentie.

De runtime-architectuur bestaat uit één app-container, een of meer worker-containers, Postgres en Redis. AP_DB_TYPE=POSTGRES en AP_REDIS_TYPE=STANDALONE zijn de standaardinstellingen. Er is een single-container-modus met een ingebedde database en een in-process queue (AP_DB_TYPE=PGLITE met AP_REDIS_TYPE=MEMORY), en de documentatie stelt dat deze "alleen bedoeld is voor persoonlijk gebruik of testen". Neem dat letterlijk. Deze modi kunnen niet meer dan één instantie draaien, dus het ontgroeien hiervan is een migratie, geen kwestie van een vlag aanpassen.

Windmill: code-first en zwaarder dan het lijkt

Windmill voert scripts uit in Python, TypeScript, Go, Bash en SQL en combineert deze vervolgens tot flows. Als uw automatiseringen grotendeels uit code bestaan met slechts een kleine hoeveelheid lijmwerk eromheen, sluit dit beter aan dan een node-gebaseerd canvas.

De licentie vereist aandacht. De broncode is AGPLv3 wanneer deze wordt gecompileerd zonder de enterprise-feature-flag. De images die op ghcr.io/windmill-labs/windmill worden gepubliceerd, zijn de Community Edition; deze bevatten code die niet open source is en gratis te gebruiken is binnen bepaalde quota. De prijspagina van Windmill stelt deze quota vast op 50 gebruikers, 3 workspaces en 10 GiB aan workspace-opslag, met een onbeperkt aantal uitvoeringen. Voor één persoon of een klein team ligt dat plafond ver weg, dus de praktische vraag is niet het quotum. Het punt is dat het binary dat u draait niet de AGPL-build is.

Het gewicht is de andere overweging. De eigen docker-compose.yml van Windmill levert een Postgres 16-database, één server, drie standaard workers met elk een geheugenlimiet van 2048M, een native worker en een Caddy-proxy. De gedocumenteerde vuistregel is "1 worker per 1vCPU en 1-2 GB RAM". U kunt het aantal replica's op een kleine server verlagen. U moet zich er echter van bewust zijn dat u dit doet, omdat de workers de daadwerkelijke taken uitvoeren.

De AI-functies van Windmill zijn gedocumenteerd als ondersteuning tijdens het bouwen: codegeneratie, het bouwen van flows, chat en het invullen van formulieren. Hiervoor moet u eerst een modelprovider-resource toevoegen in de workspace-instellingen. Als u een agent-stap wilt die volgens een schema draait en tools aanroept, is de AI Agent-node van n8n nog steeds de meest directe route, en het bouwen van een AI-agent in n8n behandelt die aanpak.

Node-RED: de compacte variant, zonder database

Node-RED valt onder de Apache 2.0-licentie, de meest toegankelijke licentie in deze vergelijking. Het is één Node.js-proces met een /data volume. Geen Postgres. Geen Redis. Pin de versie op nodered/node-red:5.0.4, de huidige release.

Het is voortgekomen uit IoT (internet of things)-bedrading, waardoor het meer event-gestuurd is dan gebaseerd op connectoren. Nodes voor externe diensten zijn afkomstig uit de community-bibliotheek en variëren in kwaliteit; dit is de afweging die u maakt voor de geringe omvang. Er is geen ingebouwde AI-agentstap. Voor een kleine VPS die webhooks en message-queue-verkeer afhandelt, is dit de lichtste optie in deze lijst die functioneert, en het start binnen enkele seconden op.

Huginn en Automatisch: controleer eerst het commit-logboek

Huginn is MIT-gelicentieerd, geschreven in Ruby on Rails en vereist MySQL of PostgreSQL. Het werkt met agents die een bron observeren en events genereren; dit is een ander model dan een flow-canvas en het bevat geen LLM-functionaliteit. De code ontvangt nog steeds commits, maar de laatste getagde release dateert uit augustus 2022. Het draaien van deze software betekent dus het gebruik van de ghcr.io/huginn/huginn-image die is gebouwd op basis van de default-branch. Kies voor deze optie wanneer het agent-model aansluit bij uw probleem, niet als een algemene vervanging voor n8n.

Automatisch is AGPL-3.0-gelicentieerd, met uitzondering van de .ee-bestanden, en oogt als een eenvoudigere variant van n8n: het gebruikt Postgres, Redis en een kleine catalogus aan applicaties. Het is de tool die in tutorials voor single-deployments vaak wordt aanbevolen. De releasegeschiedenis geeft aan dat u beter kunt wachten. Een jaar zonder release en een half jaar zonder commit is geen reden tot paniek als u het al gebruikt, maar het is wel een reden om er geen nieuwe productie-implementatie op te starten.

Wat een Activepieces-stack werkelijk aan RAM kost

Gemeten idle- en werkgeheugen is geen cijfer dat iemand voor u kan publiceren, omdat dit afhangt van uw eigen flows en de hoeveelheid data die zij verwerken. Wat u wel kunt lezen, is het budget dat elke leverancier adviseert. Activepieces documenteert de onderstaande vorm, en de zin daarnaast is belangrijker dan de getallen: "Een concurrency-1 worker is bezet gedurende de volledige duur van een flow (tot 10 min), dus baseer de grootte op gelijktijdige flows, niet op de trigger-frequentie."

ChartActivepieces published production sizing, per component
The data behind this chart
[
  {
    "label": "App container",
    "vcpu": 1,
    "ram_gb": 1
  },
  {
    "label": "Worker (each)",
    "vcpu": 0.5,
    "ram_gb": 1
  },
  {
    "label": "Postgres",
    "vcpu": 2,
    "ram_gb": 4
  },
  {
    "label": "Redis",
    "vcpu": 1,
    "ram_gb": 1
  }
]

Eén worker is 0.5 vCPU en 1 GB, en deze voert precies één flow tegelijk uit. Postgres wordt begroot op 4 GB. Het compose-bestand van het project zelf levert vijf worker-replica's, dus volgens die schatting vraagt de stack in de repository om ongeveer 11 GB voordat uw flows ook maar iets interessants doen. Tutorials voor losse tools kopiëren dat bestand en noemen het een kleine implementatie.

Draai op een 4 GB VPS twee workers, houd Postgres in hetzelfde compose-project en meet het zelf. docker stats --no-stream print per container één regel met het werkelijke resident geheugen, wat nauwkeuriger is dan elk cijfer dat door een leverancier of blog wordt gepubliceerd. Als een container zonder limiet groeit, stel dan een maximum in, en geheugenlimieten in Docker Compose toont de syntax.

Een compose-bestand voor Activepieces op één VPS

Pin de tag. latest betekent dat de volgende docker compose pull het databaseschema zonder waarschuwing kan wijzigen. Versie 0.86.3 is de versie die het project zelf in zijn compose-bestand vastzet per 4 augustus 2026.

Genereer eerst de twee secrets, waarbij u de lengtes aanhoudt die in de documentatie worden gespecificeerd.

openssl rand -hex 16    # AP_ENCRYPTION_KEY, encrypts stored connections
openssl rand -hex 32    # AP_JWT_SECRET, signs session tokens

Schrijf .env naast het compose-bestand:

AP_ENGINE_EXECUTABLE_PATH=dist/packages/engine/main.js
AP_ENVIRONMENT=prod
AP_FRONTEND_URL=https://automation.example.com
AP_ENCRYPTION_KEY=REPLACE_WITH_HEX_16
AP_JWT_SECRET=REPLACE_WITH_HEX_32
AP_DB_TYPE=POSTGRES
AP_POSTGRES_DATABASE=activepieces
AP_POSTGRES_HOST=postgres
AP_POSTGRES_PORT=5432
AP_POSTGRES_USERNAME=postgres
AP_POSTGRES_PASSWORD=REPLACE_WITH_A_LONG_RANDOM_PASSWORD
AP_REDIS_TYPE=STANDALONE
AP_REDIS_HOST=redis
AP_REDIS_PORT=6379
AP_EXECUTION_MODE=UNSANDBOXED
AP_TELEMETRY_ENABLED=false

AP_FRONTEND_URL moet het publieke HTTPS-adres zijn, omdat Activepieces anders probeert uw publieke IP-adres te gebruiken bij het opbouwen van webhook-URL's. Elke webhook die u aan een derde partij verstrekt, wordt op basis van die waarde gegenereerd; als deze nog naar localhost wijst, zal de URL die u in een andere service plakt uw server nooit bereiken.

services:
  app:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    ports:
      - '127.0.0.1:8080:80'
    depends_on:
      - postgres
      - redis
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=APP
    volumes:
      - ./cache:/usr/src/app/cache
  worker:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    depends_on:
      - app
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=WORKER
    deploy:
      replicas: 2
    volumes:
      - ./cache:/usr/src/app/cache
  postgres:
    image: pgvector/pgvector:0.8.0-pg14
    restart: unless-stopped
    env_file: .env
    environment:
      - POSTGRES_DB=${AP_POSTGRES_DATABASE}
      - POSTGRES_USER=${AP_POSTGRES_USERNAME}
      - POSTGRES_PASSWORD=${AP_POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
  redis:
    image: redis:7.0.7
    restart: unless-stopped
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

Dat bestand is het eigen compose-bestand van het project met vier wijzigingen: het aantal workers is verlaagd van vijf naar twee, de gepubliceerde poort is gebonden aan 127.0.0.1 in plaats van aan elke interface, de vaste containernamen zijn verwijderd omdat een service met replica's deze niet kan gebruiken, en het expliciete netwerkblok is verwijderd omdat compose er sowieso een aanmaakt.

docker compose up -d
docker compose ps

Elke service hoort Up te tonen, inclusief twee worker containers. Een container die in een lus herstart, print de reden in docker compose logs worker; lees deze dus voordat u wijzigingen aanbrengt. De poortbinding betekent dat er niets van buitenaf de app bereikt totdat u een reverse proxy met TLS (transport layer security) ervoor plaatst, wat wordt behandeld in Traefik draaien voor meerdere compose-apps. Houd .env op modus 600 en buiten git, zoals beschreven in omgaan met secrets in compose env-bestanden.

De back-up die in elke handleiding ontbreekt

Al deze tools versleutelen opgeslagen inloggegevens, dus een database-dump op zichzelf is geen back-up. U heeft zowel de dump als de sleutel nodig om deze te ontsleutelen. De valkuil is dat de meeste van deze tools die sleutel stilletjes voor u genereren en opslaan op een locatie die u niet meeneemt in uw back-up.

n8n is het duidelijkste voorbeeld. Als u N8N_ENCRYPTION_KEY niet instelt, "maakt n8n bij de eerste start automatisch een willekeurige encryptiesleutel aan en slaat deze op in de map ~/.n8n". Vervolgens gebruikt het deze sleutel om inloggegevens te versleutelen voordat ze de database bereiken. Als u Postgres dumpt en terugzet in een nieuwe container met een nieuw volume, komen de workflows wel terug, maar zijn alle inloggegevens onleesbare cijfertekst. Stel de variabele expliciet in en gebruik dezelfde waarde op elke worker wanneer u de queue-modus draait.

Node-RED werkt op dezelfde manier. Inloggegevens staan in een eigen versleuteld bestand en de sleutel is credentialSecret in settings.js. Wanneer u er geen instelt, genereert de runtime een willekeurige sleutel en slaat deze op onder _credentialSecret in de eigen instellingenopslag binnen /data. Het standaard instellingenbestand vermeldt de consequentie: "zodra u deze eigenschap instelt, mag u deze niet meer wijzigen - dit voorkomt dat node-red uw bestaande inloggegevens kan ontsleutelen en ze zullen verloren gaan." Maak een back-up van het volledige /data volume, niet alleen van het flows-bestand.

Activepieces bewaart AP_ENCRYPTION_KEY in uw .env, gedocumenteerd als een "32-karakter (16-byte) hexadecimale sleutel gebruikt voor het versleutelen van verbindingen". Huginn bewaart APP_SECRET_TOKEN in zijn omgeving. Automatisch heeft er drie: ENCRYPTION_KEY, WEBHOOK_SECRET_KEY en APP_SECRET_KEY. In elk geval bevindt het geheim zich in een omgevingsbestand, wat betekent dat het omgevingsbestand onderdeel is van de back-up.

Windmill is de uitzondering die het vermelden waard is. De variabelen en geheimen worden versleuteld met een werkruimte-specifieke symmetrische sleutel die Windmill in zijn eigen database opslaat, waardoor een enkele Postgres-dump beide helften bevat. Dat is handig voor herstelacties, maar het betekent ook dat de dump alleen voldoende is om elk geheim te lezen; bescherm het bestand dus alsof het de geheimen zelf zijn.

Voor de bovenstaande Activepieces-stack bestaat de back-up uit twee bestanden:

cd /srv/activepieces
docker compose exec -T postgres pg_dump -U postgres -Fc activepieces > "ap-$(date +%F).dump"
cp .env "ap-env-$(date +%F).bak"
chmod 600 ap-*.dump ap-env-*.bak

Controleer vervolgens of de back-up werkt, want een ongeteste back-up is slechts een aanname. Herstel de dump in een test-compose-project dat een bewust andere AP_ENCRYPTION_KEY gebruikt en voer vervolgens een flow uit die een opgeslagen verbinding gebruikt. Dit mislukt, omdat de cijfertekst in de database is geproduceerd met de andere sleutel. Herhaal het herstel met de juiste sleutel uit .env en dezelfde flow werkt wel. Die twee runs zijn het enige bewijs dat uw back-up daadwerkelijk een back-up is. Verplaats beide bestanden volgens een schema van de server af met restic backups vanaf een VPS, aangezien een back-up op dezelfde schijf verloren gaat zodra de schijf defect raakt.

Wanneer u bij n8n moet blijven

Blijf bij n8n als het werk intern is voor uw eigen bedrijf, aangezien dit precies is wat de Sustainable Use License toestaat. Blijf bij n8n als u afhankelijk bent van een breed aanbod, aangezien n8n meer dan 1500 integraties claimt, of vanwege de AI Agent-node gebaseerd op LangChain, waarvoor op dit gebied geen enkel ander alternatief kant-en-klare agent-stappen biedt. n8n-workflows aansturen met Claude laat zien hoe dat er in de praktijk uitziet.

Stap over naar Activepieces als u een permissieve licentie op de automatiseringskern wilt en een stack die u volledig kunt doorgronden. Stap over naar Windmill als uw flows in feite code zijn met een gebruikersinterface. Stap over naar Node-RED als de hardware beperkt is en het werk uit events bestaat. Stap niet over omdat een benchmark beweert dat n8n zwaar is. Meet eerst uw eigen instantie, lees daarna wat het waard is om zelf te hosten in 2026 en maak één keer een keuze, want de tweede migratie kost net zoveel als de eerste.

FAQ

Welk zelfgehost alternatief voor n8n lijkt het meest op n8n?

Activepieces. Het concept is identiek: een visuele builder waarbij een trigger een flow start en elke stap een service aanroept, ondersteund door een uitgebreide catalogus met connectoren. De kern is MIT-gelicentieerd, draait op Postgres en Redis via Docker, en de 'pieces' fungeren tevens als MCP-servers voor LLM-clients. Het aandachtspunt is dat API-toegang en de agent-functies zich in de commerciële enterprise-mappen bevinden; een Community Edition-instantie wordt daarom voornamelijk via de webinterface aangestuurd in plaats van programmatisch.

Is Activepieces echt open source?

De kern is open source onder de MIT-licentie. Twee mappen, packages/ee/ en packages/server/api/src/app/ee, zijn commercieel gelicentieerd; voor het gebruik van deze functies op uw eigen server is een betaalde licentie vereist. De prijsinformatie van de leverancier plaatst Agents en Chat, Projects, API-toegang, single sign-on, gebruikersrollen, audit logs, secret managers, branding en Git-synchronisatie buiten de Community Edition, terwijl het aantal runs, gebruikers en flows onbeperkt blijft. Het is dus oprecht open source voor het bouwen en uitvoeren van automatiseringen, maar niet voor de team- en beheerslaag.

Hoeveel RAM heeft Activepieces nodig op een VPS?

Activepieces adviseert 0,5 vCPU en 1 GB RAM per worker, 1 vCPU en 1 GB RAM voor de app-container, 4 GB voor Postgres en 1 GB voor Redis. Een worker verwerkt één flow tegelijk gedurende de volledige looptijd van die flow; u schaalt dus op basis van het aantal gelijktijdige flows in plaats van de triggerfrequentie. Het compose-bestand in de repository bevat standaard vijf workers, wat neerkomt op ongeveer 11 GB aan aanbevolen capaciteit. Twee workers op een VPS met 4 GB RAM is een redelijk startpunt, en docker stats --no-stream geeft inzicht in het werkelijke verbruik van uw flows tijdens uitvoering.

Wat moet ik back-uppen om een restore succesvol te laten verlopen?

De database-dump en de encryptiesleutel, in combinatie. Voor Activepieces betreft dit een pg_dump van de activepieces-database, aangevuld met het .env-bestand dat AP_ENCRYPTION_KEY bevat. Voor n8n is dit de database plus N8N_ENCRYPTION_KEY, die n8n voor u heeft gegenereerd in de ~/.n8n-map als u deze niet handmatig heeft ingesteld. Voor Node-RED back-upt u het volledige /data-volume, omdat zowel het bestand met inloggegevens als de sleutel voor de ontsleuteling zich daar bevinden. Windmill vormt de uitzondering: de workspace-sleutel bevindt zich in de eigen Postgres-database, waardoor de dump alle benodigde gegevens bevat en beveiligd moet worden alsof het de geheimen zelf zijn.

Kan ik mijn n8n-workflows importeren in een andere tool?

Nee. Deze projecten importeren en exporteren hun eigen flow-formaten, niet die van n8n. Een migratie betekent dat elke flow opnieuw moet worden opgebouwd in de nieuwe builder en dat elke credential opnieuw moet worden aangemaakt vanuit de oorspronkelijke service. Die werkzaamheden vormen de werkelijke kosten van een overstap; tel daarom uw flows voordat u een besluit neemt. Twaalf flows is een middag werk. Tweehonderd flows is een project, en het is doorgaans goedkoper om het geheugengebruik van n8n te optimaliseren met queue mode en Postgres dan om ze allemaal opnieuw op te bouwen.

#n8n#activepieces#windmill#workflows#self-hosting