[GH-ISSUE #818] [Feature Request] Use single domain for frontend #514

New issue

Closed

opened 2026-03-02 02:16:57 +03:00 by kerem · 2 comments

kerem commented

2026-03-02 02:16:57 +03:00

Owner

Originally created by @NiceGuyIT on GitHub (Nov 22, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/818

Is your feature request related to a problem? Please describe.
A common problem on Discord stems from the the frontend using the API domain and trying to proxy the API domain. This results in CORS errors, NATS issues among other problems.

Describe the solution you'd like
Use a single domain for the frontend, rmm.example.com, and proxy all API calls to the appropriate backend in nginx.

Describe alternatives you've considered
I have done this for my install.

Additional context
This issue is to gather feedback before working on the PR. I can submit the PR if approved.

This will solve the following issues.

CORS errors stemming from improperly configured proxies for the rmm and API domains.
NATS and agent offline errors stemming from improperly configured proxies for the API domain.

This will allow the following.

The entire frontend can be proxied through Cloudflare or other reverse proxies easily.
Ease the support burden of troubleshooting reverse proxy issues.

The following changes are proposed.

Change the nginx config to route the API calls to the Django uWSGI service.
Change the nginx config to route the websocket to the Django channels daemon.
Change web/.env to the rmm.example.com domain for the frontend.
Change the deployment URL to use the API domain. I haven't figured out if the instructions are generated on the frontend or backend.
Update the install.sh and upgrade.sh scripts accordingly.

Breaking changes.

The update script is probably going to be a breaking change if the nginx changes cannot be scripted. This will need to be communicated.

Notes.

The API domain is not going to change and this will not affect agents connecting to the API domain.
Since the frontend API calls are not grouped under a single path (i.e. /api/), there will be a little extra maintenance burden going forward keeping the nginx config synced with the API calls/paths. I don't know if this can be scripted.

Thoughts? Did I miss anything?

Originally created by @NiceGuyIT on GitHub (Nov 22, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/818 **Is your feature request related to a problem? Please describe.** A common problem on Discord stems from the the frontend using the API domain and trying to proxy the API domain. This results in CORS errors, NATS issues among other problems. **Describe the solution you'd like** Use a single domain for the frontend, `rmm.example.com`, and proxy all API calls to the appropriate backend in nginx. **Describe alternatives you've considered** I have done this for my install. **Additional context** This issue is to gather feedback before working on the PR. I can submit the PR if approved. **This will solve the following issues.** 1. CORS errors stemming from improperly configured proxies for the rmm and API domains. 2. NATS and agent offline errors stemming from improperly configured proxies for the API domain. **This will allow the following.** 1. The entire frontend can be proxied through Cloudflare or other reverse proxies easily. 2. Ease the support burden of troubleshooting reverse proxy issues. **The following changes are proposed.** 1. Change the `nginx` config to route the API calls to the Django uWSGI service. 2. Change the `nginx` config to route the websocket to the Django channels daemon. 3. Change `web/.env` to the `rmm.example.com` domain for the frontend. 4. Change the deployment URL to use the API domain. I haven't figured out if the instructions are generated on the frontend or backend. 5. Update the `install.sh` and `upgrade.sh` scripts accordingly. **Breaking changes.** 1. The update script is probably going to be a breaking change if the nginx changes cannot be scripted. This will need to be communicated. **Notes.** 1. The API domain is not going to change and this will not affect agents connecting to the API domain. 2. Since the frontend API calls are not grouped under a single path (i.e. `/api/`), there will be a little extra maintenance burden going forward keeping the nginx config synced with the API calls/paths. I don't know if this can be scripted. Thoughts? Did I miss anything?

kerem

2026-03-02 02:16:57 +03:00

closed this issue
added the
dev-triage
label

kerem commented

2026-03-02 02:16:57 +03:00

Author

Owner

@wh1te909 commented on GitHub (Nov 23, 2021):

Very early versions of trmm actually were setup this way with a single domain and just proxying everything through nginx. I decided to separate them though to allow more flexibility for deployment, like with separate subdomains you can deploy your frontend to a different server or preferably a CDN since it's just a few static files. I'll let the community discuss this one we can see what people prefer and the pros and cons of each.

@wh1te909 commented on GitHub (Nov 23, 2021): Very early versions of trmm actually were setup this way with a single domain and just proxying everything through nginx. I decided to separate them though to allow more flexibility for deployment, like with separate subdomains you can deploy your frontend to a different server or preferably a CDN since it's just a few static files. I'll let the community discuss this one we can see what people prefer and the pros and cons of each.

kerem commented

2026-03-02 02:16:58 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Dec 1, 2021):

Moving this to a discussion about configuration organization and improvements. I believe with enough configuration options available, a single domain frontend can be optionally configured.

@NiceGuyIT commented on GitHub (Dec 1, 2021): Moving this to a discussion about [configuration organization and improvements](../discussions/836). I believe with enough configuration options available, a single domain frontend can be optionally configured.

kerem referenced this issue

2026-03-14 03:19:27 +03:00

[GH-ISSUE #514] BUG: Tasks not passing value properly #2266

kerem referenced this issue

2026-03-14 03:30:40 +03:00

[GH-ISSUE #568] BUG: Checks not passing value properly #2305