Umgebungsvariablen

Wie richte ich Umgebungsvariablen ein?

Installation über Git-Quellcode oder create-nocobase-app

Legen Sie Umgebungsvariablen in der .env-Datei im Stammverzeichnis Ihres Projekts fest. Nachdem Sie die Umgebungsvariablen geändert haben, müssen Sie den Anwendungsprozess beenden und die Anwendung neu starten.

Installation über Docker

Bearbeiten Sie die docker-compose.yml-Konfiguration und legen Sie die Umgebungsvariablen im Parameter environment fest. Beispiel:

services:
  app:
    image: nocobase/nocobase:latest
    environment:
      - APP_ENV=production

Sie können auch env_file verwenden, um Umgebungsvariablen in einer .env-Datei zu definieren. Beispiel:

services:
  app:
    image: nocobase/nocobase:latest
    env_file: .env

Nachdem Sie die Umgebungsvariablen geändert haben, müssen Sie den App-Container neu erstellen:

docker compose up -d app

Globale Umgebungsvariablen

TZ

Dient zum Festlegen der Zeitzone der Anwendung. Standardmäßig wird die Zeitzone des Betriebssystems verwendet.

https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

Warning

Zeitbezogene Operationen werden gemäß dieser Zeitzone verarbeitet. Eine Änderung von TZ kann Datumswerte in der Datenbank beeinflussen. Weitere Details finden Sie unter „Datum & Uhrzeit Übersicht“.

APP_ENV

Die Anwendungsumgebung. Der Standardwert ist development. Verfügbare Optionen sind:

  • production Produktionsumgebung
  • development Entwicklungsumgebung
APP_ENV=production

APP_KEY

Der geheime Schlüssel der Anwendung, der unter anderem zur Generierung von Benutzer-Tokens verwendet wird. Ändern Sie ihn zu Ihrem eigenen Anwendungsschlüssel und stellen Sie sicher, dass er nicht nach außen gelangt.

Warning

Wenn der APP_KEY geändert wird, werden alte Tokens ungültig.

APP_KEY=app-key-test

APP_PORT

Der Port der Anwendung. Der Standardwert ist 13000.

APP_PORT=13000

API_BASE_PATH

Das Präfix der NocoBase API-Adresse. Der Standardwert ist /api/.

API_BASE_PATH=/api/

API_BASE_URL

Die Basis-URL, die das Frontend für den Zugriff auf die NocoBase-API verwendet. Standardmäßig leer, was bedeutet, dass ${APP_PUBLIC_PATH}api/ derselben Origin verwendet wird.

API_BASE_URL=

Setzen Sie diesen Wert nur auf die vollständige API-Adresse, wenn Seiten und API-Dienst unterschiedliche Origins haben (abweichendes Protokoll, Domain oder Port):

API_BASE_URL=https://api.example.com/api/
Hinweise zu ursprungsübergreifenden Bereitstellungen

NocoBase verwendet Cookies, um den Anmeldestatus und den Zugriff auf stabile Datei-URLs zu autorisieren. Wenn API_BASE_URL auf eine andere Origin als die Seiten zeigt:

  • Der Ursprung der Seiten muss zu CORS_ORIGIN_WHITELIST hinzugefügt werden. Andernfalls ignoriert der Browser Set-Cookie in API-Antworten, das Anmelde-Cookie wird nicht gespeichert und Cookie-abhängige Funktionen wie Dateivorschau und Download schlagen mit 403 fehl.
  • Cookies werden pro hostname gespeichert. Wenn Seiten und API vollständig unterschiedliche Domains verwenden, senden Aufrufe stabiler /files/-URLs über die Seitendomain nicht das Anmelde-Cookie mit, das unter der API-Domain gespeichert wurde. Dadurch schlägt der Dateizugriff weiterhin fehl.

Es ist empfehlenswert, Seiten und API per Reverse-Proxy unter derselben Origin bereitzustellen und API_BASE_URL leer zu lassen.

CORS_ORIGIN_WHITELIST

