App Management Interface#

The App Management page is the primary workspace-level UI for creating, browsing, and managing applications (prompts/workflows). It is distinct from the organization switcher and project selector — it operates within a selected project context.

Entry point: web/oss/src/components/pages/app-management/index.tsx

Page Structure#

The AppManagement component renders five main sections in sequence 1:

ObservabilityDashboardSection and DemoApplicationsSection are lazy-loaded via next/dynamic to reduce initial bundle size 2.

App Data#

Apps are fetched via the useAppsData context hook, which calls /api/apps?project_id={projectId} using SWR 3. The fetch is gated on authentication, a valid project ID, and an active organization selection.

Each app is typed as ListAppsItem:

{ app_id: string; app_name: string; app_type?: string; updated_at: string }

Apps are sorted descending by updated_at before display and filtered client-side by the search term 4.

ApplicationManagementSection#

ApplicationManagementSection is the core listing component. Key features:

• Dual view modes: card grid and table list, toggled by a Radio.Group and persisted to localStorage under the key app_management_display 5.
• Search: client-side filter input that updates searchTerm in the parent 6.
• Pagination: via the usePagination hook applied to filteredApps 7.
• Create app: the "Create New Prompt" button opens AddAppFromTemplateModal 8.
• Per-app actions: edit and delete, dispatched through EditAppModal and DeleteAppModal 9.
• Empty state: EmptyAppView component is rendered when no apps exist 10.

Card layout is responsive: 2 columns ≤1099 px, 3 up to 1700 px, 4 up to 2000 px, 5 above 11.

App Creation Flow#

App creation is handled in the parent AppManagement component. Two creation paths exist:

1. Template-based (AddAppFromTemplateModal → handleTemplateCardClick): calls createAndStartTemplate from services/app-selector/api, passing the app name, template key, and LLM provider keys. Status updates flow through the onStatusChange callback and are shown in CreateAppStatusModal.

2. Custom workflow (CustomWorkflowModal via useCustomWorkflowConfig): for bring-your-own service deployments 12.

After successful creation, mutate() from useAppsData refreshes the app list and a PostHog app_deployment event is captured 13.

Error and timeout states in template creation each have retry handlers (onErrorRetry, onTimeoutRetry) that clean up any partially created app and restart the flow 14. A MaxAppModal guards against exceeding the workspace app limit 15.

Modals Reference#

Key Files#