2026'da Baserow Kendin Barındırma: Birleşik Veriler, URL'ler ve Yedekler

Bir Baserow container'ı yeşil durumda görünürken kullanıcıların önemsediği işlev çalışmıyor olabilir. Baserow'da bu gizli hata genellikle kullanıcılar paylaşım ve callback bağlantıları oluşturduktan sonra public URL'nin değişmesidir. Bu rehberde “bir veritabanı ve görünüm oluşturma, bir CSV içe aktarma, iki oturumdan satırları düzenleme ve all-in-one stack'i yeniden başlatmadan önce bir dosya yükleme” işlemlerini kabul testi olarak ele alıyor ve deployment'ı bu sonuca göre geriye doğru oluşturuyoruz.

Baserow'un stack içindeki rolü belirgindir: Postgres ve Redis tarafından desteklenen Airtable tarzı veritabanları. Bu nedenle production sorusu, port 80'in bir kez yanıt verip vermediği değil; restart, update ve restore sonrasında state'in, bağımlılıkların ve public adresin uyumlu kalıp kalmadığıdır.

Baserow'un bağımlılıkları

Baserow için process health ile product health birbirinden ayrıdır. Kullanıcıya sunulan işlem hâlâ başarısızken port 80 yanıt verebilir. Yerel runtime gereksinimi; bundled Postgres, Redis, backend ve worker'lar için yeterli bellektir. Baserow'u host'lar arasında taşırken davranışın sessizce değişmemesi için lifecycle'ını açıkça yönetin.

Anlamlı configuration değişikliklerinden sonra şu readiness çalışmasını kullanın: bir veritabanı ve görünüm oluşturun, bir CSV içe aktarın, iki oturumdan satırları düzenleyin ve all-in-one stack'i yeniden başlatmadan önce bir dosya yükleyin. Pahalı external check'leri liveness probe'larından uzak tutun; böylece bir provider kesintisi restart loop'a neden olmaz. Capacity çalışmalarında bundled Postgres, Redis, Celery worker'ları, satır sayısı, import boyutu ve eş zamanlı editörleri izleyin. Bu ölçütler, Baserow'un gerçek yükünü page request'lerden daha doğru yansıtır.

Baserow için Docker temeli

Aşağıdaki komut, her external service'i provision ediyormuş gibi davranmadan container sınırını görünür kılar.

docker run -d \
  --name baserow \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v baserow-data:/baserow/data \
  -e SECRET_KEY=replace-with-a-long-random-value \
  baserow/baserow:latest

Ingress'i açmadan önce çözümlenmiş environment'ı, mount'ları ve listener'ı inceleyin. Dışarı açmadan önce yerel gereksinimi doğrulayın: bundled Postgres, Redis, backend ve worker'lar için yeterli bellek. Başarılı launch, docker ps çıktısında Up görülmesiyle değil; bir veritabanı ve görünüm oluşturabildiğiniz, bir CSV içe aktarabildiğiniz, iki oturumdan satırları düzenleyebildiğiniz ve all-in-one stack'i yeniden başlatmadan önce bir dosya yükleyebildiğiniz noktada tamamlanır.

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

Baserow için tek bir HTTPS hostname'i dışarı açın; ham port 80'i private tutun. BASEROW_PUBLIC_URL değerini tam external origin olarak ayarlayın. Böylece browser'ların ve API client'larının birbiriyle yarışan iki farklı adres öğrenmesi engellenir.

Temiz bir client'tan doğrulanmış işlemi çalıştırın ve başarısız olan ilk request'i inceleyin. DNS veya TLS hatalıysa custom-domain rehberini kullanın. Route doğrulandıktan sonra “kullanıcılar paylaşım ve callback bağlantıları oluşturduktan sonra public URL değişiyor” durumunu ayrı bir application teşhisi olarak ele alın.

Baserow'un yeniden oluşturamayacağı state'i yedekleyin

Baserow için recovery point ve recovery time hedeflerini, tüm /baserow/data ağacı ve periyodik logical database export'ları üzerinden tanımlayın. Bootstrap işleminden önce /baserow/data'yı mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Named volume redeploy sonrasında persistence sorununu çözer; compromise veya server kaybını çözmez.

Temiz bir restore environment'ı oluşturun, aynı pinned application version'ı kullanın ve tabloların, görünümlerin, kullanıcıların, automation'ların ve dosyaların eksiksiz /baserow/data yedeğinden geri geldiğini kanıtlayın. Komutları, ownership düzeltmelerini ve geçen süreyi kaydedin. Yedekleme rehberi yararlı bir standart sunar: bir yedeğe upload edildikten sonra değil, restore edildikten sonra güvenilir gözüyle bakılır.

Baserow'a tüm host'u vermeyin

Yalnızca login formunu değil, Baserow'un gerçekleştirdiği işlemi threat model'leyin. Buradaki yüksek riskli hata, bundled service'leri için bir yedekleme planı olmadan all-in-one image kullanmaktır. Şu sınırı uygulayın: gerektiğinde registration'ı kapatın, SECRET_KEY'i koruyun ve public shared view'ları yalnızca amaçlanan verilerle sınırlayın.

SECRET_KEY'i bir kez oluşturun, Git dışında tutun ve recovery manifest ile birlikte koruyun; bu anahtarı değiştirmek encrypted veya signed application state'i geçersiz kılabilir. Bir permission hatasını container'ı root olarak çalıştırarak veya host'u geniş kapsamlı mount ederek çözmeye çalışmayın. Bundled Postgres, Redis, Celery worker'ları, satır sayısı, import boyutu ve eş zamanlı editörler kullanıcılar tarafından tetiklenebildiğinde resource limit'leri de security design'ın parçasıdır.

