[bug]: Unable to run web and api on separate URLs when self-hosting (due to the removal of the `NEXT_PUBLIC_API_BASE_URL` env variable)

[jordibeen]

Is there an existing issue for this?

• [x] I have searched the existing issues

Current behavior

Hey all, I'm wondering why the NEXT_PUBLIC_API_BASE_URL environment variables doesn't work anymore on v0.13.2-dev? I set both NEXT_PUBLIC_API_BASE_URL and BUILT_NEXT_PUBLIC_API_BASE_URL to "http://localhost:8000", but the frontend still tries to request /api/... on the same host.

Even though this code still seems to indicate that it's an environment variable, it looks like this PR "accomplished" to let the frontend always request to /api on the same host. This page also references the removal of this environment variable. I'm not entirely sure why it's being deprecated?

I'm hosting Plane on Kubernetes, and I use the pre-built makeplane/plane-frontend & makeplane/plane-backend images from Docker Hub. So passing it as a "build argument" isn't possible for me. But I do run web and deploy on different services, so I don't want the web and deploy containers to make requests on the same host!

Please reconsider being able to pass custom web and API URLs.

Steps to reproduce

Self-host the pre-built makeplane/plane-frontend & makeplane/plane-backend images from Docker Hub, and run both the web and api on different URLs.

Browser

Other

Version

Self-hosted

[nkigen]

@jordibeen I found a workaround: Have the same url for both the client and api server then in the ingress of the api set the path to /api and set the priority field to something big. e.g.

        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: {{ $appName }}-service
                port:
                  number: 80
            priority: 100

[jordibeen]

@nkigen Thanks! I understand that this is a possibility, but I don't think we should be limited to having the Frontend and API running on the same URL when self-hosting.

[nkigen]

@jordibeen Agreed.

[leikoilja]

same here... added a comment here, since reading the code i dont quite understand why does the frontend start ignoring env variables now.

and passing custom docker build arguments is not a good solutions, since we would need to rebuild the image on every new release without being able to rely on makeplane dockerhub images :/

[pablohashescobar]

Hi,

We're made some significant updates to the self hosting setup. We have moved all dynamic configuration variables to the backend, addressing the limitation in the frontend where environment values cannot be changed post-build without rebuilding the images. Now, Plane directly sources all necessary environment variables from the backend. It's important to note that NEXT_PUBLIC_API_BASE_URL has been deprecated. You can still use this variable, but be aware that it requires rebuilding the frontend image for changes to take effect.

Additionally, we're revamping our entire Docker setup. This update includes introducing a local setup for more efficient local development and other quick enhancements. For a sneak peek at these changes you can check the develop branch.

Stay tuned for more updates!

[jordibeen]

Hi @pablohashescobar, thanks for your comment.

Does that mean that, going forward, we'll always be limited to having the Frontend and API running on the same URL when using these official pre-built plane images from Docker Hub?

If that is indeed the intended behaviour it seems to be a 'feature' instead of a 'bug', and I'll close this issue.

[pablohashescobar]

Hi @jordibeen, the removal of NEXT_PUBLIC_API_BASE_URL has not been finalised yet the application still supports it if provided. We will keep the community posted when we will be completely removing the variable.

[leikoilja]

@pablohashescobar, i hope you guys are considering that no matter how the configuration variables are loaded into frontend container - there should be a way to host backend on a separate subdomain from the frontend, therefore there should be a way to direct the frontend where to look for the backend service, without implicit assumption that it will be on the same domain 🤔

[pablohashescobar]

Got it @leikoilja we will keep this in mind currently the application still supports the environment variable only you need to rebuild the containers once.

[leikoilja]

Got it @leikoilja we will keep this in mind currently the application still supports the environment variable only you need to rebuild the containers once.

makes total sense that one would need to rebuild the container when setting/changing env variables. As long as it's documented - don't think there is any problem with that. Just please dont deprecate or take away that functionality 😅