Sådan selvhoster du Directus i 2026: Database, uploads og offentlig URL

Betragt Directus som et lille system, ikke som et Docker-image. Målet for brugerne af Directus er klart: en REST- og GraphQL-API samt en admin-grænseflade til dine data. Deploymentet er kun acceptabelt, når du kan bootstrappe administratoren, oprette en collection og en rolle, skrive via REST, forespørge via GraphQL og uploade en fil.

Denne skelnen afslører den fejltilstand, operatører møder efter lokal test: Databaseklienten er forkert, eller upload-storage kan ikke skrives til. Den gør også planen for backup og opgradering tilstrækkeligt specifik til, at den kan testes.

Dokumentér, at Directus overlever udskiftning

Et container-image kan downloades igen, men database, uploads, extensions, flows og schema-snapshots kan ikke. Montér /directus/database før bootstrap, skriv harmløse testdata, og udskift containeren for at dokumentere, at stien faktisk er persistent. Kontrollér det effektive mount i stedet for at stole på et Compose-filnavn, og kontrollér, at runtime-brugeren kan skrive, hvor Directus forventer det.

Vælg retention og en destination uden for værten, og øv gendannelse uden at røre produktionen. Øvelsen er kun bestået, når schema, roller, flows, items, extensions og uploads er tilbage, og både REST- og GraphQL-prober lykkes. For databasebaseret state bør du kombinere storage-snapshots med application-consistent exports som beskrevet i point-in-time recovery versus snapshots.

Directus i produktion

Tegn tre grænser omkring Directus: ingress til port 8055, persistent state og understøttende krav. Containeren kan udskiftes, men de to andre kræver tydelige ejere. Netværkskontrakten for Directus er Postgres samt valgfri Redis og object storage til scaled deployments. Hold private endpoints på intern DNS, tillad kun nødvendige outbound-kald, og giv Directus en afgrænset service credential.

Diagrammet er komplet, når en ren klient kan bootstrappe administratoren, oprette en collection og en rolle, skrive via REST, forespørge via GraphQL og uploade en fil. Registrér timing- og resourcedata for database connection pool, API request concurrency, Flow workers, thumbnail generation og upload-storage. Hvis transaktionen fejler, identificerer den første grænse, der ikke opfører sig som dokumenteret, om du skal undersøge routing, lokal kapacitet eller en understøttende service.

Dokumentér Directus-deploymentet fra ende til anden

Opret en lille, midlertidig Directus-fixture, og behold den til hver release. Fixturen skal afprøve det reelle workflow: bootstrap administratoren, opret en collection og en rolle, skriv via REST, forespørg via GraphQL, og upload en fil. Registrér image-digest, ekstern hostname, dependency-adresse og det forventede resultat, så en senere operatør kan gentage testen uden at skulle fortolke denne vejledning.

Kør fixturen tre gange. Brug først det friske deployment. Udskift derefter containeren uden at røre persistent state. Gendan til sidst backuppen i et tomt miljø. Den tredje kørsel er kun bestået, når schema, roller, flows, items, extensions og uploads er tilbage, og både REST- og GraphQL-prober lykkes. Registrér under hver kørsel latency og ressourceforbrug omkring database connection pool, API request concurrency, Flow workers, thumbnail generation og upload-storage. Det bliver baseline for alerts i stedet for en vilkårlig CPU-procent.

Test til sidst den negative sti bevidst: Nægt midlertidigt testidentiteten adgang til Postgres samt valgfri Redis og object storage til scaled deployments. Bekræft, at Directus fejler synligt uden at korrumpere state, genopret den korrekte tilstand, og gentag den vellykkede transaktion. En release-record med de fire resultater er stærkere dokumentation end screenshots af et dashboard eller et enkelt curl-svar.

Start Directus med observerbare standardindstillinger

Start Directus på en måde, der holder routen privat, indtil bootstrap er fuldført.

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

Hvis processen går i loop, skal du sammenligne imagets forventede bruger med ejeren af hver mountede sti. Hvis den forbliver kørende, skal du teste port 8055 lokalt og derefter gå direkte videre til workflowet: bootstrap administratoren, opret en collection og en rolle, skriv via REST, forespørg via GraphQL, og upload en fil. Pin image-versionen, når denne end-to-end-kontrol er bestået, og registrér den præcise konfiguration sammen med servicen.

