Jak provozovat Directus ve vlastní režii v roce 2026: databáze, uploady a veřejná URL

Přistupujte k Directus jako k malému systému, ne jako k Docker image. Cíl z pohledu uživatele je u Directus jasný: REST a GraphQL API spolu s administračním rozhraním nad vašimi daty; nasazení je přijatelné teprve ve chvíli, kdy můžete vytvořit administrátora, kolekci a roli, zapisovat přes REST, dotazovat se přes GraphQL a nahrát soubor.

Toto rozlišení odhaluje typický problém, se kterým se operátoři setkávají po lokálním testování: databázový klient je nesprávný nebo do úložiště pro uploady nelze zapisovat. Zároveň díky němu získáte dostatečně konkrétní plán zálohování a upgradu, který lze otestovat.

Ověřte, že Directus přežije nahrazení

Docker image lze znovu stáhnout; databázi, uploady, extensions, flows a snapshots schématu nikoli. Před bootstrapem připojte /directus/database, zapište neškodná ukázková data a nahraďte kontejner, abyste ověřili, že je tato cesta skutečně persistentní. Zkontrolujte efektivní mount místo toho, abyste slepě důvěřovali názvu Compose souboru, a ověřte, že runtime user může zapisovat tam, kam Directus očekává.

Zvolte dobu uchování a umístění mimo hostitele a poté si obnovu nacvičte, aniž byste zasáhli produkci. Test je úspěšný pouze tehdy, když se vrátí schéma, role, flows, položky, extensions a uploady a úspěšně projdou sondy REST i GraphQL. U stavu uloženého v databázi kombinujte snapshoty úložiště s exporty konzistentními z pohledu aplikace, jak je popsáno v článku obnova k určitému okamžiku versus snapshoty.

Produkční podoba Directus

Nakreslete kolem Directus tři hranice: ingress na port 8055, persistentní stav a podpůrné požadavky. Kontejner lze nahradit, ale zbývající dvě oblasti potřebují jasně určené vlastníky. Síťový kontrakt pro Directus tvoří Postgres a pro škálovaná nasazení volitelně Redis a object storage. Privátní endpointy ponechte na interním DNS, povolte pouze nezbytná odchozí spojení a přidělte Directus service credential s omezeným rozsahem oprávnění.

Diagram je kompletní ve chvíli, kdy čistý klient dokáže vytvořit administrátora, kolekci a roli, zapisovat přes REST, dotazovat se přes GraphQL a nahrát soubor. Zaznamenávejte časování a údaje o využití prostředků pro database connection pool, souběžnost API requestů, Flow workers, generování thumbnailů a úložiště uploadů. Pokud transakce selže, první hranice, která se nechová podle dokumentace, určí, zda máte prověřit routing, lokální kapacitu nebo podpůrnou službu.

Ověřte nasazení Directus od začátku do konce

Vytvořte malý, jednorázový fixture Directus a ponechte si ho pro každé vydání. Fixture by měl pokrývat skutečný workflow: vytvoření administrátora, kolekce a role, zápis přes REST, dotaz přes GraphQL a nahrání souboru. Zaznamenejte digest image, externí hostname, adresu závislosti a očekávaný výsledek, aby pozdější operátor mohl test zopakovat bez interpretace této příručky.

Spusťte fixture třikrát. Nejprve použijte čerstvé nasazení. Podruhé nahraďte kontejner, aniž byste zasáhli persistentní stav. Potřetí obnovte zálohu do prázdného prostředí. Třetí běh je úspěšný pouze tehdy, když se vrátí schéma, role, flows, položky, extensions a uploady a úspěšně projdou sondy REST i GraphQL. Během každého běhu zachyťte latenci a využití prostředků v okolí database connection pool, souběžnosti API requestů, Flow workers, generování thumbnailů a úložiště uploadů; to se stane základem pro alerty namísto libovolně zvoleného procenta CPU.

Nakonec záměrně otestujte negativní scénář: dočasně odeberte testovací identitě přístup k Postgres a pro škálovaná nasazení také k volitelnému Redis a object storage. Ověřte, že Directus selže viditelně, aniž by poškodil stav, obnovte správné podmínky a úspěšnou transakci zopakujte. Záznam o vydání obsahující tyto čtyři výsledky je silnějším důkazem než screenshoty dashboardu nebo jednorázová odpověď z curl.

Spusťte Directus s pozorovatelnými výchozími hodnotami

Spusťte Directus tak, aby route zůstala privátní, dokud nebude bootstrap dokončen.

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

Pokud proces běží v loopu, porovnejte očekávaného usera image s vlastníkem každé připojené cesty. Pokud zůstane běžet, otestujte lokálně port 8055 a poté rovnou přejděte k workflow: vytvoření administrátora, kolekce a role, zápis přes REST, dotaz přes GraphQL a nahrání souboru. Image opatřete pevnou verzí teprve po úspěšném end-to-end ověření a přesnou konfiguraci zaznamenejte vedle služby.

