Slik selvhoster du NocoDB i 2026: databasetilkoblinger, autentisering og persistent lagring

Det finnes to versjoner av «å kjøre NocoDB»: enten finnes det en container, eller så fullfører tjenesten den faktiske oppgaven sin. Det er bare den siste som teller. Her er beviset å koble til en midlertidig kildedatabase, opprette et grid og en filtrert visning, redigere en rad, legge til et vedlegg og kalle REST API-et.

NocoDB har dette som formål: et regnearkgrensesnitt over en ekte database. Distribusjonen må bevare komponentene bak denne funksjonaliteten; en port, et volum og et sertifikat er forutsetninger, ikke resultatet.

Tegn runtime-grensen for NocoDB

Prosesshelse og produkthelse er to separate ting i NocoDB. Port 8080 kan svare selv om den brukerrettede transaksjonen fortsatt feiler. Nettverkskontrakten for NocoDB er Postgres eller MySQL for produksjonsmetadata, i stedet for en midlertidig lokal fil. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi NocoDB en avgrenset servicekonto.

Bruk denne readiness-øvelsen etter viktige konfigurasjonsendringer: koble til en midlertidig kildedatabase, opprett et grid og en filtrert visning, rediger en rad, legg til et vedlegg og kall REST API-et. Hold kostbare eksterne kontroller unna liveness-prober, slik at et leverandøravbrudd ikke fører til en restart-loop. Kapasitetsarbeidet bør følge med på antall rader, vedleggstrafikk, metadata-databasens forsinkelse og antallet samtidige grid-brukere. Dette ligger nærmere det reelle presset på NocoDB enn sideforespørsler.

Start NocoDB med observerbare standardinnstillinger

Start NocoDB på en måte som holder ruten privat til bootstrap er fullført.

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

Hvis prosessen går i loop, sammenligner du brukeridentiteten imaget forventer, med eieren av hver monterte sti. Hvis den fortsetter å kjøre, tester du port 8080 lokalt og går deretter direkte til arbeidsflyten: koble til en midlertidig kildedatabase, opprett et grid og en filtrert visning, rediger en rad, legg til et vedlegg og kall REST API-et. Lås imaget til en bestemt versjon først etter at denne ende-til-ende-kontrollen er bestått, og dokumenter den nøyaktige konfigurasjonen sammen med tjenesten.

Domener, proxy-headere og port 8080

Velg det endelige NocoDB-vertsnavnet før brukerne lagrer callbacks eller klientinnstillinger, og angi deretter NC_PUBLIC_URL til den kanoniske HTTPS-adressen. Plattformruten bør terminere TLS én gang og målrette den private porten 8080.

Kjør akseptansetransaksjonen eksternt. Hvis klienten aldri når NocoDB, bruker du sjekklisten for SSL-validering for DNS- og sertifikatkontroller. Hvis forespørselen når NocoDB, men metadata-databasen ikke er tilgjengelig eller offentlige URL-er peker på en intern vert, må du slutte å endre proxy-redirects og i stedet undersøke den applikasjonsspesifikke grensen.

Utform gjenoppretting av NocoDB før lansering

Definer recovery point og recovery time for NocoDB med utgangspunkt i metadata-databasen, vedleggene og eventuelle eksterne kildedatabaser. Monter /usr/app/data før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at denne stien faktisk er persistent. Et navngitt volum løser persistence ved redeploy; det løser ikke kompromittering eller tap av serveren.

Bygg et rent restore-miljø, bruk den samme låste applikasjonsversjonen og bevis at baser, visninger, roller, vedlegg og kildetilkoblinger kommer tilbake uten å endre rader i den tilkoblede databasen. Dokumenter kommandoer, eierendringer og tidsbruk. Sikkerhetskopieringsveiledningen er en nyttig standard: En sikkerhetskopi er først til å stole på etter gjenoppretting, ikke etter opplasting.

Sikkerhetsvalg som gjelder spesifikt for NocoDB

Lukk bootstrap-vinduet så snart den første betrodde administratoren finnes. NocoDBs konkrete fallgruve er å gjenbruke en svak JWT-secret eller eksponere databaselegitimasjon for alle redaktører. Den sikrere grensen er å bruke en stabil JWT-secret, begrense hvem som kan opprette eksterne datakildetilkoblinger og gjennomgå eksponeringen av delte visninger.

Generer NC_AUTH_JWT_SECRET som en lang, tilfeldig verdi. Rotering av den ugyldiggjør normalt sesjoner eller tokens, så planlegg brukeropplevelsen i stedet for å kalle det en krypteringsmigrering. Privat nettverk bør transportere avhengighetslegitimasjon, og roller i NocoDB bør gi den minste nyttige tilgangen. Hold sensitive request bodies og svar fra leverandører borte fra vanlige logger.

Kapasitet og oppgraderingskontroller

