Waarom je n8n-workflows waarschijnlijk op een risicovolle manier draaien
Je hebt n8n opgezet, een paar workflows gebouwd en alles lijkt te functioneren. Tot het moment dat een server crasht, een backup leeg blijkt of een workflow faalt zonder dat je het merkt. Pas dan blijkt dat ‘het draait’ niet hetzelfde is als ‘het draait betrouwbaar’.
Voor de meeste kleine bedrijven die n8n gebruiken om systemen te koppelen, is de uitdaging niet of het platform zelf goed presteert. Dat doet het. De vraag is of de onderliggende infrastructuur stabiel genoeg is om er klanten of processen op te laten vertrouwen.
Vijf veelgemaakte fouten die je setup kwetsbaar maken
n8n is een open-source automatiseringstool waarmee je systemen aan elkaar knoopt: van webwinkel naar boekhouding, van CRM naar e-mailmarketing, van formulier naar database. Als je de standaardinstallatie zomaar overneemt, loop je tegen deze problemen aan:
SQLite in productie
SQLite is een lichte database die prima presteert voor ontwikkeling. Niet bedoeld voor een omgeving waar meerdere processen tegelijk schrijven of waar betrouwbaarheid cruciaal is. Zodra je workflows parallel draaien of meerdere containers opstarten, krijg je locking-problemen. Een betere keuze: PostgreSQL, dat wél concurrent schrijven aankan en makkelijker te backuppen is.
Geen echte backupstrategie
Veel bedrijven denken dat ze backups hebben omdat hun hostingpartij dagelijks snapshots maakt. Maar heb je die backups ooit teruggezet? Weet je of je credentials en configuratiebestanden wel mee worden gearchiveerd? n8n schrijft naar schijf: niet alleen databasegegevens, maar ook bestanden met inloggegevens en instellingen. Als je dat niet bewust backupt, ben je kwetsbaar.
Geen foutmonitoring
Een workflow faalt. Je merkt het pas dagen later omdat een klant belt. Zonder error monitoring weet je niet wanneer iets misgaat, hoeveel workflows het betreft of welke systemen geraakt zijn. Je hebt een manier nodig om alerts te krijgen zodra iets vastloopt. Dat kan Sentry zijn, een Slack-webhook of een eenvoudige logging-service.
Workflows staan alleen in de database
Als je workflows alleen in de database staan en je verliest die database, ben je alles kwijt. Exporteer workflows regelmatig als JSON of gebruik version control (Git) om wijzigingen bij te houden. Dan kun je snel herstellen na een crash en zie je ook wie wat wanneer heeft aangepast.
Te veel afhankelijkheden van externe diensten
Als je workflow afhankelijk is van één externe API en die service valt uit, staat je hele proces stil. Bouw waar mogelijk fallbacks in: een tweede leverancier, een tijdelijke cache, of een herstart-mechanisme dat het over een minuut opnieuw probeert.
Voor wie is dit relevant
Deze adviezen zijn bedoeld voor bedrijven die n8n al in gebruik hebben of overwegen het in productie te zetten, zonder een eigen DevOps-team. Je hebt basiskennis van Docker en docker-compose, je kunt een VPS opzetten, maar je bent geen infrastructuurspecialist.
Ben je nog helemaal nieuw in serverbeheer of heb je geen tijd om een VPS te onderhouden? Dan is n8n Cloud waarschijnlijk een betere keuze: dat platform handelt de infrastructuur af, zorgt voor backups en houdt alles draaiende. Voor één vast bedrag per maand zit je veilig, zonder je zorgen te maken over databases, monitoring of updates.
Draai je daarentegen al Kubernetes-clusters met distributed workers en queue mode? Dan ken je deze concepten waarschijnlijk al en heb je dit artikel niet nodig.
Wat je wél kunt doen: een simpele, stabiele setup
De meeste bedrijven hebben geen complexe infrastructuur nodig. Eén VPS met PostgreSQL, een dagelijkse backup naar objectopslag en een monitoring-tool leveren al een betrouwbaar systeem op. Schaalt het niet meer? Upgrade je VPS naar een snellere variant met meer geheugen. Verticaal schalen is eenvoudiger dan horizontaal.
Wil je echt horizontaal schalen met meerdere servers? Dan kom je bij queue mode, load balancers en gedeelde bestandssystemen. Dat kan. Voor de meeste gebruikers is het overkill. Eén goede server brengt je ver genoeg.
Een concreet stappenplan voor deze week
Wil je je setup robuuster maken? Begin hier:
- Schakel over van SQLite naar PostgreSQL. Dat is één omgevingsvariabele in je docker-compose.yml.
- Zet een dagelijkse cronjob op die je PostgreSQL-database dumpt en naar een externe locatie kopieert: Backblaze B2, AWS S3, of een simpele SFTP-server.
- Voeg een monitoring-tool toe die je een melding stuurt zodra een workflow faalt. Dat kan zo simpel zijn als een webhook naar Slack of Discord.
- Exporteer je workflows naar JSON en leg ze in een Git-repository. Doe dit één keer handmatig, zodat je weet dat je het terug kunt zetten.
- Test of je backup terugzetten lukt. Draai een verse instantie op, importeer je laatste backup en kijk of je credentials en workflows terugkomen.
Geen van deze stappen kost meer dan een paar uur. Samen maken ze het verschil tussen een setup die vandaag functioneert en een setup die blijft functioneren.
