Så self-hostar du Directus 2026: databas, uppladdningar och publik URL

Se Directus som ett mindre system, inte som en Docker-avbildning. Målet för användaren är tydligt: ett REST- och GraphQL-API samt ett admin-gränssnitt ovanpå dina data. En deployment är godkänd först när du kan bootstrapa administratören, skapa en collection och en roll, skriva via REST, fråga via GraphQL och ladda upp en fil.

Den skillnaden fångar det fel som driftteam ofta stöter på efter lokal testning: databas-klienten är fel eller så går det inte att skriva till uppladdningslagringen. Den gör också planen för backup och uppgraderingar tillräckligt konkret för att kunna testas.

Bevisa att Directus överlever att ersättas

En container-avbildning kan laddas ned igen, men databas, uppladdningar, extensions, flows och schema snapshots kan inte det. Montera /directus/database före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är persistent. Kontrollera den aktiva mounten i stället för att lita på ett Compose-filnamn, och verifiera att runtime-användaren kan skriva där Directus förväntar sig det.

Välj retention och en destination utanför hosten, och öva sedan på återställning utan att röra produktionen. Övningen är godkänd först när schema, roller, flows, items, extensions och uppladdningar kommer tillbaka och både REST- och GraphQL-prober lyckas. För databaserat tillstånd kombinerar du storage snapshots med application-consistent exports enligt beskrivningen i point-in-time recovery jämfört med snapshots.

Directus produktionsarkitektur

Rita tre gränser runt Directus: ingress till port 8055, persistent tillstånd och stödkrav. Containern kan ersättas, men de två andra behöver tydliga ägare. Directus nätverkskontrakt består av Postgres samt valfri Redis och object storage för skalade deployments. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Directus en service credential med begränsad behörighet.

Diagrammet är komplett när en ren klient kan bootstrapa administratören, skapa en collection och en roll, skriva via REST, fråga via GraphQL och ladda upp en fil. Samla in tids- och resursdata för databasens connection pool, samtidiga API-anrop, Flow workers, generering av thumbnails och upload storage. Om transaktionen misslyckas visar den första gränsen som inte beter sig enligt dokumentationen om du ska undersöka routing, lokal kapacitet eller en stödjande tjänst.

Bevisa Directus-deploymenten från början till slut

Skapa en liten, temporär Directus-fixture och behåll den för varje release. Fixturen ska testa det verkliga arbetsflödet: bootstrapa administratören, skapa en collection och en roll, skriva via REST, fråga via GraphQL och ladda upp en fil. Dokumentera image digest, externt hostname, dependency address och förväntat resultat så att nästa operatör kan upprepa testet utan att behöva tolka den här guiden.

Kör fixturen tre gånger. Använd först den nya deploymenten. Ersätt sedan containern utan att röra persistent tillstånd. Återställ slutligen backupen till en tom miljö. Den tredje körningen är godkänd först när schema, roller, flows, items, extensions och uppladdningar kommer tillbaka och både REST- och GraphQL-prober lyckas. Samla under varje körning in latency och resursanvändning för databasens connection pool, samtidiga API-anrop, Flow workers, generering av thumbnails och upload storage. Det blir baslinjen för alerts i stället för en godtycklig CPU-procent.

Testa slutligen den negativa vägen medvetet: neka tillfälligt testidentiteten åtkomst till Postgres samt valfri Redis och object storage för skalade deployments. Bekräfta att Directus misslyckas tydligt utan att tillståndet skadas, återställ rätt förutsättningar och upprepa den lyckade transaktionen. En releasepost som innehåller dessa fyra resultat är starkare bevis än skärmbilder från en dashboard eller ett svar från en engångskörning med curl.

Starta Directus med observerbara standardvärden

Starta Directus på ett sätt som håller routen privat tills bootstrap är klart.

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

Om processen startar om i en loop jämför du image-användaren med ägaren till varje monterad sökväg. Om den fortsätter köra testar du port 8055 lokalt och går sedan direkt vidare till arbetsflödet: bootstrapa administratören, skapa en collection och en roll, skriv via REST, fråga via GraphQL och ladda upp en fil. Pin:a image-versionen först när kontrollen från början till slut är godkänd, och dokumentera den exakta konfigurationen bredvid tjänsten.

Credentials, roller och exponerade ytor

