Eine Electron-App lässt sich auf drei Ebenen konfigurieren: Command-Line-Argumente (für eigene Switches und Chromium-Flags), Environment-Variablen (für Build- und Runtime-Mode) und App-interne Config-Files. Hier die wichtigsten Wege und wann welcher passt.

01 · Abschnitt

Eigene Command-Line-Argumente

process.argv enthält die Args wie in jedem Node-Prozess. Achtung: bei Electron sind argv[0] die Electron-Executable und argv[1] der App-Pfad (in Dev) bzw. weitere Argumente in Production:

JavaScript 
// Dev: electron . --debug --port=8080
// process.argv = ['electron', '.', '--debug', '--port=8080']

// Production: my-app.exe --debug --port=8080
// process.argv = ['my-app.exe', '--debug', '--port=8080']

const args = process.argv.slice(app.isPackaged ? 1 : 2);

const isDebug = args.includes('--debug');
const portArg = args.find(a => a.startsWith('--port='));
const port = portArg ? parseInt(portArg.split('=')[1]) : 3000;

isPackaged ? 1 : 2 wegen des unterschiedlichen Argv-Layouts in Dev vs. Production.

Für komplexere CLIs: commander, yargs o. ä. wie bei normalen Node-Apps.

02 · Abschnitt

Chromium-Switches

Chromium akzeptiert hunderte Switches — von Hardware-Beschleunigung bis Memory-Limits.

JavaScript 
// VOR app.whenReady() registrieren!
app.commandLine.appendSwitch('disable-gpu-vsync');
app.commandLine.appendSwitch('lang', 'de-DE');
app.commandLine.appendSwitch('disable-http-cache');

// Mehrere Werte
app.commandLine.appendSwitch('enable-features', 'SharedArrayBuffer');

Klassische Use-Cases:

  • --disable-http-cache während Dev (verhindert Render-Cache-Probleme)
  • --disable-gpu bei Hardware-Problemen auf bestimmten Treibern
  • --lang=de-DE zum Erzwingen der Sprache (Spell-Check, etc.)
  • --enable-features=... für experimentelle Web-APIs

Liste aller Switches: List of Chromium Command Line Switches.

03 · Abschnitt

Debugging mit --inspect

Main-Prozess debuggen — wie jeder Node-Prozess:

Bash 
electron --inspect=5858 .
electron --inspect-brk=5858 .   # mit Halt am Start

Dann in Chrome chrome://inspect öffnen, Connection einrichten — DevTools für den Main. Oder mit VS Code direkt:

JSON .vscode/launch.json 
{
  "type": "node",
  "request": "launch",
  "name": "Electron Main",
  "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron",
  "args": [".", "--inspect=5858"],
  "outputCapture": "std"
}

Im Renderer: DevTools sind eingebaut — Cmd+Alt+I (macOS), Ctrl+Shift+I (Windows/Linux), oder per Code: win.webContents.openDevTools().

04 · Abschnitt

ELECTRON_* Environment-Variablen

Eine Handvoll Env-Variablen steuert Electron-Verhalten:

VariableEffekt
ELECTRON_ENABLE_LOGGINGConsole-Output von Chromium auf stdout
ELECTRON_ENABLE_STACK_DUMPINGStack-Trace bei Crash
ELECTRON_LOG_FILELog-Output in Datei
ELECTRON_DISABLE_SANDBOXSandbox global deaktivieren (NUR Debug!)
ELECTRON_NO_ATTACH_CONSOLEVerhindert Console-Window auf Windows
ELECTRON_OVERRIDE_DIST_PATHCustom Electron-Binary nutzen
Bash Beispiel 
ELECTRON_ENABLE_LOGGING=1 electron .

# mit Logfile
ELECTRON_LOG_FILE=/tmp/app.log ELECTRON_ENABLE_LOGGING=1 electron .

Sehr hilfreich bei „App startet nicht und zeigt nichts" — ELECTRON_ENABLE_LOGGING=1 macht oft das Problem sichtbar.

