👋 Feature Request: Support for Multiple Base URLs / Domains #812

Closed
opened 2026-02-04 21:24:01 +03:00 by OVERLORD · 4 comments
Owner

Originally created by @heyvoon on GitHub (Sep 15, 2025).

Is this a feature for the backend or frontend?

Backend

What would you like?

Description:

Currently, Planka is configured with a single BASE_URL environment variable. This works well for deployments accessible via one primary address.

However, there are scenarios where it would be beneficial to allow Planka to be accessed seamlessly through multiple domains or URLs. For example:

  1. Internal vs. External Access: Accessing Planka via an internal network name (e.g., http://planka.internal.lan) and simultaneously via a public domain (e.g., https://planka.company.com).
  2. Multiple Aliases: Providing different, equally valid entry points for the same Planka instance (e.g., https://planka.teamA.internal and https://planka.projectX.internal).
  3. Reverse Proxy Configurations: Situations where a single Planka instance sits behind a reverse proxy that might be configured to handle multiple incoming server names, but Planka's strict BASE_URL check causes issues like CORS errors if the incoming Host header doesn't match the configured BASE_URL exactly.

Request:

It would be great if Planka could be configured to accept and operate correctly under a list of allowed base URLs/domains. This would involve:

  • Allowing configuration of multiple valid origins (e.g., via a new environment variable like ALLOWED_BASE_URLS or similar).
  • Ensuring internal URL generation, CORS headers, and security checks (like Referer/Origin validation, if used) correctly handle requests coming in via any of the allowed URLs.
  • Potentially providing guidance or built-in flexibility for common reverse proxy setups involving multiple domains.

This would enhance the flexibility of Planka deployments, especially in more complex network environments or when integrating with existing infrastructure that requires or benefits from multiple access points.

Additional Context:

While using a reverse proxy (like Nginx) can make Planka accessible via multiple domains by forwarding to the single internal Planka service, issues can arise if Planka's application logic strictly validates the incoming request's origin against its single BASE_URL. This often manifests as CORS errors in the browser or incorrect URL generation if the application relies heavily on the BASE_URL for constructing links and API endpoints.


Why is this needed?

No response

Other information

No response

Originally created by @heyvoon on GitHub (Sep 15, 2025). ### Is this a feature for the backend or frontend? Backend ### What would you like? **Description:** Currently, Planka is configured with a single `BASE_URL` environment variable. This works well for deployments accessible via one primary address. However, there are scenarios where it would be beneficial to allow Planka to be accessed seamlessly through multiple domains or URLs. For example: 1. **Internal vs. External Access:** Accessing Planka via an internal network name (e.g., `http://planka.internal.lan`) and simultaneously via a public domain (e.g., `https://planka.company.com`). 2. **Multiple Aliases:** Providing different, equally valid entry points for the same Planka instance (e.g., `https://planka.teamA.internal` and `https://planka.projectX.internal`). 3. **Reverse Proxy Configurations:** Situations where a single Planka instance sits behind a reverse proxy that might be configured to handle multiple incoming server names, but Planka's strict `BASE_URL` check causes issues like CORS errors if the incoming `Host` header doesn't match the configured `BASE_URL` exactly. **Request:** It would be great if Planka could be configured to accept and operate correctly under a list of allowed base URLs/domains. This would involve: * Allowing configuration of multiple valid origins (e.g., via a new environment variable like `ALLOWED_BASE_URLS` or similar). * Ensuring internal URL generation, CORS headers, and security checks (like `Referer`/`Origin` validation, if used) correctly handle requests coming in via any of the allowed URLs. * Potentially providing guidance or built-in flexibility for common reverse proxy setups involving multiple domains. This would enhance the flexibility of Planka deployments, especially in more complex network environments or when integrating with existing infrastructure that requires or benefits from multiple access points. **Additional Context:** While using a reverse proxy (like Nginx) can make Planka *accessible* via multiple domains by forwarding to the single internal Planka service, issues can arise if Planka's application logic strictly validates the incoming request's origin against its single `BASE_URL`. This often manifests as CORS errors in the browser or incorrect URL generation if the application relies heavily on the `BASE_URL` for constructing links and API endpoints. --- ### Why is this needed? _No response_ ### Other information _No response_
Author
Owner

@meltyshev commented on GitHub (Sep 15, 2025):

Hey! I already tried adapting this PR to achieve this: https://github.com/plankanban/planka/pull/1278, but it's not so easy to solve.

The main challenge is real-time socket events - all URLs inside the socket data need to be adjusted for each individual socket connection. If User A is connected via http://planka.internal.lan and User B is connected via https://planka.company.com - when User A uploads a new attachment, User B must not receive a URL pointing to http://planka.internal.lan.

Another issue is notifications with links to cards - which URL should we send? We could always pick the first one from BASE_URL as the main one, but that wouldn't necessarily match the domain the user normally connects through.

@meltyshev commented on GitHub (Sep 15, 2025): Hey! I already tried adapting this PR to achieve this: https://github.com/plankanban/planka/pull/1278, but it's not so easy to solve. The main challenge is real-time socket events - all URLs inside the socket data need to be adjusted for each individual socket connection. If User A is connected via `http://planka.internal.lan` and User B is connected via `https://planka.company.com` - when User A uploads a new attachment, User B must not receive a URL pointing to `http://planka.internal.lan`. Another issue is notifications with links to cards - which URL should we send? We could always pick the first one from `BASE_URL` as the main one, but that wouldn't necessarily match the domain the user normally connects through.
Author
Owner

@heyvoon commented on GitHub (Sep 15, 2025):

I was able to solve my issue by using the recommended Nginx Proxy Manager config details in the documentation.
Not ideally a multi domain. But at least I could deploy Planka on my RaspberryPi and serve it with my NPM.
Thank you though!
FYI: The concept of allowing multi domain for an app is "Allowing configuration of multiple valid origins (e.g., via a new environment variable like ALLOWED_BASE_URLS or similar)."

@heyvoon commented on GitHub (Sep 15, 2025): I was able to solve my issue by using the recommended Nginx Proxy Manager config details in the documentation. Not ideally a multi domain. But at least I could deploy Planka on my RaspberryPi and serve it with my NPM. Thank you though! FYI: The concept of allowing multi domain for an app is "Allowing configuration of multiple valid origins (e.g., via a new environment variable like ALLOWED_BASE_URLS or similar)."
Author
Owner

@meltyshev commented on GitHub (Sep 15, 2025):

Ah, if the issue is just about allowing multiple BASE_URL values to prevent CORS errors - will try to add this today 🙂 I'll use the same variable, and if it contains a comma with additional addresses - they'll be allowed as well.

@meltyshev commented on GitHub (Sep 15, 2025): Ah, if the issue is just about allowing multiple `BASE_URL` values to prevent CORS errors - will try to add this today 🙂 I'll use the same variable, and if it contains a comma with additional addresses - they'll be allowed as well.
Author
Owner

@heyvoon commented on GitHub (Sep 15, 2025):

YEEESSS! That is exactly it! THANK YOU!

@heyvoon commented on GitHub (Sep 15, 2025): YEEESSS! That is exactly it! THANK YOU!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/planka#812