Skip to content

Onboarding Wizard

The onboarding wizard guides you through the initial setup of DUMB, helping you configure core services, debrid credentials, and optional components in a step-by-step process.


Overview

The wizard walks you through:

  1. Selecting core services (orchestrators and related tools)
  2. Running preflight health/readiness checks
  3. Configuring debrid service credentials (when applicable)
  4. Choosing optional services
  5. Customizing service-specific options
  6. Reviewing and applying your configuration

Onboarding flow

%%{ init: { "flowchart": { "curve": "basis" } } }%%
flowchart TD
    A([App start<br/>or launch onboarding])
    B{Onboarding Required?}
    C[Core Service Selection]
    D[Preflight Checks]
    E[Apply Configuration]
    F[Run Setup + Start Services]
    G([Dashboard])

    A ==> B
    B -- No --> G
    B -- Yes --> C
    C ==> D
    D ==> E
    E ==> F
    F ==> G

When to use onboarding

The onboarding wizard runs automatically when:

  • DUMB is started for the first time
  • No core services have been configured
  • You manually navigate to /onboarding

You can also re-run onboarding at any time from the Settings page to reconfigure your setup.


Wizard steps

Step 1: Select core services

Choose one or more core services:

Category Services
Orchestrators Riven Backend, CLI Debrid, Decypharr, InfiniDysk, AltMount
Request/automation Seerr, NeutArr
Media servers Plex, Jellyfin, Emby
Arr services Sonarr, Radarr, Lidarr, Prowlarr, Whisparr

Multiple core services

You can select multiple core services if needed. Each will be configured with its own dependencies.

Guided setup

  1. Choose Debrid, Usenet, or Both.
  2. Choose the Usenet workflow service (Decypharr, InfiniDysk, AltMount, InfiniDysk + AltMount, or All) when using Usenet.
  3. Decide whether to use Arrs (required for Usenet).
  4. If using both workflows, pick Combined or Separate Arr instances.
  5. (Optional) Enable multi-quality Sonarr/Radarr instances.
  6. Select supporting services (Seerr, NeutArr, Profilarr, music/adult Arrs, and optional utilities in later steps).
  7. Click Apply recommendations to populate the core services list.

Arr instance layouts

  • Combined: one Arr instance uses a list-based core_service when multiple workflow services are selected. Decypharr-only hybrid setups keep core_service: decypharr.
  • Separate: Debrid and Usenet get separate Arr instances
  • Multi-quality: Sonarr/Radarr instances are created per quality tier

Step 2: Preflight checks

The wizard performs these blocking frontend-proxied requests before proceeding:

  • GET /api/health
  • GET /api/process/capabilities
  • GET /api/process/core-services
  • GET /api/config
  • GET /api/config/service-ui

Blocking check failures must be resolved before moving to the next step.


Step 3: Configure debrid service

For each debrid-capable core service, provide your debrid credentials:

Field Description
Debrid Service Select your provider (RealDebrid, AllDebrid, etc.)
API Key Your debrid service API key

Finding your API key

For Decypharr, DUMB writes the selected provider, API key, download folder, and mount mode before the service starts for the first time. Decypharr's separate standalone setup wizard should therefore already be complete when you open its UI.


Step 4: Select optional services

Choose additional services to enable:

Category Services
Database/discovery PostgreSQL, pgAdmin, Zilean
Riven UI Riven Frontend
Media automation Tautulli, Bazarr, Pulsarr, Maintainerr
Streaming mediastorm, AIOStreams
Identity/reverse proxy/exposure Authelia, Traefik Proxy Admin, Cloudflared

Optional services are filtered based on core dependencies and earlier selections. For example, PostgreSQL may be enabled/hidden automatically when a selected service requires it.

Authelia is additionally gated by the backend's authelia_integration capability. dmbdb removes it from the Optional Services list when connected to an older backend instead of submitting unsupported setup options.

Selecting Authelia enables PostgreSQL and installs the Authelia runtime, but intentionally does not start Authelia during onboarding. After onboarding, a Stopped or Unhealthy Authelia status is expected until you open its service page and complete Step 1: Configure and start Authelia. Only that first step is required; the DUMB OIDC, TPA OIDC, and ForwardAuth steps are optional. DNS and an HTTPS Traefik route are required before browser SSO can work.

mediastorm first login

Current mediastorm builds use the public first-login credentials admin / admin. During that same sign-in, the login form requires a new password and confirmation before creating the first admin session; this works through Docker and reverse proxies. The later mediastorm onboarding page recognizes that the password is already secured and does not require a second change. DUMB's Optional Services step directs you to the mediastorm service page, where the protected bootstrap file keeps older, pinned, or explicitly customized first-login passwords compatible. mediastorm removes the file and DUMB hides the notice after the password changes.

mediastorm's service-options step also allows its OCI runtime to follow latest or be pinned to a release tag, full commit SHA, or OCI digest. Leave release pinning disabled for normal automatic updates. See the mediastorm version-selection guide before selecting a fixed build.

AIOStreams needs a public URL and dashboard login

