Slik selvhoster du Directus i 2026: database, opplastinger og offentlig URL

Se på Directus som et lite system, ikke bare et Docker-image. Målet for brukeren av Directus er tydelig: REST- og GraphQL-API samt et admin-grensesnitt over dataene dine. Distribusjonen er først godkjent når du kan bootstrappe administratoren, opprette en collection og en rolle, skrive via REST, spørre via GraphQL og laste opp en fil.

Dette skillet avdekker feilen operatører møter etter lokal testing: databaseklienten er feil, eller lagringen for opplastinger er ikke skrivbar. Det gjør også planen for sikkerhetskopiering og oppgradering konkret nok til å testes.

Bevis at Directus overlever utskifting

Et container-image kan lastes ned på nytt, men database, opplastinger, extensions, flows og snapshots av schemaet kan ikke det. Monter /directus/database før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at denne banen faktisk er persistent. Kontroller det effektive mountet i stedet for å stole på et Compose-filnavn, og sjekk at runtime-brukeren kan skrive der Directus forventer det.

Velg retention og en destinasjon utenfor verten, og øv på gjenoppretting uten å berøre produksjon. Øvelsen er godkjent først når schema, roller, flows, items, extensions og opplastinger er tilbake, og både REST- og GraphQL-probene lykkes. For databasetilstand bør du kombinere snapshots av lagringen med applikasjonskonsistente eksporter, som beskrevet i gjenoppretting til et bestemt tidspunkt kontra snapshots.

Directus i produksjon

Tegn tre grenser rundt Directus: ingress til port 8055, persistent tilstand og støttende krav. Containeren kan erstattes, men de to andre trenger tydelige eiere. Nettverkskontrakten for Directus er Postgres, samt valgfri Redis og object storage for skalerte distribusjoner. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Directus en avgrenset service credential.

Diagrammet er komplett når en ren klient kan bootstrappe administratoren, opprette en collection og en rolle, skrive via REST, spørre via GraphQL og laste opp en fil. Samle inn tids- og ressursdata for database connection pool, samtidige API-forespørsler, Flow workers, generering av thumbnails og lagring for opplastinger. Hvis transaksjonen mislykkes, viser den første grensen som ikke oppfører seg som dokumentert om du bør undersøke routing, lokal kapasitet eller en støttetjeneste.

Bevis Directus-distribusjonen fra ende til ende

Opprett en liten, midlertidig Directus-fixture og behold den for hver release. Fixturen bør teste den faktiske arbeidsflyten: bootstrappe administratoren, opprette en collection og en rolle, skrive via REST, spørre via GraphQL og laste opp en fil. Registrer image digest, eksternt hostname, adressen til avhengigheten og forventet resultat, slik at en senere operatør kan gjenta testen uten å tolke denne veiledningen.

Kjør fixturen tre ganger. Først bruker du den ferske distribusjonen. Deretter erstatter du containeren uten å berøre persistent tilstand. Til slutt gjenoppretter du sikkerhetskopien til et tomt miljø. Den tredje kjøringen er godkjent først når schema, roller, flows, items, extensions og opplastinger er tilbake, og både REST- og GraphQL-probene lykkes. Under hver kjøring måler du responstid og ressursbruk rundt database connection pool, samtidige API-forespørsler, Flow workers, generering av thumbnails og lagring for opplastinger. Dette blir grunnlaget for alarmer, i stedet for en vilkårlig CPU-prosent.

Test til slutt den negative banen med hensikt: nekt testidentiteten tilgang til Postgres, samt valgfri Redis og object storage for skalerte distribusjoner. Bekreft at Directus feiler tydelig uten å ødelegge tilstanden, gjenopprett riktig tilstand og gjenta den vellykkede transaksjonen. En release-registrering som inneholder disse fire resultatene, er sterkere dokumentasjon enn skjermbilder av et dashboard eller et enkelt curl-svar.

Start Directus med observerbare standarder

Start Directus slik at ruten forblir privat til bootstrap er fullfø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 prosessen går i loop, sammenligner du image-ets forventede bruker med eieren av hver monterte bane. Hvis den holder seg oppe, tester du port 8055 lokalt og går deretter rett til arbeidsflyten: bootstrappe administratoren, opprette en collection og en rolle, skrive via REST, spørre via GraphQL og laste opp en fil. Lås image-versjonen først etter at denne ende-til-ende-kontrollen er godkjent, og registrer den nøyaktige konfigurasjonen sammen med tjenesten.

Credentials, roller og eksponerte flater

