2026'da Directus Kendi Sunucunda Nasıl Barındırılır: Veritabanı, Yüklemeler ve Genel URL

Directus'u bir Docker image'ı olarak değil, küçük bir sistem olarak ele al. Directus için kullanıcıya sunulan hedef nettir: verilerin üzerinde REST ve GraphQL API'leri ile bir admin arayüzü; deployment ise yalnızca yöneticiyi başlatabildiğinde, bir collection ve role oluşturabildiğinde, REST üzerinden yazabildiğinde, GraphQL üzerinden sorgulayabildiğinde ve bir dosya yükleyebildiğinde kabul edilebilir.

Bu ayrım, operatörlerin local testlerden sonra karşılaştığı hata modunu ortaya çıkarır: veritabanı istemcisi yanlıştır veya upload storage yazılabilir değildir. Ayrıca backup ve upgrade planını test edilebilecek kadar somut hâle getirir.

Directus'un değiştirme sonrasında da çalıştığını kanıtla

Bir container image'ı yeniden indirilebilir; veritabanı, uploads, extensions, flows ve schema snapshot'ları yeniden oluşturulamaz. Bootstrap işleminden önce /directus/database dizinini mount et, zararsız örnek veriler yaz ve bu yolun gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştir. Bir Compose dosya adına güvenmek yerine etkin mount'u incele ve runtime kullanıcısının Directus'un beklediği konumlara yazabildiğini kontrol et.

Retention süresini ve off-host hedefini seç, ardından production'a dokunmadan recovery sürecini prova et. Tatbikat yalnızca schema, roller, flows, items, extensions ve uploads geri geldiğinde ve hem REST hem de GraphQL probe'ları başarılı olduğunda geçer. Veritabanı destekli state için storage snapshot'larını, point-in-time recovery ile snapshot'lar başlıklı yazıda açıklandığı gibi uygulama tutarlı export'larla birlikte kullan.

Directus'un production mimarisi

Directus'un çevresine üç sınır çiz: ingress'ten 8055 portuna giden yol, kalıcı state ve destekleyici gereksinimler. Container değiştirilebilir; ancak diğer iki alanın sorumluları açıkça belirlenmelidir. Directus'un network contract'ı Postgres ile birlikte, ölçeklenen deployment'lar için isteğe bağlı Redis ve object storage kullanımını kapsar. Private endpoint'leri internal DNS üzerinde tut, yalnızca gerekli outbound çağrılara izin ver ve Directus'a kapsamı sınırlandırılmış bir service credential ver.

Temiz bir client yöneticiyi başlatabildiğinde, bir collection ve role oluşturabildiğinde, REST üzerinden yazabildiğinde, GraphQL üzerinden sorgulayabildiğinde ve bir dosya yükleyebildiğinde diyagram tamamlanmış olur. Database connection pool, API request concurrency, Flow workers, thumbnail generation ve upload storage için timing ve resource verilerini topla. Transaction başarısız olursa, belgelenen şekilde davranmayan ilk sınır; routing'i, local capacity'yi veya destekleyici bir servisi incelemen gerekip gerekmediğini gösterir.

Directus deployment'ını uçtan uca kanıtla

Küçük ve disposable bir Directus fixture'ı oluştur ve bunu her release için sakla. Fixture gerçek workflow'u çalıştırmalıdır: yöneticiyi başlatmak, bir collection ve role oluşturmak, REST üzerinden yazmak, GraphQL üzerinden sorgulamak ve bir dosya yüklemek. Image digest'ini, external hostname'i, dependency adresini ve beklenen sonucu kaydet; böylece sonraki operatör bu rehberi yorumlamak zorunda kalmadan testi tekrarlayabilir.

Fixture'ı üç kez çalıştır. İlkinde fresh deployment kullan. İkincisinde kalıcı state'e dokunmadan container'ı değiştir. Üçüncüsünde backup'ı boş bir ortama restore et. Üçüncü çalışma yalnızca schema, roller, flows, items, extensions ve uploads geri geldiğinde ve hem REST hem de GraphQL probe'ları başarılı olduğunda geçer. Her çalışma sırasında database connection pool, API request concurrency, Flow workers, thumbnail generation ve upload storage çevresindeki latency ve resource kullanımını kaydet; bu veriler rastgele bir CPU yüzdesi yerine alert'ler için baseline oluşturur.

Son olarak negative path'i kasıtlı olarak test et: test identity'sinin Postgres ile birlikte, ölçeklenen deployment'lar için isteğe bağlı Redis ve object storage'a erişimini geçici olarak engelle. Directus'un state'i bozmadan görünür bir şekilde başarısız olduğunu doğrula, doğru koşulu geri yükle ve başarılı transaction'ı tekrarla. Bu dört sonucu içeren bir release kaydı, bir dashboard ekran görüntüsünden veya tek seferlik bir curl yanıtından daha güçlü kanıttır.

Directus'u gözlemlenebilir varsayılanlarla başlat

Directus'u, bootstrap tamamlanana kadar route'u private bırakacak şekilde başlat.

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

Process loop'a girerse image'ın beklediği kullanıcıyı her mount edilmiş path'in sahibiyle karşılaştır. Çalışmaya devam ederse 8055 portunu local olarak test et ve ardından doğrudan workflow'a geç: yöneticiyi başlat, bir collection ve role oluştur, REST üzerinden yaz, GraphQL üzerinden sorgula ve bir dosya yükle. Image'ı version-pin işlemini ancak bu uçtan uca kontrol başarılı olduktan sonra yap ve kesin configuration'ı service'in yanında kaydet.

