NocoDB zelf hosten in 2026: databasekoppelingen, authenticatie en persistentie

Er zijn twee versies van “NocoDB draaien”: er bestaat een container, of de service voert zijn echte taak uit. Alleen het tweede is relevant. In dit geval bestaat het bewijs uit het koppelen van een tijdelijke source database, het maken van een grid en gefilterde view, het bewerken van een rij, het toevoegen van een attachment en het aanroepen van de REST API.

NocoDB dient hiervoor als spreadsheetinterface boven op een echte database. De deployment moet de onderdelen achter dit gedrag behouden; een poort, volume en certificaat zijn inputs, niet het resultaat.

De runtimegrens van NocoDB in kaart brengen

Processtatus en productstatus staan bij NocoDB los van elkaar. Poort 8080 kan antwoorden terwijl de transactie richting de gebruiker nog steeds mislukt. Het netwerkcontract voor NocoDB bestaat in productie uit PostgreSQL of MySQL voor metadata, in plaats van een tijdelijk lokaal bestand. Houd private endpoints op interne DNS, sta alleen vereiste uitgaande verbindingen toe en geef NocoDB een servicecredential met beperkte rechten.

Gebruik deze readiness-oefening na belangrijke configuratiewijzigingen: koppel een tijdelijke source database, maak een grid en gefilterde view, bewerk een rij, voeg een attachment toe en roep de REST API aan. Houd dure externe controles buiten liveness probes, zodat een storing bij een provider geen restart-loop veroorzaakt. Houd bij capaciteitswerk rekening met het aantal rijen, attachment-verkeer, latency van de metadata-database en het aantal gelijktijdige gridgebruikers. Dat komt dichter in de buurt van de werkelijke belasting van NocoDB dan paginaverzoeken.

NocoDB starten met goed observeerbare defaults

Start NocoDB zo dat de route private blijft totdat de bootstrap is voltooid.

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

Als het proces blijft herstarten, vergelijk je de verwachte user van de image met de owner van elk gemount pad. Als het proces actief blijft, test je poort 8080 lokaal en ga je vervolgens direct naar de workflow: koppel een tijdelijke source database, maak een grid en gefilterde view, bewerk een rij, voeg een attachment toe en roep de REST API aan. Pin de imageversie pas nadat deze end-to-endcontrole slaagt en leg de exacte configuratie naast de service vast.

Domeinen, proxyheaders en poort 8080

Kies de definitieve NocoDB-hostnaam voordat gebruikers callbacks of clientinstellingen opslaan en stel NC_PUBLIC_URL in op het canonieke HTTPS-adres. De platformroute moet TLS één keer termineren en doorsturen naar private poort 8080.

Voer de acceptatietransactie extern uit. Als de client NocoDB nooit bereikt, gebruik dan de checklist voor SSL-validatie voor DNS- en certificaatcontroles. Als het verzoek NocoDB wel bereikt, maar de metadata-database niet bereikbaar is of publieke URL's naar een interne host verwijzen, stop dan met het aanpassen van proxyredirects en inspecteer de applicatiespecifieke grens.

Het herstel van NocoDB ontwerpen vóór de start

Definieer het recovery point en recovery time voor NocoDB aan de hand van de metadata-database, attachments en eventuele externe source databases. Mount /usr/app/data vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Een named volume lost persistentie bij redeployment op; het beschermt je niet tegen een compromise of verlies van de server.

Bouw een schone restoreomgeving, gebruik dezelfde gepinde applicatieversie en bewijs dat bases, views, rollen, attachments en source mappings terugkomen zonder rijen in de verbonden database te wijzigen. Leg commando's, fixes voor ownership en de verstreken tijd vast. De backuphandleiding biedt een bruikbare standaard: een backup is pas betrouwbaar na een restore, niet na een upload.

Beveiligingskeuzes die specifiek zijn voor NocoDB

Sluit het bootstrapvenster zodra de eerste vertrouwde administrator bestaat. De concrete valkuil bij NocoDB is het hergebruiken van een zwak JWT-secret of het blootstellen van base-credentials aan elke editor; de veiligere grens bestaat uit een stabiel JWT-secret, beperken wie externe data-sourceconnecties kan maken en controleren hoe gedeelde views worden blootgesteld.

Genereer NC_AUTH_JWT_SECRET als een lange, willekeurige waarde; door deze normaal gesproken te roteren worden sessies of tokens ongeldig, dus plan de impact voor gebruikers in plaats van dit een encryptiemigratie te noemen. Private networking moet dependency-credentials transporteren en rollen binnen NocoDB moeten de kleinst bruikbare actie toestaan. Houd gevoelige request bodies en responses van providers buiten routinematige logs.

Capaciteits- en upgradecontroles

