Baserow zelf hosten in 2026: complete data-, URL- en back-upgids

Een Baserow-container kan groen zijn terwijl de taak die gebruikers belangrijk vinden niet werkt. Bij Baserow is de verborgen fout meestal dat de openbare URL verandert nadat gebruikers deel- en callbacklinks hebben gegenereerd. In deze handleiding geldt de volgende controle als acceptatietest: “maak een database en weergave, importeer een CSV, bewerk rijen vanuit twee sessies en upload een bestand voordat je de all-in-one-stack opnieuw start”. De deployment wordt vanuit dat resultaat terug opgebouwd.

Baserow heeft een specifieke rol in de stack: databases in Airtable-stijl, ondersteund door Postgres en Redis. De vraag voor productie is daarom niet of poort 80 eenmalig antwoord geeft, maar of state, dependencies en het openbare adres na een herstart, update en restore met elkaar blijven overeenkomen.

Waar Baserow van afhankelijk is

Procesgezondheid en productgezondheid zijn bij Baserow twee verschillende zaken. Poort 80 kan antwoorden terwijl de transactie aan de gebruikerskant nog steeds mislukt. De lokale runtimevereiste is voldoende geheugen voor de meegeleverde Postgres, Redis, backend en workers. Houd de lifecycle expliciet, zodat het verplaatsen van Baserow tussen hosts niet ongemerkt het gedrag verandert.

Gebruik deze readiness-oefening na belangrijke configuratiewijzigingen: maak een database en weergave, importeer een CSV, bewerk rijen vanuit twee sessies en upload een bestand voordat je de all-in-one-stack opnieuw start. Houd dure externe controles buiten liveness probes, zodat een storing bij een provider geen restart-loop veroorzaakt. Houd bij capaciteitsplanning rekening met de meegeleverde Postgres, Redis, Celery-workers, het aantal rijen, de importgrootte en het aantal gelijktijdige editors. Dat komt dichter in de buurt van de werkelijke belasting van Baserow dan pagina-aanvragen.

Een Docker-baseline voor Baserow

Met de volgende opdracht maak je de containergrens zichtbaar, zonder te doen alsof alle externe services hiermee worden geprovisioned.

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

Controleer voordat je ingress openstelt de opgeloste environment, mounts en listener. Bevestig de lokale vereiste vóór blootstelling: voldoende geheugen voor de meegeleverde Postgres, Redis, backend en workers. Een geslaagde launch is pas voltooid wanneer je een database en weergave kunt maken, een CSV kunt importeren, rijen vanuit twee sessies kunt bewerken en een bestand kunt uploaden voordat je de all-in-one-stack opnieuw start — niet wanneer docker ps Up weergeeft.

Domeinen, proxyheaders en poort 80

Stel één HTTPS-hostname voor Baserow beschikbaar en houd de kale poort 80 privé. Stel BASEROW_PUBLIC_URL in op de exacte externe origin. Zo voorkom je dat browsers en API-clients twee concurrerende adressen leren kennen.

Voer vanaf een schone client de bekende goede transactie uit en inspecteer het eerste verzoek dat mislukt. Gebruik de handleiding voor aangepaste domeinen wanneer DNS of TLS niet goed werkt. Beschouw “de openbare URL verandert nadat gebruikers deel- en callbacklinks hebben gegenereerd” als een afzonderlijke applicatiediagnose zodra de route is bewezen.

Maak een back-up van de state die Baserow niet kan reconstrueren

Definieer het recovery point en de recovery time voor Baserow aan de hand van de volledige /baserow/data-structuur en periodieke logical database exports. Mount /baserow/data vóór de bootstrap, schrijf ongevaarlijke testdata en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Een named volume lost persistence bij redeployment op; het beschermt niet tegen een compromise of verlies van de server.

Bouw een schone restoreomgeving, gebruik dezelfde vastgezette applicatieversie en bewijs dat tabellen, weergaven, gebruikers, automatiseringen en bestanden terugkomen uit de volledige /baserow/data-back-up. Leg opdrachten, fixes voor eigenaarschap en de verstreken tijd vast. De handleiding voor back-ups is een nuttige standaard: een back-up is pas betrouwbaar na een restore, niet na het uploaden ervan.

Geef Baserow niet de hele host

Maak een threat model van de acties die Baserow uitvoert, niet alleen van het loginformulier. De fout met het hoogste risico is hier het gebruik van de all-in-one-image zonder back-upplan voor de meegeleverde services. Implementeer deze grens: sluit registratie wanneer dat passend is, bewaar SECRET_KEY en beperk openbare gedeelde weergaven tot de bedoelde data.

Genereer SECRET_KEY één keer, houd deze buiten Git en bewaar hem samen met het recoverymanifest, omdat wijzigen ervan versleutelde of ondertekende applicatiestate ongeldig kan maken. Los een permission error niet op door de container als root uit te voeren of de host breed te mounten. Resource limits maken ook deel uit van het securityontwerp wanneer gebruikers de meegeleverde Postgres, Redis, Celery-workers, het aantal rijen, de importgrootte en het aantal gelijktijdige editors kunnen belasten.

