Directus zelf hosten in 2026: database, uploads en publieke URL

Behandel Directus als een klein systeem, niet als een Docker-image. Het gebruikersgerichte doel van Directus is duidelijk: een REST- en GraphQL-API plus een beheerinterface voor je data; de deployment is pas acceptabel wanneer je de beheerder kunt initialiseren, een collection en role kunt aanmaken, via REST kunt schrijven, via GraphQL kunt opvragen en een bestand kunt uploaden.

Dat onderscheid brengt de failure mode aan het licht die operators na lokaal testen tegenkomen: de databaseclient is onjuist of de uploadopslag is niet schrijfbaar. Het maakt het back-up- en upgradeplan bovendien specifiek genoeg om te testen.

Bewijs dat Directus vervanging overleeft

Een containerimage kan opnieuw worden gedownload; databases, uploads, extensions, flows en schemasnapshots niet. Mount /directus/database voordat je de bootstrap uitvoert, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Inspecteer de effectieve mount in plaats van op een Compose-bestandsnaam te vertrouwen, en controleer of de runtimegebruiker kan schrijven naar de locatie die Directus verwacht.

Kies een bewaarbeleid en een bestemming buiten de host en oefen het herstel zonder productie aan te raken. De oefening is alleen geslaagd wanneer schema, roles, flows, items, extensions en uploads terugkomen en zowel REST- als GraphQL-probes slagen. Combineer voor databasestate storage snapshots met application-consistente exports, zoals beschreven in point-in-time recovery versus snapshots.

De productieopzet van Directus

Trek drie grenzen rond Directus: ingress naar poort 8055, persistente state en ondersteunende vereisten. De container is vervangbaar, maar voor de andere twee zijn expliciete owners nodig. Het netwerkcontract voor Directus bestaat uit Postgres plus optioneel Redis en object storage voor deployments op schaal. Houd private endpoints op interne DNS, sta alleen vereiste uitgaande verbindingen toe en geef Directus een servicecredential met beperkte scope.

Het diagram is compleet wanneer een clean client de beheerder kan initialiseren, een collection en role kan aanmaken, via REST kan schrijven, via GraphQL kan opvragen en een bestand kan uploaden. Leg timing- en resourcegegevens vast voor de database connection pool, gelijktijdigheid van API-requests, Flow workers, thumbnailgeneratie en uploadopslag. Als de transactie mislukt, laat de eerste grens die zich niet gedraagt zoals gedocumenteerd zien of je routing, lokale capaciteit of een ondersteunende service moet onderzoeken.

Bewijs dat de Directus-deployment end-to-end werkt

Maak een kleine, wegwerpbare Directus-fixture en bewaar die voor elke release. De fixture moet de echte workflow uitvoeren: de beheerder initialiseren, een collection en role aanmaken, via REST schrijven, via GraphQL opvragen en een bestand uploaden. Noteer de image digest, externe hostname, het adres van de dependency en het verwachte resultaat, zodat een volgende operator de test kan herhalen zonder deze handleiding te hoeven interpreteren.

Voer de fixture drie keer uit. Gebruik eerst de verse deployment. Vervang vervolgens de container zonder de persistente state aan te raken. Herstel ten slotte de back-up in een lege omgeving. De derde run is alleen geslaagd wanneer schema, roles, flows, items, extensions en uploads terugkomen en zowel REST- als GraphQL-probes slagen. Leg tijdens elke run latency en resourcegebruik vast rond de database connection pool, gelijktijdigheid van API-requests, Flow workers, thumbnailgeneratie en uploadopslag; dit wordt de baseline voor alerts in plaats van een willekeurig CPU-percentage.

Test ten slotte bewust het negatieve pad: ontzeg de test identity tijdelijk de toegang tot Postgres plus optioneel Redis en object storage voor deployments op schaal. Bevestig dat Directus zichtbaar faalt zonder state te beschadigen, herstel de juiste situatie en herhaal de geslaagde transactie. Een releaserecord met die vier uitkomsten levert sterker bewijs dan screenshots van een dashboard of een eenmalige curl-respons.

Start Directus met observeerbare defaults

Start Directus zo dat de route private blijft totdat de bootstrap is voltooid.

docker run -d \
  --name directus \
  --restart unless-stopped \
  -p 127.0.0.1:8055:8055 \
  -v directus-data:/directus/database \
  -v directus-uploads:/directus/uploads \
  -v directus-extensions:/directus/extensions \
  -e SECRET=replace-with-a-long-random-value \
  -e KEY=replace-with-a-second-long-random-value \
  -e ADMIN_EMAIL=admin@example.com \
  -e ADMIN_PASSWORD=replace-with-a-strong-bootstrap-password \
  -e DB_CLIENT=sqlite3 \
  -e DB_FILENAME=/directus/database/data.db \
  -e PUBLIC_URL=https://app.example.com \
  directus/directus:latest