Whitelist von Origins, die ursprungsübergreifend mit Anmeldeinformationen (Cookies) auf die API zugreifen dürfen. Mehrere Origins werden durch Kommas getrennt. Standardmäßig leer.

CORS_ORIGIN_WHITELIST=https://www.example.com,https://admin.example.com
  • Wenn nichts konfiguriert ist, gelten nur Requests derselben Origin als vertrauenswürdig. Ursprungsübergreifende Requests können die API weiterhin anonym aufrufen, der Browser darf dafür jedoch keine Cookies lesen oder schreiben.
  • Wenn konfiguriert, erhalten Origins in der Whitelist einen exakt zurückgegebenen Access-Control-Allow-Origin-Header sowie Access-Control-Allow-Credentials: true, sodass der Browser bei ursprungsübergreifenden Requests Anmelde-Cookies senden und speichern kann.
  • Die Anmelde-API prüft Origin und Referer der Anfrage. Ursprungsübergreifende Anmelde-Requests von Origins außerhalb der Whitelist werden mit 403 abgelehnt.

CLUSTER_MODE

v1.6.0+

Der Multi-Core- (Cluster-) Startmodus der Anwendung. Wenn diese Variable konfiguriert ist, wird sie als Parameter -i <instances> an den pm2 start-Befehl übergeben. Die Optionen stimmen mit dem pm2 -i-Parameter überein (siehe PM2: Cluster Mode) und umfassen:

  • max: Verwendet die maximale Anzahl an CPU-Kernen
  • -1: Verwendet die maximale Anzahl an CPU-Kernen minus eins
  • <number>: Gibt die Anzahl der Kerne an

Der Standardwert ist leer, was bedeutet, dass der Modus nicht aktiviert ist.

Achtung

Dieser Modus erfordert die Verwendung von Plugins, die mit dem Cluster-Modus zusammenhängen. Andernfalls kann es zu unerwarteten Problemen mit der Funktionalität der Anwendung kommen.

Weitere Informationen finden Sie unter: Cluster-Modus.

PLUGIN_PACKAGE_PREFIX

Das Präfix für den Paketnamen des Plugins. Der Standardwert ist @nocobase/plugin-,@nocobase/preset-.

Wenn Sie beispielsweise das hello Plugin zu Ihrem my-nocobase-app-Projekt hinzufügen, lautet der vollständige Paketname des Plugins @my-nocobase-app/plugin-hello.

PLUGIN_PACKAGE_PREFIX kann wie folgt konfiguriert werden:

PLUGIN_PACKAGE_PREFIX=@nocobase/plugin-,@nocobase/preset-,@my-nocobase-app/plugin-

Die Zuordnung zwischen Plugin-Namen und Paketnamen ist dann wie folgt:

  • Der Paketname des users Plugins ist @nocobase/plugin-users
  • Der Paketname des nocobase Plugins ist @nocobase/preset-nocobase
  • Der Paketname des hello Plugins ist @my-nocobase-app/plugin-hello

DB_DIALECT

Der Datenbanktyp. Verfügbare Optionen sind:

  • mariadb
  • mysql
  • postgres
DB_DIALECT=mysql

DB_HOST

Der Datenbank-Host (erforderlich bei Verwendung von MySQL- oder PostgreSQL-Datenbanken).

Der Standardwert ist localhost.

DB_HOST=localhost

DB_PORT

Der Datenbank-Port (erforderlich bei Verwendung von MySQL- oder PostgreSQL-Datenbanken).

  • Der Standard-Port für MySQL und MariaDB ist 3306
  • Der Standard-Port für PostgreSQL ist 5432
DB_PORT=3306

DB_DATABASE

Der Datenbankname (erforderlich bei Verwendung von MySQL- oder PostgreSQL-Datenbanken).

DB_DATABASE=nocobase

DB_USER

Der Datenbank-Benutzer (erforderlich bei Verwendung von MySQL- oder PostgreSQL-Datenbanken).

DB_USER=nocobase

DB_PASSWORD

