2026'da NocoDB'yi Self-Host Etme: Veritabanı Bağlantıları, Kimlik Doğrulama ve Kalıcı Depolama

“NocoDB çalıştırmanın” iki farklı seviyesi vardır: Bir container'ın mevcut olması veya servisin gerçek işini tamamlaması. Yalnızca ikincisi önemlidir. Buradaki doğrulama; geçici bir source database'e bağlanmak, bir grid ve filtrelenmiş bir view oluşturmak, bir satırı düzenlemek, bir attachment eklemek ve REST API'yi çağırmaktır.

NocoDB'nin amacı budur: Gerçek bir veritabanının üzerinde spreadsheet arayüzü sunmak. Deployment, bu davranışın arkasındaki bileşenleri korumalıdır; bir port, volume ve certificate yalnızca girdidir, sonuç değildir.

NocoDB runtime sınırını çizin

NocoDB için process health ve product health birbirinden ayrıdır. Port 8080 yanıt verse bile kullanıcıya sunulan transaction hâlâ başarısız olabilir. NocoDB'nin network contract'ı, geçici bir local file yerine production metadata için PostgreSQL veya MySQL kullanmaktır. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve NocoDB'ye kapsamı sınırlandırılmış bir service credential sağlayın.

Anlamlı configuration değişikliklerinden sonra şu readiness çalışmasını kullanın: geçici bir source database'e bağlanın, bir grid ve filtrelenmiş bir view oluşturun, bir satırı düzenleyin, bir attachment ekleyin ve REST API'yi çağırın. Pahalı external check'leri liveness probe'larından uzak tutun; böylece bir provider kesintisi restart loop'a neden olmaz. Capacity çalışmalarında row count, attachment trafiği, metadata database latency'si ve eş zamanlı grid kullanıcılarını takip edin. Bunlar, NocoDB'nin gerçek yükünü page request'lerinden daha doğru yansıtır.

NocoDB'yi gözlemlenebilir varsayılanlarla başlatın

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

docker run -d \
  --name nocodb \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v nocodb-data:/usr/app/data \
  -e NC_AUTH_JWT_SECRET=replace-with-a-long-random-value \
  nocodb/nocodb:latest

Process loop'a girerse image'ın beklediği user ile mount edilen her path'in owner'ını karşılaştırın. Çalışmaya devam ederse önce port 8080'i local olarak test edin, ardından doğrudan workflow'a geçin: geçici bir source database'e bağlanın, bir grid ve filtrelenmiş bir view oluşturun, bir satırı düzenleyin, bir attachment ekleyin ve REST API'yi çağırın. Image'ı version-pin işlemini ancak bu uçtan uca kontrol başarılı olduktan sonra yapın ve tam configuration'ı service'in yanında kaydedin.

Domain'ler, proxy header'ları ve port 8080

Kullanıcılar callback'leri veya client ayarlarını kaydetmeden önce NocoDB için son hostname'i belirleyin, ardından NC_PUBLIC_URL değerini canonical HTTPS adresine ayarlayın. Platform route'u TLS'i bir kez terminate etmeli ve private port 8080'i hedeflemelidir.

Acceptance transaction'ı external olarak çalıştırın. Client NocoDB'ye hiç ulaşamıyorsa DNS ve certificate kontrolleri için SSL validation checklist sayfasını kullanın. Request NocoDB'ye ulaşıyor ancak metadata database erişilemiyor veya public URL'ler internal bir host'u gösteriyorsa proxy redirect'lerini değiştirmeyi bırakın ve bunun yerine application-specific boundary'yi inceleyin.

NocoDB restore sürecini launch öncesinde tasarlayın

NocoDB için recovery point ve recovery time hedeflerini metadata database, attachment'lar ve external source database'ler üzerinden tanımlayın. Bootstrap öncesinde /usr/app/data'yı mount edin, zararsız sample data yazın ve bu path'in gerçekten persistent olduğunu doğrulamak için container'ı değiştirin. Named volume redeploy sonrasında kalıcılığı çözer; ancak compromise veya server kaybını çözmez.

Temiz bir restore ortamı oluşturun, aynı pinned application version'ı kullanın ve bağlı veritabanındaki satırları değiştirmeden base'lerin, view'ların, role'lerin, attachment'ların ve source mapping'lerin geri geldiğini doğrulayın. Komutları, ownership düzeltmelerini ve geçen süreyi kaydedin. Backup guide iyi bir standarttır: Bir backup, upload edildikten sonra değil restore edildikten sonra güvenilir kabul edilir.

NocoDB'ye özgü security kararları

İlk trusted administrator oluşturulur oluşturulmaz bootstrap window'u kapatın. NocoDB'deki somut risk, zayıf bir JWT secret'ı yeniden kullanmak veya base credential'larını her editor'a açmaktır; daha güvenli sınır, stable bir JWT secret kullanmak, external data-source connection oluşturabilecek kişileri sınırlandırmak ve shared-view erişimini gözden geçirmektir.

NC_AUTH_JWT_SECRET değerini uzun ve random bir değer olarak oluşturun; bu değeri rotate etmek normalde session'ları veya token'ları geçersiz kılar. Bu nedenle işlemi encryption migration gibi değerlendirmek yerine kullanıcı etkisini planlayın. Private network dependency credential'larını taşımalı, NocoDB içindeki role'ler ise gerekli en küçük action'ı vermelidir. Hassas request body'lerini ve provider response'larını rutin log'lara yazmayın.

Capacity ve upgrade kontrolleri

