[GH-ISSUE #2369] FR: Proper container support #3404

New issue

Open

opened 2026-03-14 07:16:48 +03:00 by kerem · 0 comments

kerem commented

2026-03-14 07:16:48 +03:00

Owner

Originally created by @samip5 on GitHub (Dec 9, 2025).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2369

Running TRMM on container orchestration platforms (Kubernetes, Swarm, Nomad, etc.) is pretty rough because the Docker setup assumes every container shares the same filesystem. In practice:

The init container drops a tactical.ready file in /opt/tactical/tmp/, and NATS won’t start until it sees it — but in K8s these are separate pods with separate filesystems.
create_natsapi_conf generates nats-rmm.conf and nats-api.conf under /opt/tactical/api/, but other containers need to read them and can’t.
The source lives under /opt/tactical, so you can’t mount a shared volume there without wiping out the app code.

I have it running, but only by adding an init container to the NATS pod that polls a PVC for the config files and then copies them into an emptyDir. It works, but it’s not pretty.

MeshCentral is running in the same cluster but as a separate deployment, mainly to avoid adding even more cross-container filesystem coordination.

Describe the solution you'd like

Allow more config via environment variables instead of generated files. For example, nats-api.conf is just JSON with DB creds and a key — that could be handled entirely with env vars.
For configs that really do need to be files, let the output path be configurable (env var) instead of hard-coding /opt/tactical/api/.
Replace the tactical.ready file check with something containers can coordinate on: an HTTP readiness probe, or simply removing the check if the init container is already a separate pod.

Describe alternatives you've considered

Running on a VM as recommended — works fine, just doesn’t fit the rest of our K8s-based infra.
Mounting all of /opt/tactical — not viable because the source code lives there.
SubPath mounts for each file that needs persistence — this is what I’m doing now, but it’s brittle.

Additional context

Happy to test or contribute patches. I can handle the Django side; the main blocker is the NATS container since its paths are fixed.

EDIT: I just spent 7 hours figuring this one out.

Originally created by @samip5 on GitHub (Dec 9, 2025). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2369 ## Is your feature request related to a problem? Please describe. Running TRMM on container orchestration platforms (Kubernetes, Swarm, Nomad, etc.) is pretty rough because the Docker setup assumes every container shares the same filesystem. In practice: - The init container drops a `tactical.ready` file in `/opt/tactical/tmp/`, and NATS won’t start until it sees it — but in K8s these are separate pods with separate filesystems. - `create_natsapi_conf` generates `nats-rmm.conf` and `nats-api.conf` under `/opt/tactical/api/`, but other containers need to read them and can’t. - The source lives under `/opt/tactical`, so you can’t mount a shared volume there without wiping out the app code. I have it running, but only by adding an init container to the NATS pod that polls a PVC for the config files and then copies them into an emptyDir. It works, but it’s not pretty. MeshCentral is running in the same cluster but as a separate deployment, mainly to avoid adding even more cross-container filesystem coordination. ## Describe the solution you'd like 1. Allow more config via environment variables instead of generated files. For example, `nats-api.conf` is just JSON with DB creds and a key — that could be handled entirely with env vars. 2. For configs that really do need to be files, let the output path be configurable (env var) instead of hard-coding `/opt/tactical/api/`. 3. Replace the `tactical.ready` file check with something containers can coordinate on: an HTTP readiness probe, or simply removing the check if the init container is already a separate pod. ## Describe alternatives you've considered - Running on a VM as recommended — works fine, just doesn’t fit the rest of our K8s-based infra. - Mounting all of `/opt/tactical` — not viable because the source code lives there. - SubPath mounts for each file that needs persistence — this is what I’m doing now, but it’s brittle. ## Additional context Happy to test or contribute patches. I can handle the Django side; the main blocker is the NATS container since its paths are fixed. EDIT: I just spent 7 hours figuring this one out.