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

> Discover the purpose of the apps directory in the makeplane/plane monorepo. Understand how it organizes web frontend, backend, and microservices for shared code.

- Repository: [Plane/plane](https://github.com/makeplane/plane)
- Tags: architecture
- Published: 2026-06-25

---

**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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/apps/web/src/index.tsx), which initializes the React component tree and MobX state stores.

Key technical files:
- [`apps/web/vite.config.ts`](https://github.com/makeplane/plane/blob/main/apps/web/vite.config.ts) – Vite bundler configuration
- [`apps/web/package.json`](https://github.com/makeplane/plane/blob/main/apps/web/package.json) – Dependency declarations and npm scripts

To run the web application in isolation:

```bash
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`](https://github.com/makeplane/plane/blob/main/apps/api/manage.py).

The [`package.json`](https://github.com/makeplane/plane/blob/main/package.json) in this directory wraps Python commands for consistency with the monorepo tooling:

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

```

Start the API server using the workspace filter:

```bash
pnpm dev --filter=api

```

Or using Docker Compose for dependency services:

```bash
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`](https://github.com/makeplane/plane/blob/main/apps/admin/src/index.tsx) renders management interfaces for workspace configuration and system settings.

Run the admin panel independently:

```bash
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`](https://github.com/makeplane/plane/blob/main/apps/live/src/lib/pdf/plane-pdf-exporter.tsx).

Start the live preview service:

```bash
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`](https://github.com/makeplane/plane/blob/main/apps/space/src/index.tsx) exposes core project management features without the full application chrome.

Launch the space application:

```bash
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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/.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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/apps/web/src/index.tsx) for the frontend or [`apps/api/manage.py`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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.