Das Datenbank-Passwort (erforderlich bei Verwendung von MySQL- oder PostgreSQL-Datenbanken).

DB_PASSWORD=nocobase

DB_TABLE_PREFIX

Das Präfix für Datenbanktabellen.

DB_TABLE_PREFIX=nocobase_

DB_UNDERSCORED

Gibt an, ob Datenbanktabellen- und Feldnamen in den Snake-Case-Stil konvertiert werden sollen. Der Standardwert ist false. Wenn Sie eine MySQL- (MariaDB-) Datenbank verwenden und lower_case_table_names=1 gesetzt ist, muss DB_UNDERSCORED auf true gesetzt werden.

Warning

Wenn DB_UNDERSCORED=true ist, stimmen die tatsächlichen Tabellen- und Feldnamen in der Datenbank nicht mit denen überein, die in der Benutzeroberfläche angezeigt werden. Zum Beispiel wird orderDetails in der Datenbank als order_details gespeichert.

DB_LOGGING

Der Schalter für die Datenbankprotokollierung. Der Standardwert ist off. Verfügbare Optionen sind:

  • on Aktiviert
  • off Deaktiviert
DB_LOGGING=on

DB_POOL_MAX

Die maximale Anzahl von Verbindungen im Datenbank-Verbindungspool. Der Standardwert ist 5.

DB_POOL_MIN

Die minimale Anzahl von Verbindungen im Datenbank-Verbindungspool. Der Standardwert ist 0.

DB_POOL_IDLE

Die maximale Leerlaufzeit, in Millisekunden, die eine Verbindung im Datenbank-Verbindungspool haben kann, bevor sie freigegeben wird. Der Standardwert ist 10000 (10 Sekunden).

DB_POOL_ACQUIRE

Die maximale Wartezeit, in Millisekunden, die der Pool versucht, eine Verbindung herzustellen, bevor ein Fehler ausgelöst wird. Der Standardwert ist 60000 (60 Sekunden).

DB_POOL_EVICT

Das Zeitintervall, in Millisekunden, nach dem der Verbindungspool inaktive Verbindungen entfernt. Der Standardwert ist 1000 (1 Sekunde).

DB_POOL_MAX_USES

Die Anzahl der Verwendungen einer Verbindung, bevor sie verworfen und ersetzt wird. Der Standardwert ist 0 (unbegrenzt).

LOGGER_TRANSPORT

Die Methode zur Protokollausgabe. Mehrere Werte werden durch Kommas getrennt. Der Standardwert in der Entwicklungsumgebung ist console, in der Produktionsumgebung console,dailyRotateFile. Optionen:

  • console - console.log
  • file - Ausgabe in eine Datei
  • dailyRotateFile - Ausgabe in täglich rotierende Dateien
LOGGER_TRANSPORT=console,dailyRotateFile

LOGGER_LEVEL

Die Protokoll-Ausgabestufe. Der Standardwert in der Entwicklungsumgebung ist debug, in der Produktionsumgebung info. Optionen:

  • error
  • warn
  • info
  • debug
  • trace
LOGGER_LEVEL=info

Die Protokollausgabestufe der Datenbank ist debug. Ob diese ausgegeben wird, wird von DB_LOGGING gesteuert und ist unabhängig von LOGGER_LEVEL.

LOGGER_MAX_FILES

Die maximale Anzahl der aufzubewahrenden Protokolldateien.

  • Wenn LOGGER_TRANSPORT auf file gesetzt ist, beträgt der Standardwert 10.
  • Wenn LOGGER_TRANSPORT auf dailyRotateFile gesetzt ist, wird [n]d für die Anzahl der Tage verwendet. Der Standardwert ist 14d.
LOGGER_MAX_FILES=14d

LOGGER_MAX_SIZE

Protokollrotation nach Größe.

  • Wenn LOGGER_TRANSPORT auf file gesetzt ist, ist die Einheit Byte. Der Standardwert ist 20971520 (20 * 1024 * 1024).
  • Wenn LOGGER_TRANSPORT auf dailyRotateFile gesetzt ist, können Sie [n]k, [n]m, [n]g verwenden. Standardmäßig nicht konfiguriert.
