Slik hoster du Baserow selv i 2026: data, URL-er og sikkerhetskopier
En praktisk veiledning for selvhosting av Baserow med Docker, porter, persistent data, TLS, sikkerhet, sikkerhetskopier og feilene som hindrer produksjonsbruk. Steg for steg.
En Baserow-container kan være grønn selv om det brukerne faktisk trenger, er ødelagt. For Baserow er den skjulte feilen vanligvis at den offentlige URL-en endres etter at brukerne har generert delings- og callback-lenker. Denne veiledningen bruker «opprett en database og en visning, importer en CSV-fil, rediger rader fra to økter og last opp en fil før du starter all-in-one-stacken på nytt» som akseptansetest, og bygger utrullingen bakover fra dette resultatet.
Baserow har en bestemt rolle i stacken: Airtable-lignende databaser støttet av Postgres og Redis. Produksjonsspørsmålet er derfor ikke om port 80 svarer én gang, men om state, avhengigheter og den offentlige adressen fortsatt stemmer overens etter en omstart, oppdatering og gjenoppretting.
Hva Baserow er avhengig av
Prosesshelse og produkthelse er to forskjellige ting for Baserow. Port 80 kan svare selv om den brukerrettede transaksjonen fortsatt feiler. Det lokale runtime-kravet er tilstrekkelig minne for den inkluderte Postgres, Redis, backend-en og workerne. Hold livssyklusen eksplisitt, slik at flytting av Baserow mellom verter ikke endrer oppførselen i stillhet.
Bruk denne beredskapsøvelsen etter vesentlige konfigurasjonsendringer: opprett en database og en visning, importer en CSV-fil, rediger rader fra to økter og last opp en fil før du starter all-in-one-stacken på nytt. Hold kostbare eksterne kontroller utenfor liveness-prober, slik at et leverandørutfall ikke fører til en omstartsløkke. Kapasitetsarbeidet bør følge med på inkludert Postgres, Redis, Celery-workers, radantall, importstørrelse og antall samtidige redaktører. Dette ligger nærmere det reelle presset på Baserow enn sideforespørsler.
Et Docker-utgangspunkt for Baserow
Følgende kommando synliggjør containergrensen uten å late som om alle eksterne tjenester blir klargjort.
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 åpner for innkommende trafikk, bør du kontrollere det ferdig evaluerte miljøet, mountene og lytteren. Bekreft det lokale kravet før eksponering: tilstrekkelig minne for den inkluderte Postgres, Redis, backend-en og workerne. En vellykket oppstart er først fullført når du kan opprette en database og en visning, importere en CSV-fil, redigere rader fra to økter og laste opp en fil før du starter all-in-one-stacken på nytt – ikke når docker ps skriver ut Up.
Domener, proxy-headere og port 80
Eksponer ett HTTPS-vertsnavn for Baserow, og hold rå port 80 privat. Sett BASEROW_PUBLIC_URL til den nøyaktige eksterne origin-en. Da unngår du at nettlesere og API-klienter lærer to konkurrerende adresser.
Kjør den velprøvde transaksjonen fra en ren klient, og undersøk den første forespørselen som feiler. Bruk veiledningen for egendefinert domene når DNS eller TLS er feil. Behandle «den offentlige URL-en endres etter at brukerne har generert delings- og callback-lenker» som en separat applikasjonsdiagnose når rutingen er bekreftet.
Sikkerhetskopier state som Baserow ikke kan gjenskape
Definer recovery point og recovery time for Baserow med utgangspunkt i hele /baserow/data-treet og periodiske logiske databaseeksporter. Mount /baserow/data før bootstrap, skriv ufarlige eksempeldata og bytt ut containeren for å bevise at banen faktisk er persistent. Et navngitt volume løser persistence ved redeploy; det løser ikke kompromittering eller tap av serveren.
Bygg et rent gjenopprettingsmiljø, bruk den samme fastlåste applikasjonsversjonen og bevis at tabeller, visninger, brukere, automatiseringer og filer kommer tilbake fra den komplette /baserow/data-sikkerhetskopien. Dokumenter kommandoer, korrigeringer av eierskap og medgått tid. Veiledningen for sikkerhetskopier er en nyttig standard: En sikkerhetskopi er til å stole på etter gjenoppretting, ikke etter opplasting.
Ikke gi Baserow hele verten
Trusselmodeller handlingen Baserow utfører, ikke bare innloggingsskjemaet. Her er den største risikoen å bruke all-in-one-imaget uten en plan for sikkerhetskopiering av de inkluderte tjenestene. Implementer denne grensen: steng registrering når det er hensiktsmessig, bevar SECRET_KEY og begrens offentlige delte visninger til de tiltenkte dataene.
Generer SECRET_KEY én gang, hold den utenfor Git og bevar den sammen med recovery-manifestet, fordi en endring kan ugyldiggjøre kryptert eller signert applikasjons-state. Ikke løs et tillatelsesproblem ved å kjøre containeren som root eller ved å mounte verten bredt. Ressursgrenser hører også hjemme i sikkerhetsdesignet når inkludert Postgres, Redis, Celery-workers, radantall, importstørrelse og antall samtidige redaktører kan utløses av brukere.
Logger som besvarer det neste spørsmålet
En inaktiv helsesjekk sier lite om Baserow. Følg med på inkludert Postgres, Redis, Celery-workers, radantall, importstørrelse og antall samtidige redaktører, og varsle om symptomet brukerne opplever: at handlingen «opprett en database og en visning, importer en CSV-fil, rediger rader fra to økter og last opp en fil før du starter all-in-one-stacken på nytt» feiler. Hold liveness lokal og billig; la readiness rapportere migreringer eller initialisering uten å forårsake en omstartsflom.
Det risikable området ved oppgraderinger er at all-in-one-imaget flytter flere tjenester samtidig. Derfor må database- og applikasjonsmigreringer øves med utgangspunkt i snapshots. Les versjonsnotater, ta et snapshot av state, rull ut målversjonen mot en gjenopprettet kopi og gjenta akseptansesjekken. Hvis den offentlige URL-en endres etter at brukerne har generert delings- og callback-lenker, bør du korrelere klientforespørselen med den første relevante applikasjonsloggen i stedet for å slette state eller legge til redirects på måfå.
Fem kontroller som er sterkere enn containerhelse
Før de reelle brukerne kommer, bør du lage et release-ark for Baserow. Det må angi det fastlåste imaget, port 80, den kanoniske origin-en, persistente baner og hvem som har ansvaret for tilstrekkelig minne for den inkluderte Postgres, Redis, backend-en og workerne. Legg ved forventet resultat for denne transaksjonen: opprett en database og en visning, importer en CSV-fil, rediger rader fra to økter og last opp en fil før du starter all-in-one-stacken på nytt.
Bruk arket etter en normal utskifting og etter en ren gjenoppretting. Gjenoppretting godtas bare hvis tabeller, visninger, brukere, automatiseringer og filer kommer tilbake fra den komplette /baserow/data-sikkerhetskopien. Samle også inn en kort ressursmåling som dekker inkludert Postgres, Redis, Celery-workers, radantall, importstørrelse og antall samtidige redaktører. Oppbevar den sammen med releasen, slik at fremtidige kapasitetsendringer kan sammenlignes med den samme arbeidsbelastningen.
Inkluder én kontrollert feil: send inn ufarlige data nær ressurs- eller formatgrensen som er knyttet til denne grensen: den offentlige URL-en endres etter at brukerne har generert delings- og callback-lenker. Bekreft at Baserow rapporterer problemet ved riktig grense, gjenopprett den gyldige tilstanden og kjør transaksjonen på nytt. Dette kontrollerer feilsynlighet, ikke bare suksess, og hindrer et tilsynelatende friskt grensesnitt i å skjule en ødelagt worker, callback eller databaseforbindelse.
Knytt Baserow til Dockup-livssyklusen
Dockups utrulling av Baserow med ett klikk bør gjøre utskifting trygg: Ruten fortsetter å peke mot 80, hemmeligheter bygges ikke inn i imaget, og persistente baner kommer tilbake i den nye containeren. Den samme utrullingen kan kjøre på Dockup-compute eller en tilkoblet maskin.
Fullfør det appspesifikke arbeidet ved å bekrefte det lokale kravet – tilstrekkelig minne for den inkluderte Postgres, Redis, backend-en og workerne –, bruke den kanoniske offentlige adressen og kjøre denne akseptansesjekken: opprett en database og en visning, importer en CSV-fil, rediger rader fra to økter og last opp en fil før du starter all-in-one-stacken på nytt. Legg resultatet av gjenopprettingen inn i runbooken før de reelle brukerne kommer.
Vanlige spørsmål
Hva trenger Baserow for en produksjonsutrulling?
Rout Baserow-containeren på port 80 gjennom én HTTPS-origin. Det lokale runtime-kravet er tilstrekkelig minne for den inkluderte Postgres, Redis, backend-en og workerne. Ikke erklær Baserow klar før du kan opprette en database og en visning, importere en CSV-fil, redigere rader fra to økter og laste opp en fil før du starter all-in-one-stacken på nytt.
Hvilke Baserow-data bør inngå i en sikkerhetskopi?
Gjør /baserow/data persistent, og inkluder hele /baserow/data-treet samt periodiske logiske databaseeksporter i det samme recovery-manifestet. En ren Baserow-gjenoppretting er først godkjent når tabeller, visninger, brukere, automatiseringer og filer kommer tilbake fra den komplette /baserow/data-sikkerhetskopien.
Krever Baserow HTTPS bak en reverse proxy?
Bruk HTTPS for den offentlige Baserow-origin-en, og hold port 80 på den interne ruten. Bruk Baserow-innstillingen riktig: sett BASEROW_PUBLIC_URL til den nøyaktige eksterne origin-en. For Baserow beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for konsistent klientoppførsel som er avhengig av origin.
Hvordan bør en Baserow-oppgradering testes?
Gjenopprett gjeldende Baserow-state til en isolert utrulling, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at all-in-one-imaget flytter flere tjenester samtidig. Derfor må database- og applikasjonsmigreringer øves med utgangspunkt i snapshots. Behold det forrige Baserow-imaget til grensen for datamigrering og rollback er forstått.