05 · Abschnitt

App-eigene Konfiguration

Für persistente App-Konfig (Theme, Sprache, letzte Fenster-Größe): electron-store ist der pragmatische Default.

JavaScript 
import Store from 'electron-store';

const store = new Store({
    schema: {
        theme: { type: 'string', enum: ['light','dark','system'], default: 'system' },
        language: { type: 'string', default: 'de' },
        windowBounds: {
            type: 'object',
            default: { width: 1200, height: 800 }
        }
    }
});

const theme = store.get('theme');         // 'system'
store.set('theme', 'dark');

electron-store schreibt JSON in userData — automatisch plattformsicher, mit Schema-Validierung. Mehr im Datenpersistenz-Kapitel.

06 · Abschnitt

Build-Time-Konfiguration

Wer Konstanten zur Build-Zeit injizieren will (API-URL, Feature-Flags), nutzt das via Vite/Webpack:

JavaScript electron.vite.config.js 
import { defineConfig } from 'electron-vite';

export default defineConfig({
    main: {
        define: {
            'process.env.API_URL': JSON.stringify(
                process.env.NODE_ENV === 'production'
                    ? 'https://api.example.com'
                    : 'http://localhost:3000'
            )
        }
    }
});

So wird process.env.API_URL zur Build-Zeit ersetzt — keine Runtime-Lookup-Kosten, keine versehentliche Config-Datei in der Distribution.

07 · Abschnitt

Custom Protocol Handler

App registrieren, damit Links wie myapp://login?token=xyz die App öffnen:

JavaScript 
if (!app.isDefaultProtocolClient('myapp')) {
    app.setAsDefaultProtocolClient('myapp');
}

// macOS: ankommende Links
app.on('open-url', (event, url) => {
    event.preventDefault();
    handleDeepLink(url);
});

// Windows/Linux: kommen via second-instance args
app.on('second-instance', (_event, argv) => {
    const url = argv.find(a => a.startsWith('myapp://'));
    if (url) handleDeepLink(url);
});

Klassischer Use-Case: OAuth-Callback („Login mit GitHub" → Browser-Redirect zu myapp://oauth?code=...).

08 · Abschnitt

Besonderheiten

Chromium-Switches NUR vor app.whenReady().

Nach Init hat appendSwitch keinen Effekt mehr. Pattern: ganz oben in main.js, vor allem anderen — sogar vor Imports, die app.ready triggern könnten.

process.argv-Layout unterscheidet sich Dev vs. Production.

Dev: argv[1] ist der App-Pfad. Production: argv[1] ist schon das erste echte Argument. Mit app.isPackaged umschalten — sonst frisst dein Argument-Parser den Pfad.

ELECTRON_ENABLE_LOGGING=1 ist die Notbremse beim Crash-Debugging.

Wenn die App startet und sofort tot ist — keine Fenster, kein DevTools. Mit dieser Env-Variable schreibt Chromium seine Logs auf stdout, oft mit klarer Fehler-Ursache.

setAsDefaultProtocolClient braucht macOS-Plist-Eintrag.

Auf Windows reicht der API-Aufruf, auf macOS muss in Info.plist zusätzlich der CFBundleURLTypes-Eintrag stehen. electron-builder/Forge generieren das aus der Konfig — manuelle Setups müssen das selbst pflegen.

ELECTRON_DISABLE_SANDBOX niemals in Production.

Kann während Debug nützlich sein, aber nie in einer ausgelieferten App. Sandbox ist eine Sicherheits-Säule — wer sie deaktiviert, öffnet sich für jede Web-Schwachstelle.

Build-Time-Konstanten besser als Runtime-Config.

Was sich nach Build nicht ändern soll (API-URLs für Dev/Prod, Feature-Flags), via define injizieren — keine if (process.env.NODE_ENV) zur Runtime, kein versehentliches Auslieferen einer .env-Datei.

09 · Abschnitt

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Grundlagen

Zur Übersicht