Logs die de volgende vraag beantwoorden

Een inactieve health check zegt weinig over Baserow. Houd de meegeleverde Postgres, Redis, Celery-workers, het aantal rijen, de importgrootte en het aantal gelijktijdige editors in de gaten en geef een alert op het symptoom dat gebruikers ervaren: het mislukken van de actie “maak een database en weergave, importeer een CSV, bewerk rijen vanuit twee sessies en upload een bestand voordat je de all-in-one-stack opnieuw start”. Houd liveness lokaal en goedkoop; laat readiness migraties of initialisatie rapporteren zonder een restart storm te veroorzaken.

Het risicovolle upgradegebied is dat de all-in-one-image meerdere services tegelijk verplaatst. Daarom moeten database- en applicatiemigraties worden geoefend op basis van snapshots. Lees de release notes, maak een snapshot van de state, deploy de doelversie tegen een herstelde kopie en herhaal de acceptatieactie. Als de openbare URL verandert nadat gebruikers deel- en callbacklinks hebben gegenereerd, breng je het clientverzoek in verband met het eerste relevante applicatielogboek in plaats van blind state te verwijderen of redirects toe te voegen.

Vijf controles die sterker zijn dan container health

Maak vóór de komst van echte gebruikers een releasewerkblad voor Baserow. Daarin moeten de vastgezette image, poort 80, canonical origin, persistente paden en de eigenaar van voldoende geheugen voor de meegeleverde Postgres, Redis, backend en workers worden benoemd. Voeg het verwachte resultaat van deze transactie toe: maak een database en weergave, importeer een CSV, bewerk rijen vanuit twee sessies en upload een bestand voordat je de all-in-one-stack opnieuw start.

Gebruik het werkblad na een normale vervanging en na een schone restore. Recovery wordt alleen geaccepteerd als tabellen, weergaven, gebruikers, automatiseringen en bestanden terugkomen uit de volledige /baserow/data-back-up. Verzamel ook een korte resource trace voor de meegeleverde Postgres, Redis, Celery-workers, het aantal rijen, de importgrootte en het aantal gelijktijdige editors. Bewaar die naast de release, zodat toekomstige capaciteitswijzigingen met dezelfde workload kunnen worden vergeleken.

Voeg één gecontroleerde fout toe: dien ongevaarlijke input in die dicht bij de resource- of formatlimiet voor deze grens komt: de openbare URL verandert nadat gebruikers deel- en callbacklinks hebben gegenereerd. Controleer of Baserow het probleem op de juiste grens rapporteert, herstel de geldige toestand en voer de transactie opnieuw uit. Hiermee test je de zichtbaarheid van fouten, niet alleen succes, en voorkom je dat een gezond ogende interface een defecte worker, callback of databaseverbinding verbergt.

Koppel Baserow aan de lifecycle van Dockup

De one-click Baserow-deployment van Dockup moet vervanging veilig maken: de route blijft naar 80 verwijzen, secrets worden niet in de image ingebakken en persistente paden komen terug op de nieuwe container. Dezelfde deployment kan op Dockup-compute of op een gekoppelde machine draaien.

Rond het app-specifieke werk af door de lokale vereiste te bevestigen — voldoende geheugen voor de meegeleverde Postgres, Redis, backend en workers — het canonical public address toe te passen en deze acceptatiecontrole uit te voeren: maak een database en weergave, importeer een CSV, bewerk rijen vanuit twee sessies en upload een bestand voordat je de all-in-one-stack opnieuw start. Voeg het restore-resultaat aan het runbook toe voordat echte gebruikers arriveren.

Veelgestelde vragen

Wat heeft Baserow nodig voor een productiedeployment?

Routeer de Baserow-container via poort 80 door één HTTPS-origin. De lokale runtimevereiste is voldoende geheugen voor de meegeleverde Postgres, Redis, backend en workers. Noem Baserow pas gereed wanneer je een database en weergave kunt maken, een CSV kunt importeren, rijen vanuit twee sessies kunt bewerken en een bestand kunt uploaden voordat je de all-in-one-stack opnieuw start.

Welke Baserow-data hoort in een back-up?

Maak /baserow/data persistent en neem de volledige /baserow/data-structuur en periodieke logical database exports op in hetzelfde recoverymanifest. Een schone Baserow-restore is pas geslaagd wanneer tabellen, weergaven, gebruikers, automatiseringen en bestanden terugkomen uit de volledige /baserow/data-back-up.

Heeft Baserow HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de openbare Baserow-origin en houd poort 80 op de interne route. Pas de Baserow-instelling correct toe: stel BASEROW_PUBLIC_URL in op de exacte externe origin. Voor Baserow beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het ervoor dat origingevoelig clientgedrag consistent blijft.

Hoe moet een Baserow-upgrade worden getest?

Restore de huidige Baserow-state naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let extra goed op, omdat de all-in-one-image meerdere services tegelijk verplaatst en database- en applicatiemigraties daarom op basis van snapshots moeten worden geoefend. Bewaar de vorige Baserow-image totdat de grenzen voor datamigratie en rollback duidelijk zijn.