Så självhostar du NocoDB 2026: databaslänkar, autentisering och persistens

Det finns två versioner av att ”köra NocoDB”: antingen finns en container, eller så utför tjänsten sitt faktiska arbete. Det är bara det senare som räknas. Här är beviset att ansluta en tillfällig källdatabas, skapa ett grid och en filtrerad vy, redigera en rad, lägga till en bilaga och anropa REST API:t.

NocoDB fyller den här funktionen: ett spreadsheet-gränssnitt ovanpå en riktig databas. Deploymenten måste bevara delarna bakom detta beteende; en port, en volym och ett certifikat är förutsättningar, inte resultatet.

Rita upp NocoDB:s runtime-gräns

Processhälsa och produkthälsa är separata för NocoDB. Port 8080 kan svara samtidigt som den användarvända transaktionen fortfarande misslyckas. Nätverkskontraktet för NocoDB är Postgres eller MySQL som produktionsmetadata i stället för en tillfällig lokal fil. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge NocoDB en avgränsad service credential.

Använd detta readiness-test efter meningsfulla konfigurationsändringar: anslut en tillfällig källdatabas, skapa ett grid och en filtrerad vy, redigera en rad, lägg till en bilaga och anropa REST API:t. Håll kostsamma externa kontroller borta från liveness probes så att ett avbrott hos en leverantör inte orsakar en restart loop. Kapacitetsarbetet bör följa antal rader, trafik för bilagor, metadatabasens svarstid och antalet samtidiga grid-användare, vilket bättre speglar NocoDB:s verkliga belastning än sidförfrågningar.

Starta NocoDB med observerbara standardvärden

Starta NocoDB på ett sätt som håller routen privat tills bootstrap är slutförd.

docker run -d \
  --name nocodb \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v nocodb-data:/usr/app/data \
  -e NC_AUTH_JWT_SECRET=replace-with-a-long-random-value \
  nocodb/nocodb:latest

Om processen startar om i en loop ska du jämföra den användare som image:n förväntar sig med ägaren till varje mountad sökväg. Om den fortsätter vara igång testar du port 8080 lokalt och går sedan direkt vidare till arbetsflödet: anslut en tillfällig källdatabas, skapa ett grid och en filtrerad vy, redigera en rad, lägg till en bilaga och anropa REST API:t. Versionslås image:n först när den här end-to-end-kontrollen har gått igenom, och dokumentera den exakta konfigurationen bredvid tjänsten.

Domäner, proxyheaders och port 8080

Välj det slutgiltiga NocoDB-hostnamnet innan användare sparar callbacks eller klientinställningar, och ange sedan NC_PUBLIC_URL som den kanoniska HTTPS-adressen. Plattformens route bör terminera TLS en gång och rikta trafiken mot den privata porten 8080.

Kör acceptanstransaktionen externt. Om klienten aldrig når NocoDB använder du checklistan för SSL-validering för DNS- och certifikatkontroller. Om anropet når NocoDB men metadatabasen inte går att nå, eller om publika URL:er pekar på en intern host, ska du sluta ändra proxyredirects och i stället undersöka den applikationsspecifika gränsen.

Utforma NocoDB:s återställning före lansering

Definiera recovery point och recovery time för NocoDB utifrån metadatabasen, bilagorna och eventuella externa källdatabaser. Montera /usr/app/data före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är persistent. En namngiven volym löser persistens vid redeploy; den löser inte intrång eller förlust av servern.

Bygg en ren restore-miljö, använd samma versionslåsta applikationsversion och bevisa att bases, vyer, roller, bilagor och källmappningar återkommer utan att rader i den anslutna databasen ändras. Dokumentera kommandon, ägarskapskorrigeringar och förfluten tid. Backupguiden är en användbar standard: en backup är betrodd efter återställning, inte efter uppladdning.

Säkerhetsbeslut som är specifika för NocoDB

Stäng bootstrap-fönstret så snart den första betrodda administratören finns. NocoDB:s konkreta fallgrop är att återanvända en svag JWT-secret eller exponera datakällans credentials för alla editors; den säkrare gränsen är att använda en stabil JWT-secret, begränsa vilka som får skapa externa datakällanslutningar och granska exponeringen av delade vyer.

Generera NC_AUTH_JWT_SECRET som ett långt slumpmässigt värde; en rotation ogiltigförklarar normalt sessioner eller tokens, så planera användarpåverkan i stället för att kalla det en krypteringsmigrering. Privat nätverk bör bära dependency-credentials, och roller inne i NocoDB bör ge minsta användbara behörighet. Håll känsliga request bodies och leverantörssvar borta från rutinloggar.

