Kako samostalno hostati Directus 2026.: baza podataka, uploadi i javni URL

Directus tretirajte kao mali sustav, a ne kao Docker image. Korisnički cilj Directusa je jasan: REST i GraphQL API te administratorsko sučelje nad vašim podacima; deployment je prihvatljiv tek kada možete inicijalizirati administratora, izraditi kolekciju i ulogu, zapisivati putem REST-a, dohvaćati podatke putem GraphQL-a i učitati datoteku.

Ta razlika otkriva problem s kojim se operateri susreću nakon lokalnog testiranja: klijent baze podataka nije ispravan ili upload storage nije moguće zapisivati. Osim toga, plan sigurnosnog kopiranja i nadogradnje postaje dovoljno konkretan za testiranje.

Dokažite da Directus preživljava zamjenu

Container image može se ponovno preuzeti; baza podataka, uploadi, ekstenzije, flowovi i snapshoti sheme ne mogu. Montirajte /directus/database prije inicijalizacije, zapišite bezopasne ogledne podatke i zamijenite container kako biste dokazali da je taj path doista persistentan. Provjerite efektivni mount umjesto da vjerujete nazivu Compose datoteke te provjerite da runtime user može zapisivati na mjesto koje Directus očekuje.

Odaberite retention i odredište izvan hosta, a zatim uvježbajte oporavak bez diranja produkcije. Vježba je uspješna samo kada se vrate shema, uloge, flowovi, stavke, ekstenzije i uploadi te kada REST i GraphQL probe uspješno prođu. Za stanje koje ovisi o bazi podataka kombinirajte snapshotove storagea s exportima konzistentnima s aplikacijom, kao što je opisano u vodiču point-in-time recovery u odnosu na snapshotove.

Produkcijska struktura Directusa

Oko Directusa povucite tri granice: ingress prema portu 8055, trajno stanje i prateće zahtjeve. Container je zamjenjiv, ali za druge dvije granice potrebno je izričito definirati odgovorne osobe. Mrežni ugovor za Directus čine Postgres te opcionalni Redis i object storage za skalirane deploymentove. Privatne endpointe zadržite na internom DNS-u, dopustite samo potrebne outbound pozive i Directusu dodijelite service credential ograničenog opsega.

Dijagram je potpun kada čisti client može inicijalizirati administratora, izraditi kolekciju i ulogu, zapisivati putem REST-a, dohvaćati podatke putem GraphQL-a i učitati datoteku. Prikupite podatke o vremenu i resursima za connection pool baze podataka, konkurentnost API requestova, Flow workere, generiranje thumbnaila i upload storage. Ako transakcija ne uspije, prva granica koja se ne ponaša prema dokumentaciji pokazuje trebate li istražiti routing, lokalni kapacitet ili prateću uslugu.

Dokažite Directus deployment od početka do kraja

Izradite malu, disposable Directus fixture i zadržite je za svako izdanje. Fixture treba obuhvatiti stvarni workflow: inicijalizirati administratora, izraditi kolekciju i ulogu, zapisivati putem REST-a, dohvaćati podatke putem GraphQL-a i učitati datoteku. Zabilježite image digest, vanjski hostname, adresu dependencyja i očekivani rezultat kako bi kasniji operater mogao ponoviti test bez tumačenja ovog vodiča.

Pokrenite fixture tri puta. Prvi put upotrijebite svježi deployment. Drugi put zamijenite container bez diranja trajnog stanja. Treći put vratite sigurnosnu kopiju u prazno okruženje. Treći je prolaz uspješan samo kada se vrate shema, uloge, flowovi, stavke, ekstenzije i uploadi te kada REST i GraphQL probe uspješno prođu. Tijekom svakog pokretanja bilježite latency i korištenje resursa za connection pool baze podataka, konkurentnost API requestova, Flow workere, generiranje thumbnaila i upload storage; to postaje baseline za alerte umjesto proizvoljnog postotka korištenja CPU-a.

Na kraju namjerno testirajte negativni scenarij: privremeno uskratite testnom identitetu pristup Postgresu te opcionalnom Redisu i object storageu za skalirane deploymentove. Potvrdite da Directus vidljivo ne uspijeva bez korupcije stanja, vratite ispravan uvjet i ponovite uspješnu transakciju. Zapis o izdanju koji sadrži ta četiri ishoda snažniji je dokaz od screenshota dashboarda ili jednokratnog odgovora naredbe curl.

Pokrenite Directus s vidljivim zadanim postavkama

Pokrenite Directus tako da ruta ostane privatna dok inicijalizacija ne bude dovršena.

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

Ako se proces vrti u petlji, usporedite očekivanog usera imagea s vlasnikom svakog montiranog patha. Ako ostane pokrenut, lokalno testirajte port 8055 i zatim odmah prijeđite na workflow: inicijalizirajte administratora, izradite kolekciju i ulogu, zapisujte putem REST-a, dohvaćajte podatke putem GraphQL-a i učitajte datoteku. Imageu dodijelite fiksnu verziju tek nakon što end-to-end provjera prođe te zabilježite točnu konfiguraciju uz servis.

Credentiali, uloge i izložene površine

