Directus Hosting

Voor een nadere uitwerking van de hosting van Directus is het van belang welke functionaliteit gewenst is. Dat wil zeggen: kan strikt met een Directus Docker-container worden volstaan en wordt alle functionaliteit volledig binnen Directus opgelost? Onze ervaring is dat met Directus veel mogelijk is, maar dat het ook zijn beperkingen heeft. Als er meer functionele mogelijkheden gewenst zijn (importing, exporting, reporting, dashboards etc.), dan zullen er al snel aanvullende specifieke Docker-stacks worden ingericht met extra functionaliteit. Dit biedt veel mogelijkheden en alternatieven en kan een welkome aanvulling zijn op de Directus-stack. Daarmee doet dit overigens niets af aan de kracht van een Directusstack. Bij uitstek is dit krachtig op het gebied van een datamodelgedreven omgeving die multi-tenancy ondersteunt en veel communicatiemogelijkheden op basis van standaard api's biedt met de buitenwereld.

Als sprake is van een applicatie met veel interne en externe koppelingen waarbij bestanden (XML, XAS, JSON of CSV) geïmporteerd moeten worden of waarbij data opgehaald moet worden via diverse API's, wordt geadviseerd dit te realiseren met behulp van een afzonderlijke servicestack naast de Directus-stack. Een veelgebruikte hiervoor is een FastAPI-oplossing met een Python-stack. Deze is erg krachtig in het parsen van XML en JSON, het mappen van data van input naar output en het wegschrijven van deze data naar Directus met behulp van de Directus-API's. Deze stack draait bij voorkeur in een aparte Docker-container naast de Directus-Docker-stack. Hierbij wordt gebruikgemaakt van een gezamenlijke Docker-netwerkdefinitie zodat de Docker-containers betrouwbaar met elkaar kunnen communiceren. De servicestack heeft geen dataopslag en heeft puur een servicekarakter. De software op deze stack wordt via Github met behulp van een runner bijgewerkt bij updates, zodat het beheer van de servicestack eenvoudig is.

In veel gevallen bestaat ook de wens om rapportages vanuit Directus te kunnen draaien zowel naar het web als naar pdf. Directus zelf biedt daar geen kant-en-klare functionaliteit voor, behalve Insight. Hiermee kunnen eenvoudige dashboards in Directus worden gemaakt. Enerzijds kan gekozen worden om rapportages te realiseren binnen een aanvullende BI-omgeving , zoals Microsoft Power BI. Nadeel is dat deze rapportages alleen kunnen worden ontsloten via een zogenaamde Power BI-server, hetzij gehost in een Microsoft-cloudomgeving, hetzij met een eigen Power BI-server. Dit betekent weer aanvullende kosten.
In de opzet die wij hebben uitgewerkt, hebben we ervoor gekozen om de datapreparatie binnen de servicestack op te lossen. Oa het pivoteren van de data naar de gewenste structuur. De servicestack levert vervolgens een JSON-output op die wordt gerenderd op een JSReport-server. JSReport draait hiervoor in een derde afzonderlijke stack naast Directus en naast de Directus-service-stack. De JSRepoprtstack acteert ook binnen hetzelfde Docker-netwerk van Directus.

Twee scenario's:
👉 Scenario A: volledig managed/PaaS (zoals Railway)
👉 Scenario B: self-hosted met 2 NUC’s (prod + pure DR/failover, geen dev/test daarop)
We geven eerst de heldere conclusie, daarna de kosten (nu concreter) en dan de afweging die er écht toe doet.

🧠 Kort oordeel

• Railway → minder werk, hogere maandkosten, minder controle, sneller live
• 2x NUC self-hosted → meer werk, lagere kosten, maximale controle, betere DR-positie

👉 In de setup finance + reporting + beperkte users:

Self-hosted wint technisch en financieel,
Railway wint op gemak en snelheid.

💰 Railway kosten

Railway rekent grofweg op basis van:

• CPU / RAM usage per service
• database usage
• storage + egress
• uptime (geen echte “free idle” bij productie)

🔧 Een set van stacks op Railway

Je hebt minimaal:

1. Directus
2. PostgreSQL
3. Finance service(s)
4. JSReporting service
5. (optioneel Redis)

💸 Indicatie per stack

1. Directus

• ± 512MB – 1GB RAM
• lichte CPU

👉 €8 – €20 / maand

2. PostgreSQL

• managed via Railway

👉 €10 – €30 / maand
(afhankelijk van opslag + usage)

3. Finance services

• meestal licht tot medium

👉 €5 – €20 / maand

4. JSReporting ⚠️ (belangrijkste kostenfactor)

• CPU spikes
• memory usage
• rendering

👉 €15 – €50 / maand
(kan uitschieten bij intensief gebruik)

5. Redis (optioneel)

👉 €5 – €10 / maand

👉 Totaal Railway

👉 Belangrijk:

• kosten zijn variabel
• moeilijk 100% voorspelbaar
• pieken = direct hogere kosten

🧱 Self-hosted met 2 NUC’s (kosten)

Eenmalig

• 2x NUC: €400 – €800 per stuk
  👉 €800 – €1600 totaal

Maandelijks

• stroom: €10 – €25
• backup storage (EU): €5 – €15
• internet: meestal al aanwezig

👉 €15 – €40 / maand

👉 Vergelijking kosten over 1 jaar

👉 Vanaf jaar 2 wordt self-hosted significant goedkoper

⚖️ Architectuurvergelijking (jouw specifieke setup)

🚀 Railway

✅ Voordelen

• geen infra beheer
• snelle deploys
• schaalbaar zonder nadenken
• geen hardware risico

❌ Nadelen

• kosten groeien met usage
• JSReporting inefficiënt geprijsd
• minder controle over performance
• afhankelijk van platform
• DR = beperkt (tenzij multi-region zelf geregeld)

🖥️ 2x NUC (prod + uitwijk)

✅ Voordelen

• volledige controle
• stabiele performance
• JSReporting werkt beter (geen runtime limits)
• DR volledig in eigen hand
• kosten laag en voorspelbaar

❌ Nadelen

• beheer (updates, monitoring)
• hardware risico (maar jij vangt dat op met 2e locatie)
• failover moet je zelf organiseren

🔥 Belangrijk verschil: Disaster Recovery

Hier wint jouw NUC-opzet eigenlijk overtuigend.

Jouw setup:

• productie NUC
• tweede NUC = dedicated failover
• VPN via pfSense
• regelmatige backups + restore

👉 Resultaat:

• echte controle over RPO
• zelf te bepalen RTO
• geen afhankelijkheid van provider

Railway:

• geen native “2 regio’s actief” zonder extra complexiteit
• backups wel, maar:
• DR = afhankelijk van hun infra

👉 In praktijk:

• Railway = hosting
• jouw NUC setup = eigen mini-datacenter met DR

⚠️ Grootste verschil in de praktijk

Dit is waar de keuze écht over gaat:

Railway

“Ik wil dat het werkt zonder dat ik infra beheer.”

NUC setup

“Ik wil controle en lage kosten, en accepteer dat ik operator ben.”

🧠 Mijn advies voor jouw situatie

Gezien alles wat je eerder beschreef:

• finance stack
• JSReporting
• beperkte gebruikersgroep
• nadruk op controle
• al bereidheid tot infra (pfSense, VPN, backups)

👉 Dan zou ik dit adviseren:

✅ Ga voor 2x NUC self-hosted

Waarom:

• je setup past daar perfect bij
• je hebt al DR-denken ingebouwd
• je workloads zijn niet “cloud-native scaling dependent”
• je voorkomt variabele kosten
• je vermijdt PaaS-limitaties bij reporting

🧩 Wanneer zou ik Railway wél kiezen?

Alleen als:

• je geen zin hebt in beheer
• uptime minder kritisch is
• je snel wilt itereren
• je stack simpeler wordt (minder services)
• of je team geen infra-kennis heeft

🏁 Eindoordeel

👉 Voor jouw specifieke situatie:

NUC setup = rationeel de beste keuze
Railway = comfortabeler, maar duurder en minder controle