Lukk bootstrap-vinduet så snart den første betrodde administratoren finnes. Den konkrete fellen i Directus er å bruke bootstrap-passordet etter første innlogging eller rotere SECRET blindt. Den tryggere grensen er å erstatte bootstrap-credentials, bruke roller med minste privilegium og holde SECRET stabil, fordi den beskytter applikasjonssesjoner og tokens.

Generer SECRET én gang, hold den utenfor Git og ta vare på den sammen med recovery-manifestet, fordi en endring kan ugyldiggjøre kryptert eller signert applikasjonstilstand. Privat nettverk bør transportere credentials til avhengigheter, og roller i Directus bør gi den minste nyttige handlingen. Ikke ta med sensitive request bodies og svar fra providers i vanlige logger.

Gjør den offentlige origin entydig

Unngå midlertidige og permanente offentlige origins for Directus. Sett i stedet PUBLIC_URL til den kanoniske HTTPS-adressen, pek det valgte DNS-navnet til plattformruten og proxier bare til port 8055.

Test dette utenfra verten: bootstrappe administratoren, opprette en collection og en rolle, skrive via REST, spørre via GraphQL og laste opp en fil. Hvis ingress feiler, dekker veiledningen for feilsøking av 502 feil med porter og listeners. Hvis Directus mottar forespørselen, men databaseklienten er feil eller lagringen for opplastinger ikke er skrivbar, peker bevisene nå videre enn proxien.

Feiløvelser for Directus

For Directus bør du overvåke en transaksjon, ikke bare en prosess: bootstrappe administratoren, opprette en collection og en rolle, skrive via REST, spørre via GraphQL og laste opp en fil. Kombiner responstid og feilrate med database connection pool, samtidige API-forespørsler, Flow workers, generering av thumbnails og lagring for opplastinger, slik at et alarmvarsel identifiserer den begrensende komponenten.

Oppgraderingsøvelsen må dekke at schema-migreringer i Directus, extensions og støtte for databaseleverandører må kontrolleres som en helhet. Gjenopprett, migrer og kjør transaksjonen før produksjonen erstattes. Hvis databaseklienten er feil eller lagringen for opplastinger ikke er skrivbar, må du ikke slette data for å få en grønn oppstart. Sammenlign versjon, variabler, mounts og tilgjengelighet til avhengigheter i denne rekkefølgen.

Hva Dockup bør automatisere for Directus

Plattformlaget for Directus består av port 8055, ingress, TLS, runtime-konfigurasjon, lagring og tilgjengelighet til avhengigheter. Dockup kan gjenskape disse delene for sin egen infrastruktur eller en server kunden kobler til.

Deretter fullfører operatøren produktlaget: sett PUBLIC_URL til den kanoniske HTTPS-adressen, håndhev denne tilgangsregelen — erstatt bootstrap-credentials, bruk roller med minste privilegium og hold SECRET stabil, fordi den beskytter applikasjonssesjoner og tokens — og kjør «bootstrappe administratoren, opprette en collection og en rolle, skrive via REST, spørre via GraphQL og laste opp en fil». Når denne testen registreres sammen med distribusjonen, unngår du å forveksle automatisert klargjøring med at applikasjonen er klar.

Vanlige spørsmål

Hva trenger Directus for en produksjonsdistribusjon?

Rout Directus-containeren på port 8055 gjennom én HTTPS-origin. Det støttende nettverkskravet er Postgres, samt valgfri Redis og object storage for skalerte distribusjoner. Ikke kall Directus klar før du kan bootstrappe administratoren, opprette en collection og en rolle, skrive via REST, spørre via GraphQL og laste opp en fil.

Hvilke Directus-data bør inngå i en sikkerhetskopi?

Gjør /directus/database persistent, og inkluder database, opplastinger, extensions, flows og snapshots av schemaet i det samme recovery-manifestet. En ren Directus-gjenoppretting er godkjent først når schema, roller, flows, items, extensions og opplastinger er tilbake, og både REST- og GraphQL-probene lykkes.

Krever Directus HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Directus-originen, og behold port 8055 på den interne ruten. Bruk Directus-innstillingen riktig: sett PUBLIC_URL til den kanoniske HTTPS-adressen. For Directus beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for at origin-sensitiv klientadferd forblir konsistent.

Hvordan bør en Directus-oppgradering testes?

Gjenopprett den gjeldende Directus-tilstanden til en isolert distribusjon, installer kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at schema-migreringer i Directus, extensions og støtte for databaseleverandører må kontrolleres som en helhet. Behold det forrige Directus-imaget til grensen for datamigrering og rollback er forstått.