Kapacitet och uppgraderingskontroller

En grön container är nödvändig men inte tillräcklig. Service-level-indikatorn är att ”ansluta en tillfällig källdatabas, skapa ett grid och en filtrerad vy, redigera en rad, lägga till en bilaga och anropa REST API:t” slutförs framgångsrikt, medan de sannolika belastningssignalerna är antal rader, trafik för bilagor, metadatabasens svarstid och antalet samtidiga grid-användare.

Change control spelar roll eftersom metadatamigreringar kan påverka vyer och automations även när den underliggande källdatabasen förblir orörd. Bevara den gamla image:n, testa migreringar på kopierat state och dokumentera om rollback stöds efter att schemat har flyttats. Om metadatabasen inte går att nå eller publika URL:er pekar på en intern host ska du diagnostisera den första gräns som skiljer sig från den fungerande miljön.

En produktionsmässig acceptanskörning för NocoDB

Innan riktiga användare kommer in ska du skapa ett release-formulär för NocoDB. Det måste ange den versionslåsta image:n, port 8080, den kanoniska origin, persistenta sökvägar och ägaren till Postgres eller MySQL för produktionsmetadata i stället för en tillfällig lokal fil. Bifoga det förväntade resultatet av denna transaktion: anslut en tillfällig källdatabas, skapa ett grid och en filtrerad vy, redigera en rad, lägg till en bilaga och anropa REST API:t.

Använd formuläret efter ett normalt byte och efter en ren restore. Återställningen godkänns endast om bases, vyer, roller, bilagor och källmappningar återkommer utan att rader i den anslutna databasen ändras. Samla också in en kort resursmätning som omfattar antal rader, trafik för bilagor, metadatabasens svarstid och antalet samtidiga grid-användare; spara den bredvid releasen så att framtida kapacitetsändringar jämförs med samma arbetsbelastning.

Inkludera ett kontrollerat fel: neka tillfälligt testidentiteten åtkomst till Postgres eller MySQL för produktionsmetadata i stället för en tillfällig lokal fil. Bekräfta att NocoDB rapporterar problemet vid rätt gräns, återställ det giltiga tillståndet och kör transaktionen igen. Detta kontrollerar felsynlighet, inte bara framgång, och förhindrar att ett till synes friskt gränssnitt döljer en trasig worker, callback eller databasanslutning.

Var Dockup minskar arbetet för NocoDB

För NocoDB är Dockup mest användbart i gränsen mellan en image och en persistent tjänst. Det håller routen till 8080, TLS, secret-värden och lagring sammanlänkade vid containerbyten, oavsett om beräkningsresurserna tillhör Dockup eller din anslutna server.

Avsluta med applikationskunskap: ange NC_PUBLIC_URL som den kanoniska HTTPS-adressen; anslut och testa Postgres eller MySQL för produktionsmetadata i stället för en tillfällig lokal fil; och kör denna verifiering: anslut en tillfällig källdatabas, skapa ett grid och en filtrerad vy, redigera en rad, lägg till en bilaga och anropa REST API:t. Spara resultatet som en deploymentkontroll så att nästa image-uppdatering bedöms utifrån beteende i stället för containerstatus.

Vanliga frågor

Vad behöver NocoDB för en produktionsdeployment?

Routa NocoDB-containern på port 8080 via en enda HTTPS-origin. Det stödjande nätverkskravet är Postgres eller MySQL för produktionsmetadata i stället för en tillfällig lokal fil. Kalla inte NocoDB redo förrän du kan ansluta en tillfällig källdatabas, skapa ett grid och en filtrerad vy, redigera en rad, lägga till en bilaga och anropa REST API:t.

Vilka NocoDB-data ska ingå i en backup?

Gör /usr/app/data persistent och inkludera metadatabasen, bilagorna och eventuella externa källdatabaser i samma recovery-manifest. En ren NocoDB-restore är godkänd först när bases, vyer, roller, bilagor och källmappningar återkommer utan att rader i den anslutna databasen ändras.

Kräver NocoDB HTTPS bakom en reverse proxy?

Använd HTTPS för den publika NocoDB-origin och håll port 8080 på den interna routen. Tillämpa NocoDB-inställningen korrekt: ange NC_PUBLIC_URL som den kanoniska HTTPS-adressen. För NocoDB skyddar HTTPS credentials eller användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.

Hur bör en NocoDB-uppgradering testas?

Återställ det aktuella NocoDB-state:t till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom metadatamigreringar kan påverka vyer och automations även när den underliggande källdatabasen förblir orörd. Behåll den tidigare NocoDB-image:n tills dess datamigrerings- och rollback-gräns är förstådd.