AIOStreams can start with its generated local base_url, but remote Stremio clients require a stable trusted HTTPS origin. Set the final hostname, such as https://aiostreams.example.com, then create the matching reverse-proxy route before saving/installing the addon. Onboarding also requires an administrator username and a 12–256-character password for the AIOStreams Dashboard. The Configure page remains public unless you later enable AIOStreams' Auth Required setting. DUMB generates and preserves AIOStreams' separate encryption secret automatically. The initial integration uses SQLite by default; PostgreSQL is an advanced aiostreams.database_uri override rather than an onboarding toggle or guided migration. See AIOStreams.

For GitHub source-build services, the service-options step also exposes commit_sha. Paste the full 40-character SHA to select an immutable source revision. Once the SHA is complete, onboarding clears competing release and branch selections; enabling a release or branch clears the commit pin.


Step 5: Service-specific options

Configure additional settings for selected services:

Example options:

  • Zurg: Custom port, log level
  • rclone: Mount options, log level
  • Phalanx DB: Enable/disable for CLI Debrid
  • Decypharr: FUSE, embedded rclone, external rclone, or no-mount mode
  • AltMount: FUSE, embedded rclone, external rclone, or no-mount mode
  • InfiniDysk: Fresh-install SQLite or PostgreSQL main database
  • AIOStreams: Public base URL and Dashboard administrator credentials

Default values are pre-filled but can be customized.

InfiniDysk onboarding PostgreSQL is fresh-install only

InfiniDysk v1.2.0+ exposes postgres_enabled and postgres_database (default infinidysk) in its service options. Enable PostgreSQL here only for a fresh InfiniDysk installation, matching upstream support.

For an existing SQLite installation, leave the onboarding option disabled. After onboarding, open Database Migration on the InfiniDysk service page and complete DUMB's guarded rehearsal before cutover. The DUMB adapter accepts an official stable v1.2.0-or-newer runtime only while its source SQLite and staged PostgreSQL databases exactly match the supported contract; schema drift blocks migration until DUMB is updated. Only the main db.sqlite moves; metrics.sqlite, warden.db, and usenet-migration.db remain local and require filesystem backups. If the installation still needs an InfiniDysk identity or namespace migration, complete that before making any PostgreSQL selection.

AltMount still needs application setup

Onboarding selects AltMount's mount mode and wires Arr download clients. After first start, create the AltMount administrator, add an NNTP provider, choose an import strategy, and validate the Arr/media-library paths. See the AltMount guide.

Instances

Services that support multiple instances show instance panels on a single page. Each instance can have its own options (including core_service routing).


Step 6: Enable embedded UIs

If your backend supports embedded service UIs, you'll be asked:

Would you like to enable embedded service UIs?

When enabled, you can access service web interfaces directly within the DUMB frontend using embedded tabs, direct link buttons, and split view.


Step 7: Review configuration

Review your complete configuration before applying:

  • Core services selected
  • Debrid credentials (API key masked)
  • Optional services
  • Custom options

Verify before proceeding

Review carefully - the wizard will start services immediately after confirmation.


Step 8: Live setup logs

Watch the setup progress in real-time:

  • Service initialization
  • Dependency resolution
  • Configuration application
  • Startup confirmations

The log viewer shows output from all services being started.


Step 9: Success or error

Success: All services started successfully. You'll be redirected to the dashboard.

Error: If any service failed to start, you'll see:

  • Which services failed
  • Error messages
  • Option to retry or skip

Skipping onboarding

If you prefer to configure services manually:

  1. Navigate to /onboarding
  2. Click Skip Onboarding
  3. Configure services individually in Settings

Manual setup caveats

Onboarding is the preferred way to add or configure services. Manual edits can miss the nuanced wiring DUMB applies for core services, so a manual-only setup may fail to fully configure dependencies and integrations.

Re-running onboarding

You can always return to onboarding from Settings Launch Onboarding.


Configuration applied

The wizard updates dumb_config.json with:

  • Enabled services
  • Debrid API keys (injected into Zurg/Decypharr)
  • Service options
  • Instance configurations

Multi-instance support

For services that support multiple instances (like Zurg or rclone), the wizard:

  • Creates instances linked to core services
  • Names them appropriately (e.g., "Zurg w/ Riven")
  • Configures separate ports to avoid conflicts

For Arr services and NeutArr, instance names can be used to split workflows (e.g., Debrid vs Usenet, or multiple quality tiers).

Combined Arr workflows that include Decypharr plus InfiniDysk or AltMount use /mnt/debrid/combined_symlinks/<slug> for the Decypharr-managed root. An AltMount-only route—or InfiniDysk + AltMount without Decypharr—does not get a combined root automatically.


After onboarding

Once complete:

  1. Dashboard shows your running services
  2. Settings allows further customization
  3. Service UIs are accessible (if enabled)
  4. Logs can be viewed for each service

Troubleshooting

Services fail to start

  • Check logs for specific error messages
  • Verify debrid API key is valid
  • Ensure required ports are available

Can't proceed past a step

  • Fill in all required fields
  • Check for validation errors (red highlights)
  • Refresh the page and try again

Need to change configuration

  • Complete onboarding first
  • Use Settings to modify individual services
  • Or Launch Onboarding to start fresh