Přihlašovací údaje, role a vystavené povrchy

Bootstrap okno uzavřete, jakmile existuje první důvěryhodný administrátor. Konkrétní past u Directus spočívá v používání bootstrap hesla po prvním přihlášení nebo ve slepé rotaci SECRET; bezpečnější hranicí je nahradit bootstrap credentials, používat role s nejmenšími oprávněními a ponechat SECRET stabilní, protože chrání aplikační sessions a tokeny.

SECRET vygenerujte jednou, udržujte ho mimo Git a uchovejte ho spolu s recovery manifestem, protože jeho změna může zneplatnit šifrovaný nebo podepsaný stav aplikace. Credentials k závislostem by měla putovat privátní sítí a role uvnitř Directus by měly povolovat pouze nejmenší užitečnou akci. Citlivá těla requestů a odpovědi providerů nezapisujte do běžných logů.

Zajistěte jednoznačný veřejný origin

Vyhněte se dočasným i trvalým veřejným originům pro Directus. Místo toho nastavte PUBLIC_URL na kanonickou HTTPS adresu, nasměrujte zvolený DNS název na route platformy a proxy směrujte pouze na port 8055.

Tuto akci otestujte mimo hostitele: vytvořte administrátora, kolekci a roli, zapisujte přes REST, dotazujte se přes GraphQL a nahrajte soubor. Pokud ingress selhává, průvodce řešením chyby 502 pokrývá chyby portu a listeneru. Pokud Directus request přijme, ale databázový klient je nesprávný nebo do úložiště uploadů nelze zapisovat, důkazy nyní ukazují mimo proxy.

Testy selhání pro Directus

U Directus monitorujte transakci, ne proces: vytvoření administrátora, kolekce a role, zápis přes REST, dotaz přes GraphQL a nahrání souboru. Její latenci a chybovost kombinujte s údaji o database connection pool, souběžnosti API requestů, Flow workers, generování thumbnailů a úložišti uploadů, aby alert identifikoval omezenou komponentu.

Rehearsal upgradu musí pokrýt skutečnost, že migrace schématu Directus, extensions a podpora databázových vendorů se musí kontrolovat jako jeden celek. Před nahrazením produkce proveďte obnovu, migraci a transakci. Pokud je databázový klient nesprávný nebo do úložiště uploadů nelze zapisovat, nemažte data jen proto, aby startup skončil zeleně; v tomto pořadí porovnejte verzi, proměnné, mounty a dostupnost závislostí.

Co by měl Dockup pro Directus automatizovat

Platformní vrstvu pro Directus tvoří port 8055, ingress, TLS, runtime konfigurace, úložiště a dostupnost závislostí. Dockup může tyto části reprodukovat pro vlastní infrastrukturu nebo pro server připojený zákazníkem.

Operátor poté dokončí produktovou vrstvu: nastaví PUBLIC_URL na kanonickou HTTPS adresu; vynutí toto přístupové pravidlo — nahradit bootstrap credentials, používat role s nejmenšími oprávněními a ponechat SECRET stabilní, protože chrání aplikační sessions a tokeny; a spustí „vytvoření administrátora, kolekce a role, zápis přes REST, dotaz přes GraphQL a nahrání souboru“. Zaznamenání tohoto testu spolu s nasazením pomáhá odlišit automatizované provisionování od připravenosti aplikace.

Často kladené otázky

Co Directus potřebuje pro produkční nasazení?

Veďte kontejner Directus na portu 8055 přes jediný HTTPS origin. Síťový požadavek na podpůrné služby tvoří Postgres a pro škálovaná nasazení volitelně Redis a object storage. Directus nepovažujte za připravený, dokud nemůžete vytvořit administrátora, kolekci a roli, zapisovat přes REST, dotazovat se přes GraphQL a nahrát soubor.

Která data Directus patří do zálohy?

Zachovejte /directus/database a do stejného recovery manifestu zahrňte databázi, uploady, extensions, flows a snapshots schématu. Obnova čistého Directus je úspěšná pouze tehdy, když se vrátí schéma, role, flows, položky, extensions a uploady a úspěšně projdou sondy REST i GraphQL.

Vyžaduje Directus HTTPS za reverse proxy?

Pro veřejný origin Directus použijte HTTPS a port 8055 ponechte na interní route. Nastavení Directus aplikujte správně: nastavte PUBLIC_URL na kanonickou HTTPS adresu. U Directus HTTPS chrání credentials nebo uživatelský obsah při přenosu a zajišťuje konzistentní chování klienta závislé na originu.

Jak testovat upgrade Directus?

Obnovte aktuální stav Directus do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte akceptační transakci. Věnujte tomu zvláštní pozornost, protože migrace schématu Directus, extensions a podpora databázových vendorů se musí kontrolovat jako jeden celek. Předchozí Directus image ponechte, dokud nebudou jasné hranice migrace dat a rollbacku.