En grønn container er nødvendig, men ikke tilstrekkelig. Tjenestens indikator er at «koble til en midlertidig kildedatabase, opprett et grid og en filtrert visning, rediger en rad, legg til et vedlegg og kall REST API-et» fullføres, mens de sannsynlige belastningssignalene er antall rader, vedleggstrafikk, metadata-databasens forsinkelse og antallet samtidige grid-brukere.

Endringskontroll er viktig fordi metadata-migreringer kan påvirke visninger og automatiseringer selv når den underliggende kildedatabasen forblir urørt. Ta vare på det gamle imaget, test migreringer på en kopi av tilstanden og dokumenter om rollback støttes etter at schemaet er flyttet. Hvis metadata-databasen ikke er tilgjengelig eller offentlige URL-er peker på en intern vert, diagnostiserer du den første grensen som avviker fra det fungerende miljøet.

En produksjonsgodkjenningstest for NocoDB

Før de faktiske brukerne kommer, lager du et release-regneark for NocoDB. Det må angi det låste imaget, port 8080, kanonisk origin, persistente stier og eieren av Postgres eller MySQL for produksjonsmetadata, i stedet for en midlertidig lokal fil. Legg ved det forventede resultatet av denne transaksjonen: koble til en midlertidig kildedatabase, opprett et grid og en filtrert visning, rediger en rad, legg til et vedlegg og kall REST API-et.

Bruk regnearket etter en vanlig utskifting og etter en ren restore. Gjenoppretting godtas bare hvis baser, visninger, roller, vedlegg og kildetilkoblinger kommer tilbake uten å endre rader i den tilkoblede databasen. Samle også inn en kort ressursmåling som dekker antall rader, vedleggstrafikk, metadata-databasens forsinkelse og antallet samtidige grid-brukere. Oppbevar den sammen med releasen, slik at fremtidige kapasitetsendringer sammenlignes med den samme arbeidsbelastningen.

Inkluder én kontrollert feil: nekt testidentiteten tilgang til Postgres eller MySQL for produksjonsmetadata, i stedet for en midlertidig lokal fil. Bekreft at NocoDB rapporterer problemet ved riktig grense, gjenopprett den gyldige tilstanden og kjør transaksjonen på nytt. Dette kontrollerer feilsynlighet, ikke bare suksess, og hindrer at et tilsynelatende friskt grensesnitt skjuler en ødelagt worker, callback eller databasetilkobling.

Hvor Dockup gjør NocoDB enklere

For NocoDB er Dockup mest nyttig i grensen mellom et image og en persistent tjeneste. Det holder ruten til 8080, TLS, secret-verdier og lagring tilknyttet på tvers av containerutskiftinger, uavhengig av om compute tilhører Dockup eller den tilkoblede serveren din.

Avslutt med applikasjonskunnskap: angi NC_PUBLIC_URL til den kanoniske HTTPS-adressen, koble til og test Postgres eller MySQL for produksjonsmetadata, i stedet for en midlertidig lokal fil, og kjør denne verifiseringen: koble til en midlertidig kildedatabase, opprett et grid og en filtrert visning, rediger en rad, legg til et vedlegg og kall REST API-et. Ta vare på resultatet som en deployment-kontroll, slik at neste image-oppdatering vurderes etter oppførsel og ikke containerstatus.

Vanlige spørsmål

Hva trenger NocoDB for en produksjonsdistribusjon?

Rout NocoDB-containeren på port 8080 gjennom én HTTPS-origin. Det støttende nettverkskravet er Postgres eller MySQL for produksjonsmetadata, i stedet for en midlertidig lokal fil. Ikke kall NocoDB klar før du kan koble til en midlertidig kildedatabase, opprette et grid og en filtrert visning, redigere en rad, legge til et vedlegg og kalle REST API-et.

Hvilke NocoDB-data hører hjemme i en sikkerhetskopi?

Gjør /usr/app/data persistent, og inkluder metadata-databasen, vedleggene og eventuelle eksterne kildedatabaser i det samme recovery-manifestet. En ren NocoDB-restore er bare godkjent når baser, visninger, roller, vedlegg og kildetilkoblinger kommer tilbake uten å endre rader i den tilkoblede databasen.

Krever NocoDB HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige NocoDB-origin-en, og hold port 8080 på den interne ruten. Bruk NocoDB-innstillingen riktig: angi NC_PUBLIC_URL til den kanoniske HTTPS-adressen. For NocoDB beskytter HTTPS legitimasjon eller brukerinnhold under transport og sørger for konsistent klientoppførsel som er avhengig av origin.

Hvordan bør en NocoDB-oppgradering testes?

Gjenopprett den aktuelle NocoDB-tilstanden i en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom fordi metadata-migreringer kan påvirke visninger og automatiseringer selv når den underliggende kildedatabasen forblir urørt. Behold det forrige NocoDB-imaget til grensen for datamigrering og rollback er forstått.