Green bir container gerekli olsa da yeterli değildir. Service-level indicator, “geçici bir source database'e bağlanmak, bir grid ve filtrelenmiş bir view oluşturmak, bir satırı düzenlemek, bir attachment eklemek ve REST API'yi çağırmak” işleminin başarıyla tamamlanmasıdır. Olası pressure signal'ları ise row count, attachment trafiği, metadata database latency'si ve eş zamanlı grid kullanıcılarıdır.

Change control önemlidir; çünkü underlying source database'e dokunulmasa bile metadata migration'ları view'ları ve automation'ları etkileyebilir. Eski image'ı koruyun, migration'ları kopyalanmış state üzerinde test edin ve schema değişikliğinden sonra rollback'in desteklenip desteklenmediğini belgeleyin. Metadata database erişilemiyorsa veya public URL'ler internal bir host'u gösteriyorsa çalışan ortamdan farklılık gösteren ilk boundary'yi teşhis edin.

NocoDB için production acceptance çalıştırması

Gerçek kullanıcılar gelmeden önce NocoDB için bir release worksheet hazırlayın. Bu worksheet pinned image'ı, port 8080'i, canonical origin'i, persistent path'leri ve geçici bir local file yerine production metadata için PostgreSQL veya MySQL'in owner'ını belirtmelidir. Şu transaction'ın beklenen sonucunu da ekleyin: geçici bir source database'e bağlanmak, bir grid ve filtrelenmiş bir view oluşturmak, bir satırı düzenlemek, bir attachment eklemek ve REST API'yi çağırmak.

Worksheet'i normal bir replacement sonrasında ve temiz bir restore sonrasında kullanın. Recovery yalnızca base'ler, view'lar, role'ler, attachment'lar ve source mapping'ler bağlı veritabanındaki satırlar değiştirilmeden geri geldiğinde kabul edilir. Ayrıca row count, attachment trafiği, metadata database latency'si ve eş zamanlı grid kullanıcılarını kapsayan kısa bir resource trace toplayın; gelecekteki capacity değişikliklerini aynı workload ile karşılaştırabilmek için bunu release'in yanında saklayın.

Kontrollü bir failure da ekleyin: geçici olarak test identity'sinin geçici bir local file yerine production metadata için kullanılan PostgreSQL veya MySQL'e erişimini engelleyin. NocoDB'nin sorunu doğru boundary'de raporladığını doğrulayın, geçerli koşulu geri yükleyin ve transaction'ı yeniden çalıştırın. Bu işlem yalnızca başarıyı değil, error visibility'yi de kontrol eder ve sağlıklı görünen bir arayüzün bozuk bir worker'ı, callback'i veya database connection'ını gizlemesini önler.

Dockup, NocoDB için hangi işleri ortadan kaldırır?

NocoDB için Dockup, bir image ile durable service arasındaki boundary'de en fazla faydayı sağlar. Compute Dockup'a veya bağladığınız server'a ait olsa da container replacement'ları boyunca 8080 route'unu, TLS'i, secret değerlerini ve storage'ı birlikte korur.

Application bilgisiyle süreci tamamlayın: NC_PUBLIC_URL değerini canonical HTTPS adresine ayarlayın; geçici bir local file yerine production metadata için PostgreSQL veya MySQL'e bağlanıp test edin; ardından şu doğrulamayı çalıştırın: geçici bir source database'e bağlanın, bir grid ve filtrelenmiş bir view oluşturun, bir satırı düzenleyin, bir attachment ekleyin ve REST API'yi çağırın. Sonucu bir deployment check olarak saklayın; böylece bir sonraki image update'i container status'a göre değil, davranışa göre değerlendirilir.

Sık sorulan sorular

NocoDB'nin production deployment için neye ihtiyacı vardır?

NocoDB container'ını port 8080 üzerinden tek bir HTTPS origin'e route edin. Supporting network requirement, geçici bir local file yerine production metadata için PostgreSQL veya MySQL kullanılmasıdır. Geçici bir source database'e bağlanıp bir grid ve filtrelenmiş bir view oluşturamadığınız, bir satırı düzenleyemediğiniz, bir attachment ekleyemediğiniz ve REST API'yi çağıramadığınız sürece NocoDB'yi hazır kabul etmeyin.

NocoDB'deki hangi veriler backup'a dahil edilmelidir?

/usr/app/data'yı persistent hâle getirin ve metadata database'i, attachment'ları ve external source database'leri aynı recovery manifest'ine dahil edin. Temiz bir NocoDB restore işlemi yalnızca base'ler, view'lar, role'ler, attachment'lar ve source mapping'ler bağlı veritabanındaki satırlar değiştirilmeden geri geldiğinde başarılı kabul edilir.

NocoDB, reverse proxy arkasında HTTPS gerektirir mi?

Public NocoDB origin'i için HTTPS kullanın ve port 8080'i internal route üzerinde tutun. NocoDB ayarını doğru şekilde uygulayın: NC_PUBLIC_URL değerini canonical HTTPS adresine ayarlayın. NocoDB için HTTPS, credential'ları veya kullanıcı içeriğini transit sırasında korur ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

NocoDB upgrade'i nasıl test edilmelidir?

Mevcut NocoDB state'ini isolated bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ı tekrarlayın. Underlying source database'e dokunulmasa bile metadata migration'ları view'ları ve automation'ları etkileyebileceği için özellikle dikkatli olun. Data migration ve rollback boundary'leri anlaşılana kadar önceki NocoDB image'ını saklayın.