feature: Allow workspace admins to pin apps as first-class sidebar entries

[DissectDev]

Feature Request: Pin Apps as First-Class Workspace Sidebar Entries

Summary

Allow workspace admins to pin selected Windmill Apps into the main Windmill workspace sidebar as first-class navigation entries, alongside built-in sections such as Home, Runs, Variables, Resources, Schedules, and Apps.

This would let teams build custom internal control planes, dashboards, catalog views, review consoles, or operational cockpits inside Windmill, without forcing users to first navigate through the generic Apps section.

Motivation

Windmill Apps are powerful enough to become custom management surfaces. Full-code Apps can be built with React or Svelte and connected to Windmill backend runnables and data tables, which makes them suitable for advanced internal tools, control planes, and workflow-specific dashboards.

However, when an App becomes a core workspace surface, it still feels like a second-level object hidden under the Apps area. This creates friction for use cases where the App is not just “an app,” but a workspace-level operating surface.

Examples:

• Capability Catalog
• Asset Catalog
• Workflow Control Center
• Test Dashboard
• Approval Console
• Incident / Runbook Console
• Data Operations Cockpit
• AI Agent Operations Panel

Today, these can be built as Windmill Apps, but they cannot be promoted to the same navigation level as built-in Windmill sections.

Current Workarounds

There are partial workarounds, but none fully solve the problem.

1. Use an App Navbar

The Navbar component can link between Apps and make multi-App navigation feel seamless, but it only works once the user is already inside an App. It does not add an entry to the main Windmill workspace sidebar.

2. Use Sidebar Tabs inside an App

Sidebar Tabs are useful for App-level navigation, but they do not extend the global Windmill sidebar.

3. Use White Labeling / External Shell

Windmill white labeling can embed Windmill or Windmill components into a custom application, but this is heavier than needed when the desired behavior is simply to pin a workspace App into the native sidebar.

4. Bookmark or Deep Link the App

This works technically, but it does not make the App feel like part of the workspace’s primary operating model.

Proposed Feature

Add a workspace-level setting that allows admins to pin one or more Windmill Apps as custom entries in the main left sidebar.

Example conceptual configuration:

workspace_sidebar:
  custom_entries:
    - id: capability_catalog
      title: Capability Catalog
      icon: boxes
      type: app
      app_path: f/catalog/capability_cockpit
      position: after_home
      visible_to:
        roles:
          - admin
          - developer

    - id: approval_console
      title: Approvals
      icon: check-circle
      type: app
      app_path: f/ops/approval_console
      position: after_runs
      visible_to:
        groups:
          - platform-team

The sidebar would then show something like:

Home
Capability Catalog
Runs
Approvals
Variables
Resources
Schedules
Apps

Desired Behavior

1. Pin App to Sidebar

Workspace admins should be able to select an existing Windmill App and pin it to the main sidebar.

This could be exposed through:

• Workspace settings
• App settings
• A new “Pin to sidebar” action
• A workspace-level navigation configuration file
• CLI / API support

2. Custom Label and Icon

The pinned entry should support:

• Display name
• Icon
• Optional badge or count
• Optional grouping or section
• Optional ordering

3. Role-Based Visibility

Visibility should respect Windmill permissions.

A pinned App should only appear if the current user has access to the underlying App.

Optional enhancement: allow admins to further restrict sidebar visibility by role or group.

4. Deep Link Behavior

Clicking the custom sidebar entry should open the App directly, preferably without making the user first pass through the generic Apps list.

5. Optional Badge / Status Support

Pinned Apps could optionally expose a badge value, such as:

Approvals    3
Incidents    1
Tests        7 failed

This could be implemented later through a runnable, query, or static config.

Use Case: Capability Catalog inside Windmill

One concrete use case is a Capability Catalog App.

Windmill already has scripts, flows, resources, apps, labels, jobs, and runs. A custom Capability Catalog App could organize these objects into higher-level concepts:

Capability
  ├── Related scripts
  ├── Related flows
  ├── Related resources
  ├── Recent runs
  ├── Test status
  ├── Owners
  └── Documentation

For this type of App, being hidden under “Apps” is awkward. It is effectively a workspace-level control surface and should be available from the main sidebar.

Why This Matters

Windmill is not only a place to run scripts and flows. It is increasingly a platform where teams can build internal tools, operational surfaces, workflow dashboards, and custom control planes.

If Apps can be promoted into the main workspace navigation, Windmill becomes more extensible without requiring users to fork the frontend or build an external shell.

This would make Windmill better suited for:

• Internal developer platforms
• Platform engineering portals
• Custom operations consoles
• Workflow observability dashboards
• Review and approval systems
• AI agent control panels
• Asset and capability catalogs

Non-Goals

This request is not asking for:

• Replacing the built-in sidebar
• Full plugin architecture
• Forking or customizing Windmill core UI
• Embedding arbitrary external websites
• Making every App appear in the sidebar by default

The goal is simply to allow workspace admins to promote selected Windmill Apps into the main workspace navigation.

Possible Implementation Options

Option A: Workspace-Level Config

A workspace setting stores custom sidebar entries.

{
  "custom_sidebar_entries": [
    {
      "id": "capability_catalog",
      "title": "Capability Catalog",
      "icon": "boxes",
      "type": "app",
      "path": "f/catalog/capability_cockpit",
      "position": "after_home"
    }
  ]
}

Option B: App-Level Setting

Each App can opt into sidebar pinning.

sidebar:
  pinned: true
  title: Capability Catalog
  icon: boxes
  position: after_home

Option C: Hybrid

Apps declare whether they are pinnable, but workspace admins decide whether they are actually pinned.

This is probably the safest model.

Acceptance Criteria

A minimal version of this feature would satisfy:

• Workspace admins can pin an existing App to the main sidebar.
• The pinned App appears alongside built-in Windmill navigation entries.
• The pinned App respects existing App permissions.
• Clicking the sidebar entry opens the App directly.
• Admins can remove or reorder pinned entries.
• The feature works without forking Windmill or using white labeling.

A more advanced version could add:

• Custom icons
• Sidebar groups
• Badges
• CLI / API support
• Git-syncable navigation configuration
• Role/group-specific visibility rules

Suggested Labels

feature-request
apps
ui
navigation
workspace
developer-experience
platform-engineering

Suggested Issue Titles

Recommended:

Allow workspace admins to pin Apps as first-class sidebar entries

Other options:

Support custom workspace sidebar entries for Windmill Apps
Promote selected Apps to the main workspace navigation
Add pinned Apps to the global workspace sidebar
Workspace navigation extensions for custom Apps

Opening Paragraph Option

Windmill Apps can already be powerful enough to act as custom control planes, but they currently remain second-level objects under the Apps section. This feature would let workspace admins promote selected Apps into the primary workspace navigation, making Windmill more extensible without requiring frontend forks or external white-label shells.

[rubenfiszel]

It's an interesting proposal, we will consider it.