Sådan self-hoster du Baserow i 2026: Data, URL'er og backups samlet ét sted

En Baserow-container kan være grøn, selv om den funktion, brugerne er afhængige af, er gået i stykker. For Baserow er den skjulte fejl typisk, at den offentlige URL ændres, efter at brugerne har genereret share- og callback-links. Denne guide bruger følgende som acceptancetest: “opret en database og en visning, importér en CSV-fil, redigér rækker fra to sessioner, og upload en fil, før du genstarter all-in-one-stakken” — og bygger deploymentet baglæns ud fra det resultat.

Baserow har en specifik rolle i stacken: Airtable-lignende databaser understøttet af Postgres og Redis. Produktionsspørgsmålet er derfor ikke, om port 80 svarer én gang, men om state, dependencies og den offentlige adresse fortsat stemmer overens efter en genstart, opdatering og restore.

Hvad Baserow afhænger af

Proces-health og produkt-health er to forskellige ting i Baserow. Port 80 kan godt svare, selv om den brugerrettede transaktion stadig fejler. Det lokale runtime-krav er tilstrækkelig hukommelse til den inkluderede Postgres, Redis, backend og workers. Gør livscyklussen eksplicit, så flytning af Baserow mellem hosts ikke ændrer funktionaliteten ubemærket.

Brug denne readiness-test efter væsentlige konfigurationsændringer: opret en database og en visning, importér en CSV-fil, redigér rækker fra to sessioner, og upload en fil, før du genstarter all-in-one-stakken. Hold dyre eksterne checks ude af liveness probes, så et nedbrud hos en provider ikke udløser en restart loop. Kapacitetsarbejdet bør følge den inkluderede Postgres, Redis, Celery workers, antal rækker, importstørrelse og antal samtidige redaktører, da det ligger tættere på Baserows reelle belastning end page requests.

Et Docker-baseline for Baserow

Følgende kommando gør containergrænsen synlig uden at foregive, at alle eksterne services bliver provisioneret.

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

Før du åbner for ingress, skal du inspicere det resolverede miljø, mounts og listeneren. Bekræft det lokale krav før eksponering: tilstrækkelig hukommelse til den inkluderede Postgres, Redis, backend og workers. En vellykket opstart er først gennemført, når du kan oprette en database og en visning, importere en CSV-fil, redigere rækker fra to sessioner og uploade en fil, før du genstarter all-in-one-stakken — ikke når docker ps skriver Up.

Domæner, proxy headers og port 80

Eksponér ét HTTPS-hostname til Baserow, og hold den rå port 80 privat. Sæt BASEROW_PUBLIC_URL til den præcise eksterne origin. Det forhindrer browsere og API-klienter i at opdage to konkurrerende adresser.

Kør den kendte, velfungerende transaktion fra en ren klient, og inspicér den første request, der fejler. Brug guiden til custom domains, når DNS eller TLS er forkert. Betragt “den offentlige URL ændres, efter at brugerne har genereret share- og callback-links” som en separat applikationsdiagnose, når routen er bekræftet.

Tag backup af den state, Baserow ikke kan genskabe

Definér recovery point og recovery time for Baserow ud fra hele /baserow/data-træet og periodiske logiske databaseeksporter. Mount /baserow/data før bootstrap, skriv harmløse eksempeldata, og erstat containeren for at bevise, at stien faktisk er persistent. Et named volume løser persistence ved redeploy; det løser ikke et sikkerhedsbrud eller tab af serveren.

Opbyg et rent restore-miljø, brug den samme pinned application-version, og bevis, at tabeller, visninger, brugere, automatiseringer og filer kommer tilbage fra den komplette /baserow/data-backup. Notér kommandoer, ændringer af ejerskab og den forløbne tid. Backup-guiden er en nyttig standard: En backup er først til at stole på efter en restore — ikke efter en upload.

Giv ikke Baserow hele hosten

Lav en threat model for den handling, Baserow udfører — ikke kun for login-formularen. Den største risiko her er at bruge all-in-one-imaget uden en backup-plan for de inkluderede services. Implementér denne afgrænsning: Luk for registrering, når det er relevant, bevar SECRET_KEY, og begræns offentlige shared views til de tiltænkte data.

Generér SECRET_KEY én gang, hold den ude af Git, og bevar den sammen med recovery-manifestet, fordi en ændring kan ugyldiggøre krypteret eller signeret application state. Løs ikke en permission-fejl ved at køre containeren som root eller mounte hosten bredt. Resource limits hører også til i sikkerhedsdesignet, når brugere kan udløse belastning på den inkluderede Postgres, Redis, Celery workers, antal rækker, importstørrelse og antal samtidige redaktører.

Logs, der besvarer det næste spørgsmål