Een groene container is noodzakelijk, maar niet voldoende. De service-level indicator is het succesvol voltooien van “een tijdelijke source database koppelen, een grid en gefilterde view maken, een rij bewerken, een attachment toevoegen en de REST API aanroepen”. De meest waarschijnlijke signalen van druk zijn het aantal rijen, attachment-verkeer, latency van de metadata-database en het aantal gelijktijdige gridgebruikers.

Change control is belangrijk omdat metadata-migraties invloed kunnen hebben op views en automations, zelfs wanneer de onderliggende source database niet wordt gewijzigd. Bewaar de oude image, test migraties op een kopie van de state en documenteer of rollback na de schemamutatie wordt ondersteund. Als de metadata-database niet bereikbaar is of publieke URL's naar een interne host verwijzen, diagnosticeer je de eerste grens die afwijkt van de werkende omgeving.

Een productieacceptatietest voor NocoDB

Maak vóór de komst van echte gebruikers een releasewerkblad voor NocoDB. Daarin moeten de gepinde image, poort 8080, canonieke origin, persistente paden en de owner van PostgreSQL of MySQL voor productiemetadata in plaats van een tijdelijk lokaal bestand worden vermeld. Voeg het verwachte resultaat van deze transactie toe: een tijdelijke source database koppelen, een grid en gefilterde view maken, een rij bewerken, een attachment toevoegen en de REST API aanroepen.

Gebruik het werkblad na een normale vervanging en na een schone restore. Recovery wordt alleen geaccepteerd als bases, views, rollen, attachments en source mappings terugkomen zonder rijen in de verbonden database te wijzigen. Verzamel ook een korte resourcetrace met het aantal rijen, attachment-verkeer, latency van de metadata-database en het aantal gelijktijdige gridgebruikers; bewaar deze naast de release, zodat toekomstige capaciteitswijzigingen met dezelfde workload worden vergeleken.

Neem één gecontroleerde fout op: ontzeg de testidentiteit tijdelijk de toegang tot PostgreSQL of MySQL voor productiemetadata in plaats van een tijdelijk lokaal bestand. Controleer of NocoDB het probleem op de juiste grens meldt, herstel de geldige toestand en voer de transactie opnieuw uit. Hiermee test je de zichtbaarheid van fouten, niet alleen succes, en voorkom je dat een gezond uitziende interface een defecte worker, callback of databaseverbinding verbergt.

Waar Dockup werk uit handen neemt voor NocoDB

Voor NocoDB is Dockup vooral nuttig op de grens tussen een image en een duurzame service. Het houdt de route naar 8080, TLS, secretwaarden en opslag gekoppeld tijdens het vervangen van containers, ongeacht of de compute bij Dockup of op je aangesloten server staat.

Rond af met applicatiekennis: stel NC_PUBLIC_URL in op het canonieke HTTPS-adres; maak verbinding met PostgreSQL of MySQL voor productiemetadata in plaats van een tijdelijk lokaal bestand en voer deze verificatie uit: koppel een tijdelijke source database, maak een grid en gefilterde view, bewerk een rij, voeg een attachment toe en roep de REST API aan. Bewaar het resultaat als deploymentcheck, zodat de volgende image-update wordt beoordeeld op gedrag in plaats van containerstatus.

Veelgestelde vragen

Wat heeft NocoDB nodig voor een productie-deployment?

Routeer de NocoDB-container via poort 8080 door één HTTPS-origin. De ondersteunende netwerkvereiste is PostgreSQL of MySQL voor productiemetadata in plaats van een tijdelijk lokaal bestand. Beschouw NocoDB pas als klaar wanneer je een tijdelijke source database kunt koppelen, een grid en gefilterde view kunt maken, een rij kunt bewerken, een attachment kunt toevoegen en de REST API kunt aanroepen.

Welke NocoDB-data hoort in een backup?

Maak /usr/app/data persistent en neem de metadata-database, attachments en eventuele externe source databases op in hetzelfde recoverymanifest. Een schone NocoDB-restore is alleen geslaagd wanneer bases, views, rollen, attachments en source mappings terugkomen zonder rijen in de verbonden database te wijzigen.

Heeft NocoDB HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke NocoDB-origin en houd poort 8080 op de interne route. Pas de NocoDB-instelling correct toe: stel NC_PUBLIC_URL in op het canonieke HTTPS-adres. Voor NocoDB beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het voor consistent gedrag van clients die gevoelig zijn voor de origin.

Hoe test je een NocoDB-upgrade?

Restore de huidige NocoDB-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat metadata-migraties invloed kunnen hebben op views en automations, zelfs wanneer de onderliggende source database niet wordt gewijzigd. Bewaar de vorige NocoDB-image totdat de grens voor datamigratie en rollback duidelijk is.