Sandboxed, self-updating container for torlink
817
A containerized wrapper around torlink, the terminal torrent client.
Instead of installing Node and a global npm package on your machine, everything runs inside this container: the client, its WebTorrent engine, its state and its downloads. You attach to it from the outside, and it keeps itself up to date.
Source, issues and the torlink helper script: github.com/MCmoderSD/torlink-dockered
| Tag | Platforms |
|---|---|
latest | linux/amd64, linux/arm64 |
Also published on GHCR as ghcr.io/mcmodersd/torlink-dockered.
name: torlink-dockered
services:
torlink-dockered:
image: mcmodersd/torlink-dockered:latest
container_name: torlink-dockered
hostname: torlink-dockered
pull_policy: always
restart: on-failure
user: "1000:1000"
read_only: true
init: true
environment:
TERM: xterm-256color
TORLINK_VERSION: latest
volumes:
- downloads:/downloads
- config:/config
- app:/app
tmpfs:
- /tmp:mode=1777
networks:
- torlink-network
volumes:
downloads:
name: torlink-downloads
config:
name: torlink-config
app:
name: torlink-app
networks:
torlink-network:
name: torlink-network
docker compose up -d
Then attach to the client:
docker compose exec torlink-dockered screen -U -x torlink
Detach again with Ctrl-a then d — the container keeps seeding and downloading in the background. Torrents are added from inside the TUI.
The repository ships torlink.sh, a wrapper you can symlink to /usr/local/bin/torlink so that plain torlink starts the container if needed and attaches.
The container has no daemon. torlink's TUI process is the engine, so it has to stay alive:
torlnk from npm into the /app volume./config/config/config.json on first start, pointing the download directory at /downloads.torlnk inside a detached GNU screen session named torlink.Attaching with screen -U -x torlink joins that exact session, the one doing the work. torlnk attach is not used for this: upstream hardcodes it to tmux new-session -A -s torlink, and this image ships screen rather than tmux.
Session and attach both run in screen's forced UTF-8 mode, and the image sets LANG/LC_ALL to C.UTF-8. Without a UTF-8 locale a multiplexer downgrades the TUI's box-drawing and block glyphs to ASCII, which makes the interface look broken.
On every container start the entrypoint installs the version requested by TORLINK_VERSION. A restart is therefore an update:
docker compose restart
Pin a version by setting TORLINK_VERSION: 1.2.3. If npm is unreachable, the container warns and keeps using the copy in the /app volume; it only fails hard when no working copy exists.
torlink's own update check is permanently disabled in the image. torlnk update shells out to npm install -g torlnk@latest, which cannot succeed anywhere: the transitive dependency ip-set has a preinstall hook (npx only-allow pnpm) that refuses npm outright.
| Variable | Default | Meaning |
|---|---|---|
TORLINK_VERSION | latest | npm version range to install |
TERM | xterm-256color | terminal type for the TUI |
| Path | Contents |
|---|---|
/downloads | finished and in-progress torrents |
/config | config, torrent state, npm cache |
/app | the installed torlnk package |
torlnk stores the download directory in its config file, not in an environment variable, so a host folder has to be mounted at /downloads exactly:
volumes:
- /srv/torrents:/downloads
/tmp1000:1000, never as rootinit: true, so the reparented screen server gets reaped properlylinux/amd64 and linux/arm64 only. node-datachannel ships glibc prebuilds for these two; elsewhere the WebTorrent stack falls back to webrtc-polyfill and crashes on startup.utp-native, bufferutil and utf-8-validate have no prebuilds. torlink runs fine without them, just with slower µTP and WebSocket paths.node:slim), not Alpine, for the same prebuild reason.torlnk copy.BSD 3-Clause. See LICENSE.
torlink itself is a separate project — see baairon/torlink.
Content type
Image
Digest
sha256:acd2025d2…
Size
85.6 MB
Last updated
about 4 hours ago
docker pull mcmodersd/torlink-dockered