Et idle health check siger ikke meget om Baserow. Hold øje med den inkluderede Postgres, Redis, Celery workers, antal rækker, importstørrelse og antal samtidige redaktører, og alert på det symptom, brugerne oplever: at handlingen “opret en database og en visning, importér en CSV-fil, redigér rækker fra to sessioner, og upload en fil, før du genstarter all-in-one-stakken” fejler. Hold liveness lokal og billig; lad readiness rapportere migrations eller initialisering uden at forårsage en restart storm.

Det risikable område ved upgrades er, at all-in-one-imaget flytter flere services samlet, så database- og application-migrations kræver en rehearsal baseret på snapshots. Læs release notes, tag et snapshot af state, deploy målversionen mod en restored kopi, og gentag acceptance-handlingen. Hvis den offentlige URL ændres, efter at brugerne har genereret share- og callback-links, skal du korrelere client-requesten med den første relevante application log i stedet for blindt at slette state eller tilføje redirects.

Fem checks, der er stærkere end container-health

Før de rigtige brugere kommer til, skal du udarbejde et release-worksheet for Baserow. Det skal angive det pinned image, port 80, den kanoniske origin, persistente stier og ejeren af den tilstrækkelige hukommelse til den inkluderede Postgres, Redis, backend og workers. Vedlæg det forventede resultat af denne transaktion: opret en database og en visning, importér en CSV-fil, redigér rækker fra to sessioner, og upload en fil, før du genstarter all-in-one-stakken.

Brug worksheetet efter en normal replacement og efter en clean restore. Recovery accepteres kun, hvis tabeller, visninger, brugere, automatiseringer og filer kommer tilbage fra den komplette /baserow/data-backup. Indsaml også et kort resource trace, der dækker den inkluderede Postgres, Redis, Celery workers, antal rækker, importstørrelse og antal samtidige redaktører; opbevar det sammen med releasen, så fremtidige kapacitetsændringer kan sammenlignes med den samme workload.

Inkludér én kontrolleret fejl: indsend harmløst input tæt på den ressource- eller formatgrænse, der er knyttet til denne afgrænsning: den offentlige URL ændres, efter at brugerne har genereret share- og callback-links. Bekræft, at Baserow rapporterer problemet ved den korrekte grænse, genskab den gyldige tilstand, og kør transaktionen igen. Det tester synligheden af fejl — ikke kun succes — og forhindrer, at en health-looking grænseflade skjuler en defekt worker, callback eller databaseforbindelse.

Knyt Baserow til Dockups lifecycle

Dockups one-click-deployment af Baserow skal gøre replacement sikkert: Routen skal fortsat pege på 80, secrets må ikke være baked ind i imaget, og persistente stier skal være tilgængelige i den nye container. Det samme deployment kan køre på Dockup compute eller på en tilknyttet maskine.

Afslut det app-specifikke arbejde ved at bekræfte det lokale krav — tilstrækkelig hukommelse til den inkluderede Postgres, Redis, backend og workers — anvende den kanoniske offentlige adresse og køre denne acceptance check: opret en database og en visning, importér en CSV-fil, redigér rækker fra to sessioner, og upload en fil, før du genstarter all-in-one-stakken. Tilføj restore-resultatet til runbooken, før de rigtige brugere kommer til.

Ofte stillede spørgsmål

Hvad kræver Baserow til en production deployment?

Route Baserow-containeren på port 80 gennem én HTTPS-origin. Det lokale runtime-krav er tilstrækkelig hukommelse til den inkluderede Postgres, Redis, backend og workers. Kald ikke Baserow klar, før du kan oprette en database og en visning, importere en CSV-fil, redigere rækker fra to sessioner og uploade en fil, før du genstarter all-in-one-stakken.

Hvilke Baserow-data skal med i en backup?

Gør /baserow/data persistent, og inkludér hele /baserow/data-træet samt periodiske logiske databaseeksporter i det samme recovery-manifest. En clean Baserow-restore er først godkendt, når tabeller, visninger, brugere, automatiseringer og filer kommer tilbage fra den komplette /baserow/data-backup.

Kræver Baserow HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Baserow-origin, og hold port 80 på den interne route. Anvend Baserow-indstillingen korrekt: Sæt BASEROW_PUBLIC_URL til den præcise eksterne origin. For Baserow beskytter HTTPS credentials eller brugerindhold under transport og holder origin-afhængig client-adfærd konsistent.

Hvordan bør en Baserow-opgradering testes?

Restore den aktuelle Baserow-state til et isoleret deployment, anvend kandidatversionen, og gentag den tilhørende acceptance-transaktion. Vær særligt opmærksom, fordi all-in-one-imaget flytter flere services samlet, så database- og application-migrations kræver en rehearsal baseret på snapshots. Behold den tidligere Baserow-version, indtil grænsen for datamigration og rollback er forstået.