Jak hostovat Baserow na vlastním serveru v roce 2026: data, URL a zálohy v jednom

Kontejner Baserow může být ve stavu green, i když nefunguje to, na čem uživatelům skutečně záleží. U Baserow se tato skrytá chyba obvykle projeví tak, že se po vygenerování odkazů pro sdílení a callbacků změní veřejná URL. Tato příručka považuje za akceptační test následující scénář: „vytvořit databázi a view, importovat CSV, upravit řádky ze dvou sessions a nahrát soubor před restartováním all-in-one stacku“. Nasazení pak staví zpětně od tohoto výsledku.

Baserow má ve stacku konkrétní roli: databáze ve stylu Airtable postavené na Postgresu a Redis. Produkční otázka proto nezní, zda port 80 jednou odpoví, ale zda budou stav, závislosti a veřejná adresa po restartu, aktualizaci a obnově stále ve vzájemném souladu.

Na čem Baserow závisí

Stav procesu a stav produktu jsou u Baserow dvě různé věci. Port 80 může odpovídat, zatímco transakce na straně uživatele stále selhává. Požadavkem lokálního runtime je dostatek paměti pro přibalený Postgres, Redis, backend a workery. Životní cyklus udržujte explicitní, aby přesun Baserow mezi hostiteli potichu nezměnil jeho chování.

Po významných změnách konfigurace použijte tento test připravenosti: vytvořte databázi a view, importujte CSV, upravte řádky ze dvou sessions a nahrajte soubor před restartováním all-in-one stacku. Nákladné externí kontroly ponechte mimo liveness probes, aby výpadek poskytovatele nezpůsobil restartovací smyčku. Při plánování kapacity sledujte přibalený Postgres, Redis, Celery workery, počet řádků, velikost importů a počet současně upravujících uživatelů. To lépe odpovídá skutečnému zatížení Baserow než požadavky na stránky.

Základní Docker konfigurace pro Baserow

Následující příkaz zpřehlední hranici kontejneru, aniž by předstíral zajištění všech externích služeb.

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

Před otevřením ingressu zkontrolujte výsledné proměnné prostředí, mounty a naslouchající port. Před vystavením služby ověřte lokální požadavek: dostatek paměti pro přibalený Postgres, Redis, backend a workery. Úspěšné spuštění je dokončeno až ve chvíli, kdy můžete vytvořit databázi a view, importovat CSV, upravit řádky ze dvou sessions a nahrát soubor před restartováním all-in-one stacku — nikoli ve chvíli, kdy docker ps vypíše Up.

Domény, proxy hlavičky a port 80

Pro Baserow vystavte jeden hostname s HTTPS a surový port 80 ponechte privátní. Nastavte BASEROW_PUBLIC_URL na přesný externí origin. Prohlížeče a API klienti tak nebudou získávat dvě konkurenční adresy.

Z čistého klienta spusťte ověřenou transakci a zkontrolujte první požadavek, který selže. Pokud je problém v DNS nebo TLS, použijte příručku pro vlastní doménu. Jakmile ověříte správné směrování, berte „po vygenerování odkazů pro sdílení a callbacků se změní veřejná URL“ jako samostatnou aplikační diagnózu.

Zálohujte stav, který Baserow nedokáže znovu vytvořit

Bod obnovy a dobu obnovy pro Baserow definujte s ohledem na celý strom /baserow/data a pravidelné logické exporty databáze. Připojte /baserow/data ještě před bootstrapem, zapište neškodná testovací data a nahraďte kontejner, abyste ověřili, že je tato cesta skutečně persistentní. Named volume řeší zachování dat při redeployi, neřeší však kompromitaci ani ztrátu serveru.

Připravte čisté prostředí pro obnovu, použijte stejnou připnutou verzi aplikace a ověřte, že se z kompletní zálohy /baserow/data vrátí tabulky, views, uživatelé, automations i soubory. Zaznamenejte příkazy, opravy vlastníka a uplynulý čas. Příručka k zálohování představuje užitečný standard: záloze lze důvěřovat až po obnově, ne po nahrání.

Nedávejte Baserow celý hostitel

Modelujte hrozby podle akcí, které Baserow provádí, ne pouze podle přihlašovacího formuláře. Zde je vysoce rizikovou chybou použití all-in-one image bez plánu zálohování jejích přibalených služeb. Nastavte tuto hranici: podle potřeby zavřete registraci, zachovejte SECRET_KEY a omezte veřejně sdílená views pouze na zamýšlená data.

SECRET_KEY vygenerujte jednou, uchovávejte ho mimo Git a zachovejte ho spolu s recovery manifestem, protože jeho změna může zneplatnit zašifrovaný nebo podepsaný stav aplikace. Chybu oprávnění neřešte spuštěním kontejneru jako root ani širokým připojením hostitele. Součástí bezpečnostního návrhu musí být také limity zdrojů, pokud mohou uživatelé vyvolat zatížení přibaleného Postgresu, Redis, Celery workerů, počtu řádků, velikosti importů a počtu současně upravujících uživatelů.

Logy, které zodpoví další otázku

