Basic Dockerfile and Compose Setup as a Starting Point

[moutasem1989]

After some experimentation, I finally managed to build an image that stays running instead of crashing on startup. I used ubuntu:24.04 as the base image — definitely heavier than ideal, but it worked reliably — and set rethink-cloud.js as the image entry point. I'm still not entirely sure which files need to persist, but for now I’ve mounted only the configuration file /rethink/config.json into the container. With that in place, the output behaves exactly as described in the wiki:

root@homeserver:/services/rethink# docker compose logs -f rethink rethink | Rethink cloud ready
rethink | During setup, please ensure that connections to common.lgthinq.com:443 are redirected to lgthinq.mydomain.tld:443
rethink | HA mqtt connection established

In my case i created a DNS Record for both common.lgthinq.com and lgthinq.mydomain.tld pointing to my server with NginX. There I redirected one domain to the other. Is it posible in this case to simply use port 443 and let NginX handle the certificates ?

I have not yet tried it with my ThinQ machine because I do not have a wifi enabled device where i can run rethink-setup.js So the image is not yet tested.
This byfar not a production ready solution but it is just a start to get things working

[moutasem1989]

I created a complete Docker deployment setup for your Rethink project by writing a Dockerfile, an entrypoint script that dynamically generates config.json from environment variables, and a docker-compose.yml exposing all required ports and settings.
This is ready to be merged

[moutasem1989]

I’ve been testing different configurations to see what works reliably with the Docker image, and here’s what I found:

The connection fails when changing the certificate locations. For example:
RETHINK_CA_KEY_FILE: "/cert/ca.key" does not work — it must be "ca.key"
RETHINK_CA_CERT_FILE: "/cert/ca.cert" also fails — it must be "ca.cert"

Because of that, creating a dedicated cert directory and mounting it like this - ./cert:/cert will not work. Instead, each file must be mounted individually, like this:

- ./ca.key:/rethink/ca.key:ro
- ./ca.cert:/rethink/ca.cert:ro

If port 443 is already in use, I found it much easier to offload everything to a reverse proxy. Trying to forward 443 → 4433 caused issues. I’m using Nginx Proxy Manager, and I had to add the certificate files there so NPM could handle TLS termination properly. Moreover even when changing the value of https_port to 443, container still reachable from port 4433. But since NPM has the certificates, and proxy requests from https://common.lgthinq.com to https://rethink-container:4433, I did not have issues with it.
My router supports DNS records. Using a CNAME caused connection problems, but an A record was completely reliable.
To test all of this, I had to constantly switch between a dedicated machine and my Docker host.
But so far, judging from the container logs, this setup is working.

[anszom]

Thank you for this work. I'll try to review it soon - hopefully :) The use-case with the reverse proxy was not what I've had in mind - but it's certainly reasonable. I'll try to find a good way to support this scenario.

[moutasem1989]

I’ve made major improvements, and I can say it’s now ready for testing:

I created a Dockerfile that installs the project into a node Docker image and sets up the entrypoint correctly.
The entrypoint generates the configuration file based on environment variables and links the files from /config into the working directory /rethink inside the container (including bridge files and certificates - it rewrites what ever is there).

Depending on the RETHINK_SERVER_MODE, it then starts either the cloud or bridge services (with cloud).
The cloud runs as its own service, while the bridge service is launched by a script that monitors the cloud service logs. For every new device that connects (new device ID), it spins up a dedicated bridge service instance and ensures there are no duplicates. it collects all the needed informations accordingly.

I think the only inconvenience is provisioning new devices in the cloud/bridge services. Additionally, we might need a way to automatically copy the .bridge-{device-id}.json files—once they’re created in /rethink—into /config so they persist between container reboots.

The certificate generated by the cloud service is copied into /config, but it’s not overwritten; if the domain changes or certificate value changes, it must be removed manually.

I hope this helps. It was a great learning experience for me to build all of this.

[anszom]

Thanks again. I didn't have time to review this yet - so far I've been focusing on adding support for new devices, docker integration is more of a "nice to have" feature for me.

I've had a bit of a different approach in mind with the bridge service. The standalone "bridge" tool was meant as an experiment. Ideally, the main rethink-cloud server would have an option to operate as a bridge, this could be configured via a simple web interface.

[moutasem1989]

Perfectly understandable. It is just meant for ease of use. I usually test such projects in VMs or Containers and I just wanted to share in case others wanted to test it as well