Så självhostar du Baserow 2026: data, URL:er och säkerhetskopior i en komplett lösning

En Baserow-container kan vara grön samtidigt som det användarna faktiskt behöver inte fungerar. För Baserow är det dolda felet oftast att den publika URL:en ändras efter att användarna har skapat delnings- och callback-länkar. Den här guiden använder följande som acceptanstest: ”skapa en databas och vy, importera en CSV-fil, redigera rader från två sessioner och ladda upp en fil innan hela stacken med allt-i-ett-lösningen startas om”. Distributionen byggs bakifrån utifrån det resultatet.

Baserow har en specifik roll i stacken: Airtable-liknande databaser med stöd av Postgres och Redis. Produktionsfrågan är därför inte om port 80 svarar en gång, utan om tillstånd, beroenden och den publika adressen fortsätter att stämma överens efter en omstart, uppdatering och återställning.

Vad Baserow är beroende av

Processens hälsa och produktens hälsa är två separata saker i Baserow. Port 80 kan svara samtidigt som den användarvända transaktionen fortfarande misslyckas. Det lokala körningskravet är tillräckligt med minne för den medföljande instansen av Postgres, Redis, backend och workers. Håll livscykeln tydlig så att en flytt av Baserow mellan värdar inte i tysthet ändrar beteendet.

Använd följande beredskapsövning efter betydande konfigurationsändringar: skapa en databas och vy, importera en CSV-fil, redigera rader från två sessioner och ladda upp en fil innan hela stacken med allt-i-ett-lösningen startas om. Håll kostsamma externa kontroller utanför liveness-prober så att ett avbrott hos en leverantör inte orsakar en omstartsloop. Kapacitetsarbetet bör följa den medföljande instansen av Postgres, Redis, Celery-workers, antal rader, importstorlek och antal samtidiga redigerare. Det ligger närmare Baserows faktiska belastning än sidförfrågningar.

En Docker-bas för Baserow

Följande kommando synliggör containergränsen utan att låtsas provisionera alla externa tjänster.

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

Innan du öppnar inkommande trafik ska du inspektera den slutliga miljön, monteringar och lyssnare. Bekräfta det lokala kravet innan exponering: tillräckligt med minne för den medföljande instansen av Postgres, Redis, backend och workers. En lyckad start är klar först när du kan skapa en databas och vy, importera en CSV-fil, redigera rader från två sessioner och ladda upp en fil innan hela stacken med allt-i-ett-lösningen startas om – inte när docker ps skriver ut Up.

Domäner, proxyheaders och port 80

Exponera ett HTTPS-värdnamn för Baserow och håll den råa port 80 privat. Ange BASEROW_PUBLIC_URL till exakt den externa origin-adressen. Då hindrar du webbläsare och API-klienter från att lära sig två konkurrerande adresser.

Kör den kända fungerande transaktionen från en ren klient och inspektera den första begäran som misslyckas. Använd guiden för anpassade domäner när DNS eller TLS är felkonfigurerat. Behandla ”den publika URL:en ändras efter att användarna har skapat delnings- och callback-länkar” som en separat applikationsdiagnos när routningen väl är bekräftad.

Säkerhetskopiera det som Baserow inte kan återskapa

Definiera återställningspunkt och återställningstid för Baserow utifrån hela trädet /baserow/data samt återkommande logiska databasexporter. Montera /baserow/data före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. En namngiven volym löser beständighet vid ny distribution, men inte ett intrång eller en förlust av servern.

Bygg en ren återställningsmiljö, använd samma låsta applikationsversion och bevisa att tabeller, vyer, användare, automatiseringar och filer återkommer från den fullständiga säkerhetskopian av /baserow/data. Dokumentera kommandon, korrigeringar av ägarskap och förfluten tid. Guiden om säkerhetskopior är en användbar standard: en säkerhetskopia är tillförlitlig efter återställning, inte efter uppladdning.

Ge inte Baserow hela värden

Gör en hotmodellering av de åtgärder Baserow utför, inte bara av inloggningsformuläret. Det högriskfyllda misstaget här är att använda allt-i-ett-avbildningen utan en plan för säkerhetskopiering av de medföljande tjänsterna. Implementera följande gräns: stäng av registrering när det är lämpligt, bevara SECRET_KEY och begränsa publika delade vyer till avsedda data.

Skapa SECRET_KEY en gång, håll den utanför Git och bevara den tillsammans med återställningsmanifestet, eftersom ett byte kan ogiltigförklara krypterat eller signerat applikationstillstånd. Lös inte ett behörighetsfel genom att köra containern som root eller montera värden brett. Resursbegränsningar hör också till säkerhetsdesignen när den medföljande instansen av Postgres, Redis, Celery-workers, antal rader, importstorlek och antal samtidiga redigerare kan utlösas av användare.

Loggar som besvarar nästa fråga

