Purpose of the Apps Directory in makeplane/plane: Monorepo Architecture Explained

The apps directory serves as the root container for all runnable applications in the Plane monorepo, housing the web frontend, Django API backend, administrative interfaces, and auxiliary microservices that share code through workspace dependencies.

The apps directory represents the application layer of the makeplane/plane repository, structuring the project as a monorepo where each subfolder contains a self-contained executable component. Every application maintains its own package.json, build configuration, and entry points while importing shared libraries from the packages/ workspace via the workspace:* protocol. This architecture enables independent development cycles for distinct product surfaces while ensuring consistency through common tooling defined in pnpm-workspace.yaml.

Applications Inside the Apps Directory

The apps/ folder contains five distinct applications, each serving a specific role in the Plane ecosystem with isolated build pipelines but shared infrastructure.

apps/web: The Primary Client Application

apps/web is the main Single-Page Application (SPA) that delivers the core Plane user experience in the browser. Bootstrapped by Vite, the application entry point resides at apps/web/src/index.tsx, which initializes the React component tree and MobX state stores.

Key technical files:

• apps/web/vite.config.ts – Vite bundler configuration
• apps/web/package.json – Dependency declarations and npm scripts

To run the web application in isolation:

pnpm dev --filter=web

This command launches the development server at http://localhost:3000 using the Vite configuration without starting other workspace applications.

apps/api: The Django Backend

apps/api contains the Django-based backend providing REST endpoints, GraphQL interfaces, authentication layers, and business logic. Unlike the TypeScript frontend applications, this service uses Python with its entry point at apps/api/manage.py.

The package.json in this directory wraps Python commands for consistency with the monorepo tooling:

{
  "name": "plane-api",
  "scripts": {
    "dev": "python manage.py runserver 0.0.0.0:8000"
  }
}

Start the API server using the workspace filter:

pnpm dev --filter=api

Or using Docker Compose for dependency services:

docker compose -f docker-compose-test.yml up api

apps/admin: Administrative Interface

apps/admin provides a dedicated administrative UI for platform management, built with the same React/Vite stack as the main web application. The entry point at apps/admin/src/index.tsx renders management interfaces for workspace configuration and system settings.

Run the admin panel independently:

pnpm dev --filter=admin

apps/live: PDF and HTML Preview Service

apps/live operates as a specialized service for rendering PDF and HTML snapshots of Plane pages, supporting sharing and print functionality. The service utilizes react-pdf for document generation, with core logic located at apps/live/src/lib/pdf/plane-pdf-exporter.tsx.

Start the live preview service:

pnpm dev --filter=live

apps/space: Embedded Micro-frontend

apps/space delivers a lightweight, embeddable version of the Plane UI designed for iframe integration or standalone micro-frontend deployment. The reduced footprint entry point at apps/space/src/index.tsx exposes core project management features without the full application chrome.

Launch the space application:

pnpm dev --filter=space

Shared Architecture and Code Reuse

The applications in the apps/ directory consume shared libraries defined in the packages/ workspace, creating a unified development environment while maintaining deployment flexibility.

Workspace Dependencies

All applications reference shared code using the workspace:* protocol in their package.json files. Critical shared packages include:

• @plane/ui – Shared React component library ensuring visual consistency
• @plane/shared-state – MobX-based state management stores, including utilities like packages/shared-state/src/utils/work-item-filters/index.ts
• @plane/services – HTTP client wrappers that abstract communication with the Django API
• @plane/utils – Common utility functions and helpers

The workspace configuration in pnpm-workspace.yaml at the repository root defines the glob patterns that include both apps/* and packages/*, enabling this dependency structure.

Cross-Application Communication

Frontend applications (web, admin, space) communicate with the backend (api) exclusively through the @plane/services package, which wraps HTTP calls to the Django server. The live service additionally consumes these APIs to fetch data for PDF generation, demonstrating how auxiliary services integrate with the core platform.

State synchronization across frontend applications relies on shared MobX stores located in packages/shared-state, ensuring that work item filters and UI state remain consistent regardless of which application surface renders the component.

Development Workflow and CI/CD

The apps directory structure supports parallel development and unified quality enforcement. The repository's GitHub Actions workflows, specifically .github/workflows/pull-request-build-lint-web-apps.yml, execute type-checking, linting, and build processes for each application concurrently.

Independent development allows engineers to run targeted commands to spin up only required services, reducing local resource consumption. Consistent tooling ensures that all TypeScript applications share the same compiler configuration (tsconfig.json) and linting rules, preventing configuration drift across the product surface.

Summary

• The apps directory contains all runnable applications in the Plane monorepo, including the web SPA (apps/web), Django API (apps/api), admin UI (apps/admin), PDF service (apps/live), and embedded frontend (apps/space).
• Each application maintains independent build configurations and entry points while sharing code via workspace:* dependencies from the packages/ directory.
• Workspace packages (@plane/ui, @plane/shared-state, @plane/services) provide shared components, state management, and API clients to all applications.
• Development isolation is achieved through PNPM workspace filters (e.g., pnpm dev --filter=web), allowing developers to run specific applications without starting the entire stack.
• CI/CD pipelines process each application in parallel, maintaining code quality across the distributed architecture while respecting individual build requirements.

Frequently Asked Questions

What is the difference between the apps directory and the packages directory in makeplane/plane?

The apps directory contains executable applications with entry points that can be started independently (such as apps/web/src/index.tsx for the frontend or apps/api/manage.py for the backend), while the packages directory contains library code consumed by those applications. Packages like @plane/ui and @plane/shared-state export functions and components but cannot run standalone, whereas every folder under apps/ represents a deployable service or user-facing application.

How do I run only the web frontend without starting the API server?

Use the PNPM workspace filter command to target only the web application: pnpm dev --filter=web. This executes the Vite development server defined in apps/web/vite.config.ts at http://localhost:3000 without initializing the Django backend or other auxiliary services. Note that API-dependent features will require the backend running separately or connected to a remote instance.

Why does the apps/api directory contain a package.json if it is a Python Django project?

The apps/api/package.json exists to normalize the developer experience across the monorepo. It declares npm scripts that wrap Python commands (such as python manage.py runserver), allowing the team to use consistent pnpm dev commands regardless of the underlying runtime. This integration enables the CI/CD pipelines and workspace tooling to treat the API service identically to the TypeScript frontend applications.

Can I deploy the apps/live PDF service independently from the main web application?

Yes, the apps/live service is designed as an independent deployable unit. While it shares code with the main application through @plane/services and @plane/ui, it runs as a separate Node.js process that can be scaled independently for PDF generation workloads. The service uses react-pdf to render documents and communicates with the central API via HTTP, making it suitable for serverless deployment or containerized microservice architectures.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}