LOGGER_MAX_SIZE=20971520

LOGGER_FORMAT

Das Format der Protokollausgabe. Der Standardwert in der Entwicklungsumgebung ist console, in der Produktionsumgebung json. Optionen:

  • console
  • json
  • logfmt
  • delimiter
LOGGER_FORMAT=json

Referenz: Protokollformat

CACHE_DEFAULT_STORE

Der eindeutige Bezeichner für die Caching-Methode, der den Standard-Cache des Servers angibt. Der Standardwert ist memory. Integrierte Optionen sind:

  • memory
  • redis
CACHE_DEFAULT_STORE=memory

CACHE_MEMORY_MAX

Die maximale Anzahl von Elementen im Speicher-Cache. Der Standardwert ist 2000.

CACHE_MEMORY_MAX=2000

CACHE_REDIS_URL

Die Redis-Verbindungs-URL, optional. Beispiel: redis://localhost:6379

CACHE_REDIS_URL=redis://localhost:6379

TELEMETRY_ENABLED

Aktiviert die Erfassung von Telemetriedaten. Der Standardwert ist off.

TELEMETRY_ENABLED=on

TELEMETRY_METRIC_READER

Die aktivierten Metrik-Kollektoren für die Überwachung. Der Standardwert ist console. Andere Werte sollten sich auf die Namen beziehen, die von den entsprechenden Plugin-Kollektoren registriert wurden, z. B. prometheus. Mehrere Werte werden durch Kommas getrennt.

TELEMETRY_METRIC_READER=console,prometheus

TELEMETRY_TRACE_PROCESSOR

Die aktivierten Trace-Datenprozessoren. Der Standardwert ist console. Andere Werte sollten sich auf die Namen beziehen, die von den entsprechenden Plugin-Prozessoren registriert wurden. Mehrere Werte werden durch Kommas getrennt.

TELEMETRY_TRACE_PROCESSOR=console

SERVER_REQUEST_WHITELIST

Whitelist der erlaubten Ziele für ausgehende HTTP-Anfragen, die vom NocoBase-Server initiiert werden. Kommagetrennte Liste aus exakten IPs, CIDR-Bereichen, exakten Hostnamen und einstufigen Platzhalter-Subdomains.

SERVER_REQUEST_WHITELIST=api.example.com,*.trusted.com,10.0.0.0/8,127.0.0.1

Gilt für: Workflow-Knoten „HTTP-Anfrage", Aktionsschaltflächen für benutzerdefinierte Anfragen, AI-Dienste und andere serverseitige Anfragen. Relative Pfade (Aufrufe der NocoBase-API selbst) sind nicht betroffen.

Nicht konfiguriert: Alle ausgehenden http / https-Anfragen bleiben aus Kompatibilitätsgründen erlaubt. Wenn das Ziel jedoch eine Loopback-, private, link-local- oder Metadata-Adresse ist oder eine Domain auf eine solche Adresse auflöst, schreibt der Server eine Warnung ins Log.

Konfiguriert: Die ursprüngliche Anfrage und jedes Weiterleitungsziel müssen der Whitelist entsprechen. Bei fehlender Übereinstimmung erzeugt NocoBase einen Fehler, bevor die nächste Anfrage gesendet wird. Zukünftige Versionen können das Standardverhalten schrittweise verschärfen. Wenn deine Bereitstellung interne Dienste erreichen muss, konfiguriere vorab eine explizite Whitelist.

Unterstützte Formate:

FormatBeispielTrifft zu auf
Exakte IPv41.2.3.4Nur diese IP
IPv4 CIDR10.0.0.0/8Alle IPs im Subnetz
Exakte IPv6::1Nur diese IP
IPv6 CIDRfc00::/7Alle IPs im Subnetz
Exakter Hostnameapi.example.comNur dieser Hostname
Platzhalter-Subdomain*.example.comEine Subdomain-Ebene, z. B. foo.example.com; nicht example.com oder a.b.example.com
Note

