# What Is the apps/proxy Function in Plane? The Caddy Reverse Proxy Explained > Discover how the apps/proxy in Plane uses Caddy as a reverse proxy to manage external traffic, route requests to microservices, and handle automatic TLS termination for your applications. - Repository: [Plane/plane](https://github.com/makeplane/plane) - Tags: deep-dive - Published: 2026-08-22 --- **The `apps/proxy` directory implements Plane's reverse-proxy layer using Caddy, serving as the central traffic entry point that routes external HTTP/HTTPS requests to the appropriate microservices while handling automatic TLS termination.** The `apps/proxy` component is a critical infrastructure layer in Plane (`makeplane/plane`), an open-source project management platform. This service acts as the gateway between external clients and Plane's distributed microservice architecture, ensuring secure and efficient request distribution without exposing individual backend services directly to the internet. ## Core Responsibilities of the apps/proxy Service ### Central Traffic Entry Point All external HTTP and HTTPS requests first hit the proxy container on standard ports 80 and 443. According to the repository's [`docker-compose.yml`](https://github.com/makeplane/plane/blob/main/docker-compose.yml), the proxy service builds from `apps/proxy/Dockerfile.ce` and mounts the Caddy configuration, making it the sole public-facing component of the architecture. This design pattern isolates internal services while providing a unified access point for users. ### Intelligent Request Routing The `apps/proxy/Caddyfile.ce` defines specific `reverse_proxy` directives that map URL paths to backend services based on the following rules: - **`/spaces/*`** → **Space** service (`space:3000`) - **`/god-mode/*`** → **Admin** service (`admin:3000`) - **`/live/*`**, **`/api/*`**, **`/auth/*`**, **`/static/*`** → **API** service (`api:8000`) - **`/{$BUCKET_NAME}/*`** → **MinIO** storage (`plane-minio:9000`) - **All other traffic** → **Web** frontend (`web:3000`) This path-based routing ensures that API calls, static assets, and application UI requests reach the correct containers without requiring separate subdomains or ports for each service. ### TLS Termination and Certificate Management Caddy automatically handles HTTPS by generating and renewing certificates via Let's Encrypt, or by utilizing provided certificates in production environments. This eliminates manual SSL configuration and ensures encrypted connections terminate at the proxy layer before traffic flows internally through Docker's private network. ## Architecture and Integration ### Docker Compose Integration The proxy service is declaratively defined in [`docker-compose.yml`](https://github.com/makeplane/plane/blob/main/docker-compose.yml), which specifies the build context from `apps/proxy/Dockerfile.ce` and volume mounts for the Caddyfile configuration. This integration allows developers to launch the entire Plane stack with a single `docker compose up` command. ### All-in-One Deployment Support In the AIO (All-in-One) deployment model, [`deployments/aio/community/supervisor.conf`](https://github.com/makeplane/plane/blob/main/deployments/aio/community/supervisor.conf) manages the proxy as a Supervisor program running `caddy run --config /app/proxy/Caddyfile`. This ensures the proxy starts automatically alongside other Plane components in self-hosted environments. ### CI/CD Pipeline Integration The GitHub Actions workflow defined in [`.github/workflows/build-branch.yml`](https://github.com/makeplane/plane/blob/main/.github/workflows/build-branch.yml) includes specific build steps for the proxy image. The CI pipeline compiles and publishes the proxy container as part of the multi-service build process, ensuring versioned releases align with core application updates. ## Security and Network Isolation The proxy architecture enforces security boundaries by preventing ambient proxy leakage. The API layer explicitly disables ambient proxy usage (`session.trust_env = False`) to prevent unwanted routing through external proxies, ensuring that internal microservice communications remain isolated within Docker's network namespace. ## Practical Usage Examples ### Routing Requests Through the Proxy When running Plane locally, all services communicate through the proxy layer: ```bash # Access the web UI (served by the web service) curl -L http://localhost/ # Access API endpoints (routed to api:8000) curl -H "Authorization: Bearer " \ http://localhost/api/v1/workspaces/ ``` ### Modifying Proxy Routes To add a new microservice route, edit `apps/proxy/Caddyfile.ce`: ```caddy # Forward /reports/* to a new reports service reverse_proxy /reports/* reports:4000 ``` After modifying the configuration, restart the container to apply changes: ```bash docker compose restart proxy ``` ### Local Development Setup Start only the proxy container for testing: ```bash docker compose up proxy ``` Or launch the complete stack: ```bash docker compose up -d ``` ## Summary - The `apps/proxy` function in Plane implements a **Caddy-based reverse proxy** that serves as the central gateway for all external traffic. - Configuration in **`apps/proxy/Caddyfile.ce`** defines path-based routing to microservices including Web (`web:3000`), API (`api:8000`), Space (`space:3000`), Admin (`admin:3000`), and MinIO storage. - The proxy handles **TLS termination automatically** via Let's Encrypt or custom certificates, simplifying HTTPS deployment. - Integration spans **Docker Compose**, **Supervisor-based AIO deployments**, and **GitHub Actions CI/CD pipelines** for automated builds. - Security measures include disabling ambient proxy settings in the API layer to prevent unintended request routing. ## Frequently Asked Questions ### What technology does Plane use for its reverse proxy? Plane uses **Caddy** as its reverse proxy implementation. The `apps/proxy` directory contains the Caddyfile configuration (`Caddyfile.ce`) and Dockerfile that build the proxy container. Caddy was chosen for its automatic HTTPS capabilities, simple configuration syntax, and native Docker integration. ### How does the Plane proxy route requests to different services? The proxy uses path-based routing defined in `apps/proxy/Caddyfile.ce`. Specific URL prefixes like `/api/*`, `/spaces/*`, and `/god-mode/*` are mapped to their respective backend containers using Caddy's `reverse_proxy` directive. Any unmatched traffic defaults to the Web frontend service. ### Can I replace the Caddy proxy with Nginx or Traefik in Plane? Yes, the proxy layer is interchangeable. Since `apps/proxy` functions as a standalone container that merely forwards traffic to named Docker services (`web`, `api`, `space`, etc.), you can substitute Caddy with Nginx, Traefik, or another reverse proxy by maintaining the same internal routing rules and service names. No modifications to the core Plane services are required. ### Where is the Plane proxy configured in production deployments? In production and AIO deployments, the proxy configuration resides in `apps/proxy/Caddyfile.ce`, which is mounted into the container at runtime. For Supervisor-managed deployments, [`deployments/aio/community/supervisor.conf`](https://github.com/makeplane/plane/blob/main/deployments/aio/community/supervisor.conf) ensures the proxy starts with the command `caddy run --config /app/proxy/Caddyfile`, maintaining consistent configuration across container restarts.