Sonraki soruyu yanıtlayan log'lar

Boşta çalışan bir health check, Baserow hakkında çok az bilgi verir. Bundled Postgres, Redis, Celery worker'ları, satır sayısı, import boyutu ve eş zamanlı editörleri izleyin; ardından kullanıcıların deneyimlediği belirti için alarm üretin: “bir veritabanı ve görünüm oluşturma, bir CSV içe aktarma, iki oturumdan satırları düzenleme ve all-in-one stack'i yeniden başlatmadan önce bir dosya yükleme” işleminin başarısız olması. Liveness'ı yerel ve düşük maliyetli tutun; readiness migration veya initialization durumunu bildirsin, ancak restart storm başlatmasın.

Riskli upgrade alanı, all-in-one image'ın birkaç service'i birlikte taşımasıdır; bu nedenle database ve application migration'ları snapshot tabanlı bir rehearsal gerektirir. Release note'ları okuyun, state'in snapshot'ını alın, target version'ı restore edilmiş bir kopya üzerinde deploy edin ve kabul işlemini tekrarlayın. Kullanıcılar paylaşım ve callback bağlantıları oluşturduktan sonra public URL değişiyorsa, state'i silmek veya gelişigüzel redirect eklemek yerine client request'ini ilgili ilk application log'u ile ilişkilendirin.

Container health'ten daha güçlü beş kontrol

Gerçek kullanıcılar gelmeden önce Baserow için bir release worksheet hazırlayın. Bu belgede pinned image, port 80, canonical origin, kalıcı path'ler ve bundled Postgres, Redis, backend ve worker'lar için yeterli belleğin sorumlusu açıkça belirtilmelidir. Şu işlemin beklenen sonucunu ekleyin: bir veritabanı ve görünüm oluşturma, bir CSV içe aktarma, iki oturumdan satırları düzenleme ve all-in-one stack'i yeniden başlatmadan önce bir dosya yükleme.

Worksheet'i normal bir replacement sonrasında ve temiz bir restore sonrasında kullanın. Recovery yalnızca tablolar, görünümler, kullanıcılar, automation'lar ve dosyalar eksiksiz /baserow/data yedeğinden geri geldiğinde kabul edilir. Ayrıca bundled Postgres, Redis, Celery worker'ları, satır sayısı, import boyutu ve eş zamanlı editörleri 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: bu sınırla ilişkili resource veya format limitine yakın, zararsız bir input gönderin: kullanıcılar paylaşım ve callback bağlantıları oluşturduktan sonra public URL değişiyor. Baserow'un sorunu doğru boundary'de raporladığını doğrulayın, geçerli koşulu geri yükleyin ve işlemi yeniden çalıştırın. Bu kontrol yalnızca başarıyı değil, error visibility'yi de sınar ve sağlıklı görünen bir arayüzün bozuk bir worker'ı, callback'i veya database connection'ı gizlemesini önler.

Baserow'u Dockup lifecycle'ına bağlayın

Dockup'un one-click Baserow deployment'ı replacement işlemini güvenli hâle getirmelidir: route 80'i hedeflemeye devam eder, secret'lar image içine gömülmez ve kalıcı path'ler yeni container'da geri gelir. Aynı deployment, Dockup compute veya bağlı bir makinede çalışabilir.

App'e özgü işlemleri, yerel gereksinimi — bundled Postgres, Redis, backend ve worker'lar için yeterli bellek — doğrulayarak, canonical public address'i uygulayarak ve şu kabul kontrolünü çalıştırarak tamamlayın: bir veritabanı ve görünüm oluşturun, bir CSV içe aktarın, iki oturumdan satırları düzenleyin ve all-in-one stack'i yeniden başlatmadan önce bir dosya yükleyin. Gerçek kullanıcılar gelmeden önce restore sonucunu runbook'a ekleyin.

Sık sorulan sorular

Production deployment için Baserow'un neye ihtiyacı vardır?

Baserow container'ını port 80 üzerinden tek bir HTTPS origin'e yönlendirin. Yerel runtime gereksinimi; bundled Postgres, Redis, backend ve worker'lar için yeterli bellektir. Bir veritabanı ve görünüm oluşturamıyor, bir CSV içe aktaramıyor, iki oturumdan satırları düzenleyemiyor ve all-in-one stack'i yeniden başlatmadan önce bir dosya yükleyemiyorsanız Baserow'u hazır kabul etmeyin.

Hangi Baserow verileri yedeğe dahil edilmelidir?

/baserow/data'yı kalıcı hâle getirin ve tüm /baserow/data ağacını, periyodik logical database export'larıyla birlikte aynı recovery manifest'e dahil edin. Temiz bir Baserow restore işlemi yalnızca tablolar, görünümler, kullanıcılar, automation'lar ve dosyalar eksiksiz /baserow/data yedeğinden geri geldiğinde başarılı sayılır.

Baserow'un reverse proxy arkasında HTTPS kullanması gerekir mi?

Public Baserow origin için HTTPS kullanın ve port 80'i internal route üzerinde tutun. Baserow ayarını doğru uygulayın: BASEROW_PUBLIC_URL değerini tam external origin olarak ayarlayın. Baserow için HTTPS, credentials veya kullanıcı içeriğinin transit sırasında korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Baserow upgrade'i nasıl test edilmelidir?

Mevcut Baserow state'ini izole bir deployment'a restore edin, aday version'ı uygulayın ve kabul işlemini tekrarlayın. All-in-one image birkaç service'i birlikte taşıdığı için özellikle dikkatli olun; database ve application migration'ları snapshot tabanlı bir rehearsal gerektirir. Data migration ve rollback sınırları anlaşılana kadar önceki Baserow image'ını koruyun.