Als het proces blijft loopen, vergelijk je de verwachte user van de image met de owner van elk gemount pad. Als het proces actief blijft, test je lokaal poort 8055 en ga je vervolgens direct door naar de workflow: de beheerder initialiseren, een collection en role aanmaken, via REST schrijven, via GraphQL opvragen en een bestand uploaden. Pin de imageversie pas nadat deze end-to-endcontrole is geslaagd en leg de exacte configuratie naast de service vast.

Credentials, roles en exposed surfaces

Sluit het bootstrapvenster zodra de eerste vertrouwde beheerder bestaat. De concrete valkuil bij Directus is dat je het bootstrap-wachtwoord na de eerste login blijft gebruiken of SECRET blind roteert; de veiligere grens is bootstrapcredentials vervangen, least-privilege roles gebruiken en SECRET stabiel houden, omdat deze application sessions en tokens beschermt.

Genereer SECRET één keer, houd het buiten Git en bewaar het in het recovery manifest, omdat wijzigen ervan encrypted of signed application state ongeldig kan maken. Gebruik private networking voor dependencycredentials en laat roles binnen Directus de kleinst mogelijke nuttige actie toestaan. Houd gevoelige request bodies en responses van providers buiten routinematige logs.

Maak de publieke origin ondubbelzinnig

Vermijd tijdelijke en permanente publieke origins voor Directus. Stel in plaats daarvan PUBLIC_URL in op het canonieke HTTPS-adres, laat de gekozen DNS-naam naar de platformroute wijzen en proxy alleen naar poort 8055.

Voer deze actie van buiten de host uit: initialiseer de beheerder, maak een collection en role aan, schrijf via REST, vraag op via GraphQL en upload een bestand. Als ingress faalt, behandelt de 502 troubleshooting guide fouten met poorten en listeners. Als Directus de request ontvangt maar de databaseclient onjuist is of de uploadopslag niet schrijfbaar is, wijst het bewijs nu verder dan de proxy.

Failure drills voor Directus

Monitor voor Directus een transactie in plaats van een proces: de beheerder initialiseren, een collection en role aanmaken, via REST schrijven, via GraphQL opvragen en een bestand uploaden. Combineer de latency en error rate met de database connection pool, gelijktijdigheid van API-requests, Flow workers, thumbnailgeneratie en uploadopslag, zodat een alert de component identificeert die de beperking veroorzaakt.

De upgrade rehearsal moet omvatten dat je schema migrations, extensions en databasevendorsupport van Directus als één geheel controleert. Herstel, migreer en voer de transactie uit vóór je de productie vervangt. Als de databaseclient onjuist is of de uploadopslag niet schrijfbaar is, wis dan geen data om de startup groen te maken; vergelijk achtereenvolgens versie, variabelen, mounts en bereikbaarheid van dependencies.

Wat Dockup voor Directus moet automatiseren

De platformlaag voor Directus bestaat uit poort 8055, ingress, TLS, runtimeconfiguratie, opslag en bereikbaarheid van dependencies. Dockup kan deze onderdelen reproduceren voor de eigen infrastructuur of voor een server die de klant koppelt.

Daarna voltooit de operator de productlaag: stel PUBLIC_URL in op het canonieke HTTPS-adres; dwing deze toegangsregel af — vervang bootstrapcredentials, gebruik least-privilege roles en houd SECRET stabiel, omdat deze application sessions en tokens beschermt; en voer “de beheerder initialiseren, een collection en role aanmaken, via REST schrijven, via GraphQL opvragen en een bestand uploaden” uit. Door die test samen met de deployment vast te leggen, voorkom je dat geautomatiseerde provisioning wordt verward met application readiness.

Veelgestelde vragen

Wat heeft Directus nodig voor een productie-deployment?

Route de Directus-container op poort 8055 via één HTTPS-origin. De ondersteunende netwerkvereiste is Postgres plus optioneel Redis en object storage voor deployments op schaal. Beschouw Directus pas als klaar wanneer je de beheerder kunt initialiseren, een collection en role kunt aanmaken, via REST kunt schrijven, via GraphQL kunt opvragen en een bestand kunt uploaden.

Welke Directus-data hoort in een back-up?

Maak een back-up van /directus/database en neem database, uploads, extensions, flows en schemasnapshots op in hetzelfde recovery manifest. Een clean Directus-herstel is alleen geslaagd wanneer schema, roles, flows, items, extensions en uploads terugkomen en zowel REST- als GraphQL-probes slagen.

Heeft Directus HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Directus-origin en houd poort 8055 op de interne route. Pas de Directus-instelling correct toe: stel PUBLIC_URL in op het canonieke HTTPS-adres. Voor Directus beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het ervoor dat origin-sensitive clientgedrag consistent blijft.

Hoe moet een Directus-upgrade worden getest?

Herstel de huidige Directus-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat je schema migrations, extensions en databasevendorsupport van Directus als één geheel moet controleren. Houd de vorige Directus-image beschikbaar totdat de grenzen van datamigratie en rollback duidelijk zijn.