DLX renamed its repository but kept the deeplx image and binary names

The rename changed the repository and nothing else

The readme has a section explaining that in July 2026 the project received a trademark notice forwarded by the platform's trust and safety team on behalf of the trademark holder, stating that the former name contained a registered trademark and might cause confusion about authorisation. It then says plainly that it never was authorised and renamed the repository to remove the branding. And then it says this:

Docker Hub and GHCR image names remain `deeplx` (only the GitHub repository was renamed to DLX)

Consequence: the string the notice objected to is still in the container images, the release artefact names, the built binary, the systemd unit, the launch agent and the compose service name. That is the correct engineering trade, because renaming published artefacts breaks every deployment at once, and it also means the objection survives in the places a user actually types. A guide written for the old name still works exactly as written.

The readme opens with an editor's metadata block

The first thing in the file is an HTML comment carrying an author handle, a creation date, a last-edited timestamp, the file's own path, a messaging contact, and a copyright line reading all rights reserved. The file then ends by granting a permissive licence with a link to it. Consequence: ten lines of scratch metadata from someone's editor survived both a rename and a licence decision, and the one line in the file that contradicts the licence is the one nobody would read twice.

The compose file ships with its authentication variables commented out

The compose file publishes one port, restarts always, pulls the image by a floating tag, and contains a commented block holding two variables:

      # - TOKEN=helloworld
      # - DL_SESSION=xxxxxx

Consequence: the documented compose path starts a server with no token, on a published port, forwarding requests to the upstream DeepL service. The variable names are visible, which tells you they exist and what they are called, and the fact that the block is commented rather than absent tells you they were considered and switched off. Anyone who exposes the port without reading the source is running an open proxy, and it will look healthy.

A fixed port and a floating tag in the same file

Port 1188 appears throughout the readme, in the compose file and in the Dockerfile, and it is the same number in all of them. The image, by contrast, is referenced by a moving tag in both the compose file and the run command the readme gives you. Consequence: the port is the most stable thing about the deployment and the code is the least, which is the wrong way round. A container that restarts after a reboot can come back running a different build with no change in your configuration file, and nothing in the repository offers a digest to pin.

A translation proxy links a fingerprinting library and two QUIC stacks

The direct dependency list is five entries and reads like a small web service. The indirect list is around forty, and among them are a library whose purpose is to make a client look like other TLS clients, a QUIC implementation (quic-go) with its QPACK library, an assembler library (golang-asm), and a binary codec. Consequence: the service's job is to take a request and forward it once, and the graph behind that is a general-purpose HTTP and serialisation stack. That is a normal consequence of building on a popular web framework, and it is also the part of this project a security review will spend its time on.

The container build uses a deprecated module command and an unpinned runtime

The builder stage downloads dependencies with the old module command that has been deprecated in favour of a different one, and the runtime stage is the latest Alpine image with no version. The builder is pinned to a specific Go release. Consequence: the deprecated form still works, so nothing breaks today, and the asymmetry is the wrong way round: the compiler is fixed and the operating system underneath the binary can move without you asking. The build also names its output for the previous project, which is what ties the packaging back to the rename.

The Activity heading has nothing under it

Near the bottom of the readme, between the acknowledgements and the licence, there is a heading for activity with no content beneath it. Consequence: in a file that otherwise goes out of its way to explain a trademark notice and a rename, an empty section reads like a release-notes block generated by a workflow that has not run since the rename. It is a small thing, and it is the kind of detail that makes a reader wonder what else on the page is generated rather than written.

The binary route gives you a file named for a project that no longer exists

The readme's binary instructions say to download an artefact for your platform from the releases page, that the artefact names still carry the old prefix, and then to run it:

./deeplx

Consequence: you end up with a file whose name matches the container image but not the repository. That is a real moment of doubt at the point where someone is checking they downloaded the right thing, and the answer is a paragraph of the readme rather than the file itself. The container route has the same property and at least hides it behind an image name.

Editorial conclusion

DLX fits a developer who wants a translation endpoint they host themselves, on a fixed port, with one command to start it and one to call it. It does not fit a deployment where the container's published port should be protected, because the compose file that the readme points you at has its authentication variables present and commented out. It also does not suit anyone who needs the naming to be consistent, since the repository is named DLX while the images, the artefacts and the service unit are still named deeplx. Before deploying it, decide whether you need a token and enable it in the compose file, pin the image by digest rather than by tag, and read the rename section before you assume the project is or is not the official product.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. OwO-Network/DLX on GitHub
4. README
5. Releases