Wenn eine Domain in der Whitelist konfiguriert ist, verwendet die Whitelist-Prüfung den Host in der Request-URL. Mit anderen Worten: Nach der Konfiguration von internal.example.com gilt dieses Ziel als explizit erlaubt, auch wenn die Domain auf 127.0.0.1 oder eine private Adresse auflöst.

Experimentelle Umgebungsvariablen

APPEND_PRESET_LOCAL_PLUGINS

Dient zum Anhängen vordefinierter, nicht aktivierter Plugins. Der Wert ist der Paketname (der name-Parameter in package.json), wobei mehrere Plugins durch Kommas getrennt werden.

Info
  1. Stellen Sie sicher, dass das Plugin lokal heruntergeladen wurde und im Verzeichnis node_modules gefunden werden kann. Weitere Details finden Sie unter Plugin-Organisation.
  2. Nachdem Sie die Umgebungsvariable hinzugefügt haben, wird das Plugin auf der Plugin-Manager-Seite erst nach einer Erstinstallation (nocobase install) oder einem Upgrade (nocobase upgrade) angezeigt.
APPEND_PRESET_LOCAL_PLUGINS=@my-project/plugin-foo,@my-project/plugin-bar

APPEND_PRESET_BUILT_IN_PLUGINS

Dient zum Anhängen integrierter Plugins, die standardmäßig installiert werden. Der Wert ist der Paketname (der name-Parameter in package.json), wobei mehrere Plugins durch Kommas getrennt werden.

Info
  1. Stellen Sie sicher, dass das Plugin lokal heruntergeladen wurde und im Verzeichnis node_modules gefunden werden kann. Weitere Details finden Sie unter Plugin-Organisation.
  2. Nachdem Sie die Umgebungsvariable hinzugefügt haben, wird das Plugin bei der Erstinstallation (nocobase install) oder einem Upgrade (nocobase upgrade) automatisch installiert oder aktualisiert.
APPEND_PRESET_BUILT_IN_PLUGINS=@my-project/plugin-foo,@my-project/plugin-bar

Temporäre Umgebungsvariablen

Die Installation von NocoBase kann durch das Setzen temporärer Umgebungsvariablen unterstützt werden, zum Beispiel:

yarn cross-env \
  INIT_APP_LANG=en-US \
  INIT_ROOT_EMAIL=demo@nocobase.com \
  INIT_ROOT_PASSWORD=admin123 \
  INIT_ROOT_NICKNAME="Super Admin" \
  nocobase install

# Entspricht
yarn nocobase install \
  --lang=en-US \
  --root-email=demo@nocobase.com \
  --root-password=admin123 \
  --root-nickname="Super Admin"

# Entspricht
yarn nocobase install -l en-US -e demo@nocobase.com -p admin123 -n "Super Admin"

INIT_APP_LANG

Die Sprache während der Installation. Der Standardwert ist en-US. Verfügbare Optionen sind:

  • en-US
  • zh-CN
yarn cross-env \
  INIT_APP_LANG=en-US \
  nocobase install

INIT_ROOT_EMAIL

Die E-Mail-Adresse des Root-Benutzers.

yarn cross-env \
  INIT_APP_LANG=en-US \
  INIT_ROOT_EMAIL=demo@nocobase.com \
  nocobase install

INIT_ROOT_PASSWORD

Das Passwort des Root-Benutzers.

yarn cross-env \
  INIT_APP_LANG=en-US \
  INIT_ROOT_EMAIL=demo@nocobase.com \
  INIT_ROOT_PASSWORD=admin123 \
  nocobase install

INIT_ROOT_NICKNAME

Der Spitzname des Root-Benutzers.

yarn cross-env \
  INIT_APP_LANG=en-US \
  INIT_ROOT_EMAIL=demo@nocobase.com \
  INIT_ROOT_PASSWORD=admin123 \
  INIT_ROOT_NICKNAME="Super Admin" \
  nocobase install