You can use an external .conf file for configuration:

1. Create the config file:

   cp config/mynetwork.conf.example config/mynetwork.conf
   # Edit config/mynetwork.conf to your needs

2. Mount the file in Docker:
   Uncomment the line in docker-compose.yml:

   volumes:
     - mynetwork_data:/app/data
     - ./config/mynetwork.conf:/app/config/mynetwork.conf:ro

3. Automatic sync:

   • On startup, if the .conf file exists → import into the database
   • If the file does not exist → export current configuration

4. API endpoints:

   • GET /api/config/export - Export current configuration
   • POST /api/config/import - Import from file
   • GET /api/config/file - Check file status
   • POST /api/config/sync - Manual sync

If you use nginx as a reverse proxy in front of MynetworK, set PUBLIC_URL to the public URL (via nginx), not the Docker container URL.

Case 1: Without nginx (direct access)
No PUBLIC_URL needed. The app works on the mapped port (e.g. http://YOUR_IP:7505).

Case 2: With nginx (reverse proxy)

1. Nginx config: See Docs/nginx.example.conf for a full example.
2. docker-compose.yml:

   environment:
     - PUBLIC_URL=http://mynetwork.example.com
     # Or with HTTPS:
     # - PUBLIC_URL=https://mynetwork.example.com

3. Minimal nginx example:

   server {
       listen 80;
       server_name mynetwork.example.com;
       location / {
           proxy_pass http://192.168.1.150:7505;
           proxy_http_version 1.1;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection 'upgrade';
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_cache_bypass $http_upgrade;
       }
   }

4. Benefits of nginx: SSL/HTTPS (e.g. Let's Encrypt), multiple services on one server, caching, clean URLs.

See Docs/nginx.example.conf for a complete HTTP/HTTPS setup.

Critical – Security: The default JWT secret (change-me-in-production-please-use-strong-secret) is for development only. In production you must set the JWT_SECRET environment variable to a unique, strong value.

JWT_SECRET is used to sign and verify JWT authentication tokens. A weak or default secret allows an attacker to:

• Forge valid JWTs and impersonate any user
• Access the system without authentication (full admin access)
• Compromise all users and their data
• Change permissions and access restricted features

JWT_SECRET is loaded at server startup in server/services/authService.ts from process.env.JWT_SECRET. If unset, the default value is used and a warning is logged. The secret is used to sign tokens on login and verify them on authenticated requests.

Docker Compose automatically reads .env at project root.

1. Generate a strong secret (at least 32 characters):

   # Linux/macOS:
   openssl rand -base64 32
   
   # Windows PowerShell:
   [Convert]::ToBase64String((1..32 | ForEach-Object { Get-Random -Maximum 256 }))

2. Create a .env file at project root:

   # .env
   JWT_SECRET=your_generated_secret_here_minimum_32_chars
   
   DASHBOARD_PORT=7505
   FREEBOX_HOST=mafreebox.freebox.fr
   PUBLIC_URL=https://mynetwork.example.com

3. Restrict permissions:

   chmod 600 .env

4. Start with Docker Compose:

   docker-compose up -d

echo "JWT_SECRET=$(openssl rand -base64 32)" > .env.production
docker-compose --env-file .env.production up -d

After startup, check that a custom secret is in use:

docker-compose logs | grep -i "jwt\|secret"

If you see a warning like: "Using default JWT secret. Please set JWT_SECRET...", then JWT_SECRET was not set correctly.

In the web UI: Administration → Security → JWT configuration section shows whether the default secret is used.

1. Length: At least 32 characters (64 recommended)
2. Random: Use random data, not predictable passwords
3. Unique: Each production instance should have its own secret
4. Storage: Restrict .env permissions (chmod 600), add .env to .gitignore, use a secrets manager for critical deployments
5. Rotation: Change the secret periodically (e.g. every 6–12 months) or if compromise is suspected
6. Dev vs prod: Use different secrets for development and production

1. Generate a new secret: openssl rand -base64 32
2. Update .env: JWT_SECRET=new_secret
3. Restart: docker-compose restart
4. All users will need to log in again (existing tokens are invalidated).

# .env – Production

JWT_SECRET=your_openssl_generated_secret_here

DASHBOARD_PORT=7505
FREEBOX_HOST=mafreebox.freebox.fr
PUBLIC_URL=https://mynetwork.example.com

• Multi-source statistics - Unified view of all plugin data
• Real-time charts - Throughput, connections, stats
• Network overview - Global state of your infrastructure

• Centralized configuration - UI to configure each plugin
• Enable/disable - Fine-grained control of each data source
• Connection status - Check each plugin’s state

• Full dashboard - All Freebox features (WiFi, LAN, Downloads, VMs, TV, Phone)
• Compatibility - Ultra, Delta, Pop
• Native API - Official Freebox OS API

• Network monitoring - AP stats, clients, traffic
• Multi-site - Multiple UniFi sites
• Real-time data - Automatic stats updates
• Dual API - Local Controller (node-unifi) and Site Manager API (cloud)
• Stats badges - System stats in header (throughput, uptime, devices)

• Auto discovery - Full local network scan (IPs, MAC, hostnames)
• Vendor detection - Automatic manufacturer identification (Wireshark DB, Freebox/UniFi, or external API)
• Scheduled scans - Periodic full scan and refresh
• History - Device evolution over time with charts
• Wireshark vendor DB - Full integration with Wireshark manuf and auto-update
• Priority system - Hostname/vendor detection order (Freebox, UniFi, Scanner)
• Modern UI - Interactive table with sort, filters, search and inline hostname editing

• Full CRUD - Create, edit, delete users
• Roles - Permissions (admin, user, viewer)
• Security - Passwords hashed with bcrypt

• Full traceability - All actions logged
• Advanced filters - By user, plugin, action, level, period
• Export - Log export (planned)

MynetworK uses a modular architecture:

• React frontend (TypeScript) - Modern UI
• Express backend (TypeScript) - REST API and WebSocket
• SQLite database - Configuration and data storage
• Plugin system - Extensible architecture for new data sources

See DEV/ARCHITECTURE_PLUGINS.md for details.

• CHANGELOG.md - Change log and new features

See DEV/README-DEV.md for development documentation.

Main docs:

• DEV/DOCUMENTATION.md - Documentation index
• DEV/GUIDE_DEVELOPPEMENT.md - Developer guide
• DEV/ARCHITECTURE_PLUGINS.md - Plugin architecture

Docs folder (Docs/): Setup and production guides (UniFi, Freebox, env vars, Nginx, troubleshooting, reset). Key docs have English and French versions (see Docs/README.md).