Credentials, roller og eksponerede overflader

Luk bootstrap-vinduet, så snart den første betroede administrator findes. Den konkrete faldgrube i Directus er at bruge bootstrap-administratorens password efter det første login eller rotere SECRET i blinde. Den sikrere grænse er at udskifte bootstrap-credentials, bruge least-privilege-roller og holde SECRET stabil, fordi den beskytter application sessions og tokens.

Generér SECRET én gang, hold den ude af Git, og bevar den sammen med recovery-manifestet, fordi en ændring kan ugyldiggøre krypteret eller signeret application state. Private netværk bør transportere dependency-credentials, og roller i Directus bør kun give den mindst mulige nyttige handling. Hold følsomme request bodies og provider-responses ude af almindelige logs.

Gør den offentlige origin entydig

Undgå midlertidige og permanente offentlige origins for Directus. Sæt i stedet PUBLIC_URL til den kanoniske HTTPS-adresse, peg det valgte DNS-navn på platformens route, og proxy kun til port 8055.

Afprøv dette fra uden for værten: bootstrap administratoren, opret en collection og en rolle, skriv via REST, forespørg via GraphQL, og upload en fil. Hvis ingress fejler, dækker 502-fejlfindingsvejledningen fejl med porte og listeners. Hvis Directus modtager requesten, men databaseklienten er forkert, eller upload-storage ikke kan skrives til, peger dokumentationen nu på noget uden for proxyen.

Fejløvelser for Directus

For Directus skal du overvåge en transaktion i stedet for en proces: bootstrap administratoren, opret en collection og en rolle, skriv via REST, forespørg via GraphQL, og upload en fil. Kombinér dens latency og error rate med database connection pool, API request concurrency, Flow workers, thumbnail generation og upload-storage, så en alert identificerer den komponent, der er begrænsningen.

Opgraderingsøvelsen skal dække, at Directus-schema-migrationer, extensions og support af databaseleverandører skal kontrolleres samlet. Gendan, migrér, og kør transaktionen før udskiftning i produktionen. Hvis databaseklienten er forkert, eller upload-storage ikke kan skrives til, må du ikke slette data for at få en grøn startup. Sammenlign version, variabler, mounts og dependency reachability i den rækkefølge.

Hvad Dockup bør automatisere for Directus

Platformlaget for Directus består af port 8055, ingress, TLS, runtime-konfiguration, storage og dependency reachability. Dockup kan genskabe disse dele i sin egen infrastruktur eller på en server, som kunden tilslutter.

Derefter afslutter operatøren produktlaget: Sæt PUBLIC_URL til den kanoniske HTTPS-adresse; håndhæv denne adgangsregel — udskift bootstrap-credentials, brug least-privilege-roller, og hold SECRET stabil, fordi den beskytter application sessions og tokens; og kør “bootstrap administratoren, opret en collection og en rolle, skriv via REST, forespørg via GraphQL, og upload en fil”. Når testen registreres sammen med deploymentet, undgår man at forveksle automatiseret provisioning med application readiness.

Ofte stillede spørgsmål

Hvad skal Directus bruge til et deployment i produktion?

Route Directus-containeren på port 8055 gennem én HTTPS-origin. Det understøttende netværkskrav er Postgres samt valgfri Redis og object storage til scaled deployments. Erklær ikke Directus klar, før du kan bootstrappe administratoren, oprette en collection og en rolle, skrive via REST, forespørge via GraphQL og uploade en fil.

Hvilke Directus-data skal med i en backup?

Gør /directus/database persistent, og inkludér database, uploads, extensions, flows og schema-snapshots i det samme recovery-manifest. En ren Directus-gendannelse er kun bestået, når schema, roller, flows, items, extensions og uploads er tilbage, og både REST- og GraphQL-prober lykkes.

Kræver Directus HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Directus-origin, og hold port 8055 på den interne route. Anvend Directus-indstillingen korrekt: Sæt PUBLIC_URL til den kanoniske HTTPS-adresse. For Directus beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet origin-følsom klientadfærd.

Hvordan bør en Directus-opgradering testes?

Gendan den aktuelle Directus-state i et isoleret deployment, anvend kandidatversionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi Directus-schema-migrationer, extensions og support af databaseleverandører skal kontrolleres samlet. Behold det tidligere Directus-image, indtil grænsen for datamigrering og rollback er forstået.