En inaktiv health check säger inte mycket om Baserow. Övervaka den medföljande instansen av Postgres, Redis, Celery-workers, antal rader, importstorlek och antal samtidiga redigerare och larma på det symptom användarna upplever: att åtgärden ”skapa en databas och vy, importera en CSV-fil, redigera rader från två sessioner och ladda upp en fil innan hela stacken med allt-i-ett-lösningen startas om” misslyckas. Håll liveness lokal och billig; låt readiness rapportera migreringar eller initiering utan att orsaka en omstartsstorm.

Det riskfyllda uppgraderingsområdet är att allt-i-ett-avbildningen flyttar flera tjänster tillsammans. Därför behöver databas- och applikationsmigreringar övas med snapshot-baserade tester. Läs versionsanteckningarna, skapa en snapshot av tillståndet, distribuera målversionen mot en återställd kopia och upprepa acceptansåtgärden. Om den publika URL:en ändras efter att användarna har skapat delnings- och callback-länkar ska du korrelera klientbegäran med den första relevanta applikationsloggen i stället för att radera tillstånd eller lägga till omdirigeringar på måfå.

Fem kontroller som är starkare än containerhälsa

Innan riktiga användare anländer ska du skapa ett releasearbetsblad för Baserow. Det måste ange den låsta avbildningen, port 80, den kanoniska origin-adressen, beständiga sökvägar och ägaren till tillräckligt med minne för den medföljande instansen av Postgres, Redis, backend och workers. Bifoga det förväntade resultatet av denna transaktion: skapa en databas och vy, importera en CSV-fil, redigera rader från två sessioner och ladda upp en fil innan hela stacken med allt-i-ett-lösningen startas om.

Använd arbetsbladet efter ett normalt byte och efter en ren återställning. Återställningen är godkänd först när tabeller, vyer, användare, automatiseringar och filer återkommer från den fullständiga säkerhetskopian av /baserow/data. Samla också in en kort resursprofil som täcker den medföljande instansen av Postgres, Redis, Celery-workers, antal rader, importstorlek och antal samtidiga redigerare. Förvara den tillsammans med releasen så att framtida kapacitetsändringar kan jämföras med samma arbetsbelastning.

Inkludera ett kontrollerat fel: skicka ofarlig indata nära den resurs- eller formatgräns som hör ihop med denna gräns: den publika URL:en ändras efter att användarna har skapat delnings- och callback-länkar. Bekräfta att Baserow rapporterar problemet vid rätt gräns, återställ det giltiga tillståndet och kör transaktionen igen. Detta kontrollerar felens synlighet, inte bara framgång, och hindrar ett gränssnitt som ser friskt ut från att dölja en trasig worker, callback eller databasanslutning.

Koppla Baserow till Dockups livscykel

Dockups distribution av Baserow med ett klick bör göra byten säkra: routningen fortsätter att rikta sig mot 80, hemligheter byggs inte in i avbildningen och beständiga sökvägar återkommer i den nya containern. Samma distribution kan köras på Dockup-beräkning eller på en ansluten maskin.

Slutför det appspecifika arbetet genom att bekräfta det lokala kravet – tillräckligt med minne för den medföljande instansen av Postgres, Redis, backend och workers –, tillämpa den kanoniska publika adressen och köra detta acceptanstest: skapa en databas och vy, importera en CSV-fil, redigera rader från två sessioner och ladda upp en fil innan hela stacken med allt-i-ett-lösningen startas om. Lägg till återställningsresultatet i körboken innan riktiga användare anländer.

Vanliga frågor

Vad behöver Baserow för en produktionsdistribution?

Routa Baserow-containern på port 80 via en enda HTTPS-origin. Det lokala körningskravet är tillräckligt med minne för den medföljande instansen av Postgres, Redis, backend och workers. Kalla inte Baserow redo förrän du kan skapa en databas och vy, importera en CSV-fil, redigera rader från två sessioner och ladda upp en fil innan hela stacken med allt-i-ett-lösningen startas om.

Vilka Baserow-data ska ingå i en säkerhetskopia?

Gör /baserow/data beständig och inkludera hela trädet /baserow/data samt återkommande logiska databasexporter i samma återställningsmanifest. En ren Baserow-återställning är godkänd först när tabeller, vyer, användare, automatiseringar och filer återkommer från den fullständiga säkerhetskopian av /baserow/data.

Kräver Baserow HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Baserow-origin-adressen och behåll port 80 på den interna routen. Tillämpa Baserow-inställningen korrekt: ange BASEROW_PUBLIC_URL till exakt den externa origin-adressen. För Baserow skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.

Hur bör en Baserow-uppgradering testas?

Återställ det aktuella Baserow-tillståndet till en isolerad distribution, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom allt-i-ett-avbildningen flyttar flera tjänster tillsammans. Därför behöver databas- och applikationsmigreringar övas med snapshot-baserade tester. Behåll den tidigare Baserow-avbildningen tills gränserna för datamigrering och rollback är förstådda.