Credential'lar, roller ve dışa açık yüzeyler

İlk güvenilir administrator oluşturulur oluşturulmaz bootstrap penceresini kapat. Directus'taki somut tuzak, ilk login'den sonra bootstrap admin password'ünü kullanmaya devam etmek veya SECRET'ı düşünmeden rotate etmektir; daha güvenli sınır, bootstrap credential'larını değiştirmek, least-privilege roller kullanmak ve uygulama session'larını ve token'ları koruduğu için SECRET'ı sabit tutmaktır.

SECRET'ı bir kez generate et, Git dışında tut ve recovery manifest ile birlikte sakla; çünkü değiştirilmesi encrypted veya signed application state'i geçersiz kılabilir. Private networking dependency credential'larını taşımalı, Directus içindeki roller ise gerekli en küçük action'ı vermelidir. Hassas request body'lerini ve provider response'larını rutin log'lara yazma.

Public origin'i belirsiz bırakma

Directus için geçici ve kalıcı public origin'leri birlikte kullanmaktan kaçın. Bunun yerine PUBLIC_URL'i canonical HTTPS adresine ayarla, seçtiğin DNS name'i platform route'una yönlendir ve yalnızca 8055 portuna proxy yap.

Bu action'ı host'un dışından çalıştır: yöneticiyi başlat, bir collection ve role oluştur, REST üzerinden yaz, GraphQL üzerinden sorgula ve bir dosya yükle. Ingress başarısız olursa 502 troubleshooting guide port ve listener hatalarını kapsar. Directus isteği alıyor ancak veritabanı istemcisi yanlış veya upload storage yazılabilir değilse, kanıt artık proxy'nin ötesine işaret eder.

Directus için failure drill'ları

Directus için bir process'i değil, transaction'ı izle: yöneticiyi başlat, bir collection ve role oluştur, REST üzerinden yaz, GraphQL üzerinden sorgula ve bir dosya yükle. Bir alert'in kısıtlanan bileşeni belirleyebilmesi için latency ve error rate'i database connection pool, API request concurrency, Flow workers, thumbnail generation ve upload storage ile birlikte değerlendir.

Upgrade rehearsal, Directus schema migration'larının, extensions'ların ve database vendor desteğinin tek bir bütün olarak kontrol edilmesini kapsamalıdır. Production'da replacement yapmadan önce restore et, migrate et ve transaction'ı çalıştır. Veritabanı istemcisi yanlış veya upload storage yazılabilir değilse, startup'ı green yapmak için verileri silme; version, variables, mounts ve dependency reachability'yi bu sırayla karşılaştır.

Dockup Directus için neleri otomatikleştirmeli?

Directus için platform katmanı 8055 portu, ingress, TLS, runtime configuration, storage ve dependency reachability'den oluşur. Dockup bu parçaları kendi infrastructure'ı veya müşterinin bağladığı bir server için yeniden oluşturabilir.

Ardından operatör product katmanını tamamlar: PUBLIC_URL'i canonical HTTPS adresine ayarla; şu access rule'u uygula — bootstrap credential'larını değiştir, least-privilege roller kullan ve uygulama session'larını ve token'ları koruduğu için SECRET'ı sabit tut; ardından “yöneticiyi başlat, bir collection ve role oluştur, REST üzerinden yaz, GraphQL üzerinden sorgula ve bir dosya yükle” işlemini çalıştır. Bu testi deployment'ın yanında kaydetmek, automated provisioning ile application readiness kavramlarının karıştırılmasını önler.

Sık sorulan sorular

Production deployment için Directus neye ihtiyaç duyar?

Directus container'ını tek bir HTTPS origin üzerinden 8055 portuna route et. Destekleyici network gereksinimi Postgres ile birlikte, ölçeklenen deployment'lar için isteğe bağlı Redis ve object storage'dır. Yöneticiyi başlatabildiğinde, bir collection ve role oluşturabildiğinde, REST üzerinden yazabildiğinde, GraphQL üzerinden sorgulayabildiğinde ve bir dosya yükleyebildiğinde Directus'u hazır kabul et.

Directus verilerinin hangileri backup'a dahil edilmelidir?

/directus/database dizinini kalıcı hâle getir ve database, uploads, extensions, flows ve schema snapshot'larını aynı recovery manifest'e dahil et. Temiz bir Directus restore işlemi yalnızca schema, roller, flows, items, extensions ve uploads geri geldiğinde ve hem REST hem de GraphQL probe'ları başarılı olduğunda geçer.

Reverse proxy arkasındaki Directus HTTPS gerektirir mi?

Public Directus origin'i için HTTPS kullan ve 8055 portunu internal route üzerinde tut. Directus ayarını doğru uygula: PUBLIC_URL'i canonical HTTPS adresine ayarla. Directus için HTTPS, credential'ları veya kullanıcı içeriğini aktarım sırasında korur ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Directus upgrade'i nasıl test edilmelidir?

Mevcut Directus state'ini izole bir deployment'a restore et, aday version'ı uygula ve acceptance transaction'ı tekrarla. Özellikle dikkat et; çünkü Directus schema migration'ları, extensions'ları ve database vendor desteği tek bir bütün olarak kontrol edilmelidir. Data migration ve rollback sınırı anlaşılana kadar önceki Directus image'ını sakla.