Stäng bootstrap-fönstret så snart den första betrodda administratören finns. Directus konkreta fallgrop är att fortsätta använda bootstrap-administratörens lösenord efter den första inloggningen eller att rotera SECRET utan planering. En säkrare gräns är att ersätta bootstrap-credentials, använda least-privilege-roller och hålla SECRET stabil eftersom den skyddar applikationens sessioner och tokens.

Generera SECRET en gång, håll den utanför Git och bevara den tillsammans med recovery-manifestet eftersom en ändring kan göra krypterat eller signerat applikationstillstånd ogiltigt. Privata nätverk ska bära dependency-credentials, och rollerna i Directus ska ge minsta användbara behörighet. Se till att känsliga request bodies och provider-svar inte hamnar i vanliga loggar.

Gör den publika origin entydig

Undvik tillfälliga och permanenta publika origins för Directus. Sätt i stället PUBLIC_URL till den kanoniska HTTPS-adressen, peka det valda DNS-namnet mot plattformens route och proxya endast till port 8055.

Testa detta utifrån hosten: bootstrapa administratören, skapa en collection och en roll, skriv via REST, fråga via GraphQL och ladda upp en fil. Om ingress misslyckas beskriver felsökningsguiden för 502 vanliga port- och listener-fel. Om Directus tar emot requesten men databas-klienten är fel eller upload storage inte är skrivbar pekar bevisningen nu bortom proxyn.

Felövningar för Directus

För Directus ska du övervaka en transaktion i stället för en process: bootstrapa administratören, skapa en collection och en roll, skriva via REST, fråga via GraphQL och ladda upp en fil. Kombinera dess latency och error rate med databasens connection pool, samtidiga API-anrop, Flow workers, generering av thumbnails och upload storage så att en alert identifierar den begränsande komponenten.

Repetitionen inför en uppgradering måste omfatta att Directus schema migrations, extensions och stöd för databasleverantörer måste kontrolleras som en helhet. Återställ, migrera och kör transaktionen före bytet i produktion. Om databas-klienten är fel eller upload storage inte är skrivbar ska du inte radera data för att få en grön startup. Jämför version, variabler, mounts och nåbarhet till dependencies i den ordningen.

Vad Dockup bör automatisera för Directus

Plattformslagret för Directus består av port 8055, ingress, TLS, runtime-konfiguration, storage och nåbarhet till dependencies. Dockup kan återskapa dessa delar i sin egen infrastruktur eller på en server som kunden ansluter.

Därefter slutför operatören produktlagret: sätt PUBLIC_URL till den kanoniska HTTPS-adressen, tillämpa denna åtkomstregel — ersätt bootstrap-credentials, använd least-privilege-roller och håll SECRET stabil eftersom den skyddar applikationens sessioner och tokens — och kör ”bootstrapa administratören, skapa en collection och en roll, skriv via REST, fråga via GraphQL och ladda upp en fil”. Om testet dokumenteras tillsammans med deploymenten blir det enklare att skilja automatiserad provisionering från att applikationen faktiskt är redo.

Vanliga frågor

Vad behöver Directus för en produktionsdeployment?

Routa Directus-containern på port 8055 via en enda HTTPS-origin. Det stödjande nätverkskravet är Postgres samt valfri Redis och object storage för skalade deployments. Anse inte Directus vara redo förrän du kan bootstrapa administratören, skapa en collection och en roll, skriva via REST, fråga via GraphQL och ladda upp en fil.

Vilka Directus-data ska ingå i en backup?

Gör /directus/database persistent och inkludera databas, uppladdningar, extensions, flows och schema snapshots i samma recovery-manifest. En ren Directus-återställning är godkänd först när schema, roller, flows, items, extensions och uppladdningar kommer tillbaka och både REST- och GraphQL-prober lyckas.

Kräver Directus HTTPS bakom en reverse proxy?

Använd HTTPS för Directus publika origin och behåll port 8055 på den interna routen. Tillämpa Directus-inställningen korrekt: sätt PUBLIC_URL till den kanoniska HTTPS-adressen. För Directus skyddar HTTPS credentials och användarinnehåll under överföring och ser till att origin-känsligt klientbeteende förblir konsekvent.

Hur ska en Directus-uppgradering testas?

Återställ aktuellt Directus-tillstånd till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptance transaction. Var särskilt uppmärksam eftersom Directus schema migrations, extensions och stöd för databasleverantörer måste kontrolleras som en helhet. Behåll den tidigare Directus-imagen tills gränsen för datamigrering och rollback är förstådd.