Sådan selvhoster du NocoDB i 2026: Databaseforbindelser, godkendelse og persistens
Selvhost NocoDB med korrekte porte, persistent storage, HTTPS, secrets, backups og opgraderingskontroller. Lær, hvordan du løser problemet, når metadata-databasen ikke kan nås.
Der findes to versioner af at “køre NocoDB”: enten findes der en container, eller også udfører servicen faktisk sin opgave. Det er kun den sidste, der tæller. Her består beviset i at forbinde en midlertidig kildedatabase, oprette et grid og en filtreret visning, redigere en række, tilføje en attachment og kalde REST API'et.
NocoDB har dette formål: et regnearksinterface oven på en rigtig database. Deploymentet skal bevare de dele, der ligger bag denne funktionalitet; en port, en volume og et certifikat er input, ikke resultatet.
Afgræns NocoDB's runtime
Processtatus og produktstatus er to forskellige ting i NocoDB. Port 8080 kan svare, selvom den brugerrettede transaktion stadig fejler. NocoDB's netværkskontrakt er Postgres eller MySQL til produktionsmetadata i stedet for en midlertidig lokal fil. Hold private endpoints på intern DNS, tillad kun nødvendige udgående kald, og giv NocoDB en afgrænset service credential.
Brug denne readiness-test efter væsentlige konfigurationsændringer: Forbind en midlertidig kildedatabase, opret et grid og en filtreret visning, rediger en række, tilføj en attachment, og kald REST API'et. Hold dyre eksterne kontroller ude af liveness probes, så et driftsstop hos en provider ikke udløser en restart-loop. Kapacitetsarbejde bør følge antallet af rækker, attachment-trafik, latency for metadata-databasen og antallet af samtidige grid-brugere, da det ligger tættere på NocoDB's reelle belastning end sideforespørgsler.
Start NocoDB med observerbare standardindstillinger
Start NocoDB på en måde, der holder routen privat, indtil bootstrap er fuldfø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 processen går i loop, skal du sammenligne imagets forventede bruger med ejeren af hver mounted sti. Hvis den forbliver kørende, skal du teste port 8080 lokalt og derefter gå direkte videre til workflowet: forbind en midlertidig kildedatabase, opret et grid og en filtreret visning, rediger en række, tilføj en attachment, og kald REST API'et. Fastlås image-versionen, når denne end-to-end-kontrol er bestået, og registrer den præcise konfiguration sammen med servicen.
Domæner, proxy headers og port 8080
Vælg det endelige NocoDB-hostnavn, før brugerne gemmer callbacks eller klientindstillinger, og angiv derefter NC_PUBLIC_URL til den kanoniske HTTPS-adresse. Platform-routen skal terminere TLS én gang og pege på den private port 8080.
Kør acceptancetransaktionen eksternt. Hvis klienten aldrig når frem til NocoDB, kan du bruge tjeklisten til SSL-validering til kontrol af DNS og certifikat. Hvis requesten når frem til NocoDB, men metadata-databasen ikke kan nås, eller offentlige URL'er peger på en intern host, skal du stoppe med at ændre proxy-redirects og i stedet undersøge den applikationsspecifikke grænse.
Design NocoDB's restore før lancering
Definér recovery point og recovery time for NocoDB med udgangspunkt i metadata-databasen, attachments og eventuelle eksterne kildedatabaser. Mount /usr/app/data før bootstrap, skriv harmløse testdata, og udskift containeren for at bevise, at stien faktisk er persistent. En named volume løser persistens ved redeployment; den løser ikke kompromittering eller tab af serveren.
Opbyg et rent restore-miljø, brug den samme fastlåste applikationsversion, og bevis, at bases, visninger, roller, attachments og kildemappinger kommer tilbage uden at ændre rækker i den forbundne database. Registrer kommandoer, rettelser af ejerskab og den forløbne tid. Backup-guiden er en nyttig standard: En backup er først pålidelig efter restore, ikke efter upload.
Sikkerhedsbeslutninger, der er specifikke for NocoDB
Luk bootstrap-vinduet, så snart den første betroede administrator findes. NocoDB's konkrete faldgrube er at genbruge en svag JWT-secret eller eksponere databaseoplysninger for alle editors; den sikrere grænse er at bruge en stabil JWT-secret, begrænse hvem der kan oprette eksterne data source-forbindelser, og gennemgå eksponeringen af shared views.
Generér NC_AUTH_JWT_SECRET som en lang, tilfældig værdi; en rotation ugyldiggør normalt sessions eller tokens, så planlæg brugeroplevelsen i stedet for at kalde det en encryption-migration. Privat netværk bør transportere credentials til afhængigheder, og roller i NocoDB bør kun give den mindst mulige nyttige handling. Hold følsomme request bodies og svar fra providers ude af almindelige logs.
Kapacitet og opgraderingskontroller
En grøn container er nødvendig, men ikke tilstrækkelig. Serviceniveauindikatoren er en vellykket gennemførelse af “forbind en midlertidig kildedatabase, opret et grid og en filtreret visning, rediger en række, tilføj en attachment, og kald REST API'et”, mens de sandsynlige belastningssignaler er antallet af rækker, attachment-trafik, latency for metadata-databasen og antallet af samtidige grid-brugere.
Change control er vigtigt, fordi metadata-migrationer kan påvirke visninger og automations, selv når den underliggende kildedatabase ikke er berørt. Bevar det gamle image, test migrationer på en kopi af state, og dokumentér, om rollback understøttes, efter at schemaet er flyttet. Hvis metadata-databasen ikke kan nås, eller offentlige URL'er peger på en intern host, skal du diagnosticere den første grænse, der adskiller sig fra det fungerende miljø.
En production acceptance-test for NocoDB
Før de rigtige brugere kommer til, skal du udarbejde et release-regneark for NocoDB. Det skal angive det fastlåste image, port 8080, den kanoniske origin, persistente stier og ejeren af Postgres eller MySQL til produktionsmetadata i stedet for en midlertidig lokal fil. Vedhæft det forventede resultat af denne transaktion: Forbind en midlertidig kildedatabase, opret et grid og en filtreret visning, rediger en række, tilføj en attachment, og kald REST API'et.
Brug regnearket efter en normal udskiftning og efter et rent restore. Recovery accepteres kun, hvis bases, visninger, roller, attachments og kildemappinger kommer tilbage uden at ændre rækker i den forbundne database. Indsaml også et kort ressource-trace, der dækker antallet af rækker, attachment-trafik, latency for metadata-databasen og antallet af samtidige grid-brugere; opbevar det sammen med releasen, så fremtidige kapacitetsændringer sammenlignes med den samme workload.
Inkludér én kontrolleret fejl: Nægt midlertidigt testidentiteten adgang til Postgres eller MySQL til produktionsmetadata i stedet for en midlertidig lokal fil. Bekræft, at NocoDB rapporterer problemet ved den korrekte grænse, genskab den gyldige tilstand, og kør transaktionen igen. Det kontrollerer synligheden af fejl, ikke kun succes, og forhindrer, at et interface, der ser sundt ud, skjuler en defekt worker, callback eller databaseforbindelse.
Hvor Dockup fjerner arbejde for NocoDB
For NocoDB er Dockup mest nyttig ved grænsen mellem et image og en persistent service. Den holder routen til 8080, TLS, secret-værdier og storage tilknyttet på tværs af containerudskiftninger, uanset om computekapaciteten leveres af Dockup eller af din tilknyttede server.
Afslut med applikationsspecifik viden: Angiv NC_PUBLIC_URL til den kanoniske HTTPS-adresse; forbind til og test Postgres eller MySQL for produktionsmetadata i stedet for en midlertidig lokal fil; og kør denne verifikation: Forbind en midlertidig kildedatabase, opret et grid og en filtreret visning, rediger en række, tilføj en attachment, og kald REST API'et. Gem resultatet som en deployment-kontrol, så den næste image-opdatering vurderes ud fra adfærd i stedet for containerstatus.
Ofte stillede spørgsmål
Hvad skal NocoDB bruge til et produktionsdeployment?
Route NocoDB-containeren på port 8080 gennem én HTTPS-origin. Det understøttende netværkskrav er Postgres eller MySQL til produktionsmetadata i stedet for en midlertidig lokal fil. Kald ikke NocoDB klar, før du kan forbinde en midlertidig kildedatabase, oprette et grid og en filtreret visning, redigere en række, tilføje en attachment og kalde REST API'et.
Hvilke NocoDB-data skal med i en backup?
Gør /usr/app/data persistent, og inkludér metadata-databasen, attachments og eventuelle eksterne kildedatabaser i det samme recovery-manifest. Et rent NocoDB-restore er kun godkendt, når bases, visninger, roller, attachments og kildemappinger kommer tilbage uden at ændre rækker i den forbundne database.
Kræver NocoDB HTTPS bag en reverse proxy?
Brug HTTPS til den offentlige NocoDB-origin, og behold port 8080 på den interne route. Anvend NocoDB-indstillingen korrekt: Angiv NC_PUBLIC_URL til den kanoniske HTTPS-adresse. For NocoDB beskytter HTTPS credentials eller brugerindhold under transport og sikrer en ensartet klientadfærd, der afhænger af origin.
Hvordan bør en NocoDB-opgradering testes?
Restore den aktuelle NocoDB-state til et isoleret deployment, anvend kandidatversionen, og gentag dens acceptancetransaktion. Vær særligt opmærksom, fordi metadata-migrationer kan påvirke visninger og automations, selv når den underliggende kildedatabase ikke er berørt. Behold det tidligere NocoDB-image, indtil grænsen for datamigration og rollback er forstået.