Zatvorite bootstrap window čim postoji prvi pouzdani administrator. Konkretna zamka u Directusu jest korištenje bootstrap administratorske lozinke nakon prve prijave ili slijepo rotiranje vrijednosti SECRET; sigurnija granica jest zamijeniti bootstrap credentiale, koristiti least-privilege uloge i zadržati SECRET stabilnim jer štiti aplikacijske sesije i tokene.

Generirajte SECRET jednom, nemojte ga spremati u Git i sačuvajte ga uz recovery manifest jer njegova promjena može poništiti šifrirano ili potpisano stanje aplikacije. Credentiali za dependencyje trebaju se prenositi privatnim networkingom, a uloge unutar Directusa trebaju dopuštati najmanju korisnu radnju. Osjetljiva tijela requestova i odgovore providera nemojte zapisivati u uobičajene logove.

Učinite javni origin nedvosmislenim

Izbjegavajte privremene i trajne javne origine za Directus. Umjesto toga postavite PUBLIC_URL na kanonsku HTTPS adresu, odabrano DNS ime usmjerite na platformsku rutu i proxy prosljeđujte samo na port 8055.

Ovu radnju provedite izvan hosta: inicijalizirajte administratora, izradite kolekciju i ulogu, zapisujte putem REST-a, dohvaćajte podatke putem GraphQL-a i učitajte datoteku. Ako ingress ne uspije, vodič za rješavanje problema s pogreškom 502 obrađuje probleme s portovima i listenerima. Ako Directus primi request, ali klijent baze podataka nije ispravan ili upload storage nije moguće zapisivati, dokazi sada upućuju izvan proxyja.

Vježbe otklanjanja kvarova za Directus

Za Directus nadzirite transakciju, a ne proces: inicijalizirajte administratora, izradite kolekciju i ulogu, zapisujte putem REST-a, dohvaćajte podatke putem GraphQL-a i učitajte datoteku. Kombinirajte njegov latency i stopu pogrešaka s connection poolom baze podataka, konkurentnošću API requestova, Flow workerima, generiranjem thumbnaila i upload storageom kako bi alert identificirao ograničenu komponentu.

Rehearsal nadogradnje mora obuhvatiti činjenicu da migracije sheme Directusa, ekstenzije i podršku za dobavljača baze podataka treba provjeravati kao cjelinu. Vratite podatke, provedite migraciju i pokrenite transakciju prije zamjene u produkciji. Ako klijent baze podataka nije ispravan ili upload storage nije moguće zapisivati, nemojte brisati podatke kako biste startup prikazali uspješnim; tim redoslijedom usporedite verziju, varijable, mountove i dostupnost dependencyja.

Što bi Dockup trebao automatizirati za Directus

Platformski sloj za Directus čine port 8055, ingress, TLS, runtime konfiguracija, storage i dostupnost dependencyja. Dockup može reproducirati te dijelove za vlastitu infrastrukturu ili server koji korisnik poveže.

Operater zatim dovršava produktni sloj: postavlja PUBLIC_URL na kanonsku HTTPS adresu; provodi ovo pravilo pristupa — zamijenite bootstrap credentiale, koristite least-privilege uloge i zadržite SECRET stabilnim jer štiti aplikacijske sesije i tokene; te pokreće „inicijalizirajte administratora, izradite kolekciju i ulogu, zapisujte putem REST-a, dohvaćajte podatke putem GraphQL-a i učitajte datoteku”. Bilježenje tog testa uz deployment sprječava miješanje automatiziranog provisioninga s pripravnošću aplikacije.

Često postavljana pitanja

Što je Directusu potrebno za produkcijski deployment?

Usmjerite Directus container na portu 8055 kroz jedan HTTPS origin. Mrežni zahtjev za podršku čine Postgres te opcionalni Redis i object storage za skalirane deploymentove. Nemojte smatrati Directus spremnim dok ne možete inicijalizirati administratora, izraditi kolekciju i ulogu, zapisivati putem REST-a, dohvaćati podatke putem GraphQL-a i učitati datoteku.

Koji Directus podaci trebaju biti uključeni u sigurnosnu kopiju?

Zadržite /directus/database i u isti recovery manifest uključite bazu podataka, uploade, ekstenzije, flowove i snapshotove sheme. Uspješan oporavak Directusa potvrđen je tek kada se vrate shema, uloge, flowovi, stavke, ekstenzije i uploadi te kada REST i GraphQL probe uspješno prođu.

Zahtijeva li Directus HTTPS iza reverse proxyja?

Za javni Directus origin koristite HTTPS, a port 8055 zadržite na internoj ruti. Ispravno primijenite Directusovu postavku: postavite PUBLIC_URL na kanonsku HTTPS adresu. Za Directus HTTPS štiti credentiale ili korisnički sadržaj tijekom prijenosa i održava dosljedno ponašanje clienta osjetljivo na origin.

Kako treba testirati nadogradnju Directusa?

Vratite trenutno stanje Directusa u izolirani deployment, primijenite kandidatsku verziju i ponovite acceptance transakciju. Obratite posebnu pozornost na to da migracije sheme Directusa, ekstenzije i podršku za dobavljača baze podataka treba provjeravati kao cjelinu. Prethodni Directus image zadržite dok ne razjasnite granice migracije podataka i rollbacka.