What Is the apps/proxy Function in Plane? The Caddy Reverse Proxy Explained

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, 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, 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 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 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:

# Access the web UI (served by the web service)

curl -L http://localhost/

# Access API endpoints (routed to api:8000)

curl -H "Authorization: Bearer <token>" \
     http://localhost/api/v1/workspaces/

Modifying Proxy Routes

To add a new microservice route, edit apps/proxy/Caddyfile.ce:

# Forward /reports/* to a new reports service

reverse_proxy /reports/* reports:4000

After modifying the configuration, restart the container to apply changes:

docker compose restart proxy

Local Development Setup

Start only the proxy container for testing:

docker compose up proxy

Or launch the complete stack:

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 ensures the proxy starts with the command caddy run --config /app/proxy/Caddyfile, maintaining consistent configuration across container restarts.

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