Skip to content

DUMB Frontend

The DUMB Frontend is the web UI for managing and monitoring the DUMB ecosystem. It provides service controls, real-time logs, embedded UIs, onboarding, settings, and metrics in a single interface.

Frontend documentation

For detailed guides on using the frontend, see the Frontend Documentation section:

Build and update requirements#

Installing or rebuilding the current frontend requires Node.js >=24.15.0 <25 and pnpm 10. This matches the Nuxt 4.6 toolchain requirements. An older frontend pin follows the engine requirement declared by that selected source.

New DUMB image builds and release validation enforce the current Node range. Frontend updates use the runtime already bundled in the running image; updating frontend source alone does not upgrade Node. Before rebuilding from an older image with Node below 24.15, update the DUMB image and recreate its container using your existing persistent volumes. Separately deployed frontends must provide a compatible Node and pnpm installation.

The frontend source includes a dependency-free Node check in its install and build commands, so those commands can detect an incompatible runtime even on an older DUMB backend. The check reads that source's own package.json; with strict engine validation, pnpm may reject the requirement first with an expected/actual version error. Neither check upgrades Node.

Production starts the compiled Nitro server with node .output/server/index.mjs, which does not run the source check. The version floor above applies to dependency installation and source builds; it does not establish the minimum runtime for every previously compiled frontend.

Configuration Settings in dumb_config.json#

This block is nested at dumb.frontend in /config/dumb_config.json:

"frontend": {
    "enabled": true,
    "process_name": "DUMB Frontend",
    "repo_owner": "nicocapalbo",
    "repo_name": "dmbdb",
    "release_version_enabled": false,
    "release_version": "v1.2.0",
    "commit_sha": "",
    "branch_enabled": false,
    "branch": "main",
    "suppress_logging": false,
    "log_level": "INFO",            
    "log_file": "/log/dumb_frontend.log",
    "origins": [
        "http://0.0.0.0:3005"
    ],
    "host": "0.0.0.0",
    "port": 3005,            
    "auto_update": false,
    "auto_update_interval": 24,
    "auto_update_start_time": "04:00",
    "clear_on_update": true,
    "exclude_dirs": [],
    "platforms": ["pnpm"],
    "command": ["node",".output/server/index.mjs"],
    "config_dir": "/dumb/frontend",
    "env": {}            
}

Configuration Key Descriptions#

  • enabled: Determines whether the DUMB Frontend service is active.
  • process_name: Name used in logs and process tracking.
  • repo_owner / repo_name: Specifies the GitHub repository to clone for the frontend.
  • release_version_enabled / release_version: Indicates if a specific release version should be used.
  • commit_sha: Builds an exact GitHub revision. Use the complete 40-character hexadecimal SHA.
  • branch_enabled / branch: Specifies the branch to use if enabled.
  • suppress_logging: If true, disables log output for this service.
  • log_level: Logging verbosity level (e.g., DEBUG, INFO).
  • host: IP address the frontend should bind to.
  • port: Port the frontend is served on.
  • auto_update: Enables automatic self-updates.
  • auto_update_interval: How often (in hours) to check for updates.
  • clear_on_update: Clears build artifacts or cache during updates.
  • exclude_dirs: Prevents specific directories from being affected by updates when using clear_on_update
  • platforms: Specifies the runtime environment required (pnpm).
  • command: Command to start the frontend service.
  • config_dir: Directory where configuration files are stored.
  • env: Environment variables for the frontend.

Commit / Branch / Version Targeting#

You can control which source revision of the frontend is deployed by setting:

  • commit_sha to a full 40-character SHA for an immutable source pin
  • branch_enabled: true and specifying a branch
  • or release_version_enabled: true and specifying a release_version

commit_sha takes precedence over release and branch settings. Automatic updates remain disabled until the commit pin is changed or cleared.

Accessing the DUMB Frontend#

  • Navigate to: http://<host>:<port>
    • default port 3005

Startup behavior#

DUMB starts its API before the enabled-service preinstall phase. When the frontend runtime is already built and its configured version does not require a new install, DUMB also starts the frontend before that phase. This makes the UI available while the remaining services are still being prepared and started.

Frontend startup remains after the service preinstall phase when any of the following applies:

  • The configured frontend entrypoint is missing.
  • A branch install is enabled.
  • A floating release such as latest, nightly, or prerelease must be resolved.
  • The installed frontend version does not match the configured release version.

In those cases, DUMB keeps the existing install/update path and starts the frontend after its runtime is ready.

Self-update behavior#

Current DUMB releases prepare manual and scheduled frontend updates transactionally. DUMB downloads, builds, and validates the candidate in an adjacent directory while the installed frontend continues serving the dashboard. Only the final atomic directory swap, process restart, and readiness check create frontend downtime.

If the candidate cannot be built or validated, including an unsupported Node version during preparation, DUMB removes it and leaves the current frontend running. If the replacement cannot configure, start, or become ready after activation, DUMB restores and verifies the previous runtime. The frontend's Node check does not add these update or rollback guarantees to older DUMB backends.

An update started from the frontend can briefly interrupt its own HTTP request during the final restart. Current dmbdb clients recognize that transport break, wait for the proxy to return, read the final update status retained by the DUMB API, and reload to pick up the new assets. If automatic confirmation times out, refresh the page and reopen Updates; do not assume the installation failed solely from the interrupted browser request.

Frontend usage guides#

For UI walkthroughs, use the frontend section:

Tips#

  • Automatic Updates: Enable auto_update to keep the frontend up-to-date with the latest features.
  • Log Monitoring: Utilize the service logs functionality for effective monitoring and troubleshooting.

Resources#