Nečinný health check o Baserow mnoho neřekne. Sledujte přibalený Postgres, Redis, Celery workery, počet řádků, velikost importů a počet současně upravujících uživatelů a upozorňujte na symptom, který uživatelé skutečně zažívají: selhání akce „vytvořit databázi a view, importovat CSV, upravit řádky ze dvou sessions a nahrát soubor před restartováním all-in-one stacku“. Liveness udržujte lokální a nenáročnou; readiness může hlásit migrace nebo inicializaci, aniž by způsobila restartovací smyčku.

Rizikovou oblastí při aktualizaci je skutečnost, že all-in-one image přesouvá několik služeb najednou, takže migrace databáze a aplikace vyžadují nácvik na základě snapshotu. Přečtěte si release notes, vytvořte snapshot stavu, nasaďte cílovou verzi proti obnovené kopii a zopakujte akceptační akci. Pokud se po vygenerování odkazů pro sdílení a callbacků změní veřejná URL, propojte požadavek klienta s prvním relevantním aplikačním logem, místo abyste bezhlavě mazali stav nebo přidávali redirecty.

Pět kontrol, které jsou důkladnější než stav kontejneru

Před příchodem skutečných uživatelů vytvořte pro Baserow release worksheet. Musí v něm být uvedená připnutá image, port 80, kanonický origin, persistentní cesty a vlastník odpovědný za dostatek paměti pro přibalený Postgres, Redis, backend a workery. Připojte očekávaný výsledek této transakce: vytvořit databázi a view, importovat CSV, upravit řádky ze dvou sessions a nahrát soubor před restartováním all-in-one stacku.

Worksheet použijte po běžné náhradě kontejneru i po čisté obnově. Obnova je úspěšná pouze tehdy, pokud se z kompletní zálohy /baserow/data vrátí tabulky, views, uživatelé, automations a soubory. Shromážděte také krátký záznam o využití zdrojů zahrnující přibalený Postgres, Redis, Celery workery, počet řádků, velikost importů a počet současně upravujících uživatelů. Uchovávejte ho u release, aby bylo možné budoucí změny kapacity porovnávat se stejnou zátěží.

Zahrňte jedno řízené selhání: odešlete neškodný vstup blízko limitu zdrojů nebo formátu souvisejícího s touto hranicí: po vygenerování odkazů pro sdílení a callbacků se změní veřejná URL. Ověřte, že Baserow problém nahlásí na správné hranici, vraťte platnou konfiguraci a znovu spusťte transakci. Tím ověříte viditelnost chyby, nejen úspěšný průchod, a zabráníte tomu, aby zdravě vypadající rozhraní skrývalo nefunkčního workera, callback nebo připojení k databázi.

Zapojte Baserow do životního cyklu Dockup

One-click nasazení Baserow v Dockup by mělo zajistit bezpečnou náhradu: směrování bude i nadále mířit na port 80, secrets nebudou zapečené v image a persistentní cesty se vrátí v novém kontejneru. Stejné nasazení může běžet na výpočetní infrastruktuře Dockup nebo na připojeném stroji.

Aplikačně specifickou část dokončete ověřením lokálního požadavku — dostatku paměti pro přibalený Postgres, Redis, backend a workery, nastavením kanonické veřejné adresy a spuštěním tohoto akceptačního testu: vytvořit databázi a view, importovat CSV, upravit řádky ze dvou sessions a nahrát soubor před restartováním all-in-one stacku. Výsledek obnovy přidejte do runbooku ještě před příchodem skutečných uživatelů.

Často kladené otázky

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

Veďte kontejner Baserow přes port 80 na jeden HTTPS origin. Požadavkem lokálního runtime je dostatek paměti pro přibalený Postgres, Redis, backend a workery. Baserow nepovažujte za připravený, dokud nemůžete vytvořit databázi a view, importovat CSV, upravit řádky ze dvou sessions a nahrát soubor před restartováním all-in-one stacku.

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

Zajistěte persistentní /baserow/data a do stejného recovery manifestu zahrňte celý strom /baserow/data i pravidelné logické exporty databáze. Čistá obnova Baserow je úspěšná pouze tehdy, pokud se z kompletní zálohy /baserow/data vrátí tabulky, views, uživatelé, automations a soubory.

Vyžaduje Baserow za reverse proxy HTTPS?

Pro veřejný origin Baserow používejte HTTPS a port 80 ponechte v interním směrování. Správně použijte nastavení Baserow: nastavte BASEROW_PUBLIC_URL na přesný externí origin. U Baserow HTTPS chrání přihlašovací údaje nebo obsah uživatelů při přenosu a udržuje konzistentní chování klienta závislé na originu.

Jak testovat aktualizaci Baserow?

Obnovte aktuální stav Baserow do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte jeho akceptační transakci. Věnujte tomu zvláštní pozornost, protože all-in-one image přesouvá několik služeb najednou, takže migrace databáze a aplikace vyžadují nácvik na základě snapshotu. Předchozí image Baserow si ponechte, dokud nebudete mít jasno v hranici migrace dat a rollbacku.