# imdl creates and verifies BitTorrent metainfo without a GUI

> Intermodal ships imdl, a Rust command line tool for creating, viewing and verifying .torrent files on Linux, macOS and Windows, with a book of examples, distribution through six package managers and a single distroless container image. It is still on a 0.1.x version line.

**casey/intermodal** — command-line utility for BitTorrent torrent file creation, verification, and more

- Repository: https://github.com/casey/intermodal
- Website: https://imdl.io
- Stars: 661 · Forks: 36
- Language: Rust
- License: CC0-1.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/casey-intermodal

## A metainfo tool, not a BitTorrent client

Intermodal is described as a user friendly and featureful command line BitTorrent metainfo utility, and the binary is called imdl. The scope is narrower than a client, and the README is explicit about it: at the moment, creation, viewing and verification of .torrent files is supported. There is no downloader, no seeder, no tracker management and no magnet link handling in the described feature set. What that means in practice is that imdl is the tool you reach for when you need to build a metainfo file from a directory, inspect what is inside one, or confirm that a file you were given matches the contents it claims. The project also has a written explanation of its goals on the author's blog, and a book hosted at imdl.io with examples and usage information, which is where the README sends you for anything beyond the short summary. The tagline in the manifest description calls it a 40 foot shipping container for the internet, which is a joke about torrents, and it is the only place the project uses that tone.

## Six package managers and a shell install script

Distribution is unusually thorough for a small Rust utility. The package table lists Cargo for various platforms, two AUR packages for Arch Linux under Yay, Homebrew for macOS, XBPS for Void Linux and Scoop for Windows, alongside pre-built binaries on the releases page. Cargo is the simplest route, since imdl is a crate and cargo install imdl handles it, and the README points at rustup for getting Rust itself. There is also a shell script that downloads the latest binary for Linux and macOS, where DEST is replaced with the directory you want.

```sh
curl --proto '=https' --tlsv1.2 -sSf https://imdl.io/install.sh | bash -s -- --to DEST
```

If you leave the destination out, the script uses a bin directory in your home directory, and you then have to put that directory on your PATH yourself. For the common shells the README shows the export line to append to your profile file.

```sh
echo 'export PATH=$HOME/bin:$PATH' >> ~/.profile
```

Fish is handled separately through its own configuration file, with a different syntax for the same idea. Shell completion scripts for Bash, Zsh, Fish, PowerShell and Elvish ship with every binary release, and the README gives the destination for each shell, which is a small sign that the author expects people to run this tool constantly rather than once.

## The dependency list explains what the tool does under the hood

The Cargo manifest reads like a description of the tool's internals. A CLI argument layer is provided by structopt with wrap_help, with snafu for error handling and strum for deriving traits on the command enumeration, and log with pretty_env_logger for the logging setup. The filesystem work is done with globset for pattern matching, ignore for walking directories, and tempfile for scratch files. Hashing is where a torrent tool earns its keep: sha1_smol and md5 provide the digests, hex formats them, and serde with serde_json and serde_bytes handles the metainfo serialisation, with bendy, lexiclean and percent-encoding dealing with the encoding of torrent names. url is present because a metainfo file can carry an announce URL. Two dependencies tell you about the user experience: indicatif, vendored under the name imdl-indicatif, provides the progress bars, and rayon is the parallelism library, which is how hashing and verification of many files are spread across cores. It is a well chosen dependency set for one binary that has to do exactly three things.

## A justfile holds the developer workflow, including a torrent statistics recipe

Development is driven from a justfile rather than a Makefile, and the recipes are a good map of the project's habits. The default recipe watches the filesystem and reruns the tests, and the check recipe runs the test, clippy, forbid, check-minimal-versions and gen steps and then asserts that the working tree has no diff.

```sh
cargo fmt -- --check
cargo test --all
cargo clippy --all-targets --all-features
```

The forbid step runs a script from the bin directory, the minimal version check runs another script from the same place, and the gen step regenerates documentation by running a helper package that invokes the imdl binary itself. Two recipes are aimed at the author rather than at contributors. The publish recipe clones the repository at depth one into a temporary directory, builds it, regenerates the documentation and then reads the version out of Cargo.toml with a sed expression. The stats recipe builds a release binary and runs the unstable statistics command against a path, which is a neat piece of dogfooding: the tool is used to inspect the torrents in the project directory.

## The container image is a distroless binary with no shell

The Dockerfile in the repository is short, and the second stage is the interesting one.

```dockerfile
FROM docker.io/library/rust:1.78.0-bookworm AS builder
WORKDIR /usr/local/src
COPY . .
RUN cargo build --release
FROM gcr.io/distroless/cc-debian12:nonroot
COPY --from=builder /usr/local/src/target/release/imdl /usr/local/bin/imdl
ENTRYPOINT ["/usr/local/bin/imdl"]
```

The runtime stage is a distroless image with no package manager and no shell, running as the nonroot user, so the container contains the compiled binary and essentially nothing else. For a utility whose only job is to read and write files, that is the right shape, with the caveat that there is no shell to run a diagnostic command inside the container. One inconsistency is worth flagging: the builder stage pins Rust 1.78.0 while the workspace manifest declares a rust-version of 1.89.0, so a source build in that image may not satisfy the toolchain requirement the manifest states. That is the kind of drift that shows up as a build failure in a container rather than on a workstation, and it is worth checking before you put the image into a pipeline.

## The book, the benchmarks and the unstable surface

The documentation strategy is worth noting because it shapes how you will use the tool. Rather than a man page and nothing else, the project maintains a book, built with mdbook from a directory in the tree and served from the www output, and the justfile has recipes to serve it locally and to install the tooling needed for that, including mdbook, cargo-watch, a grip-based README preview and an asciicast to gif converter. The book is where the commands and examples live, and the README links to it rather than duplicating it. Alongside the book there is a benches directory, so the project measures something, and a tmp directory that the publish recipe uses as a scratch area. The unstable surface is explicit in the tooling as well, since the statistics recipe calls an unstable subcommand with an unstable flag, and the README has a section on unstable features as well as one on semantic versioning. For a 0.1.x tool that is the right way to signal which parts will move, and it is a reason to read the book for the version you actually installed rather than to copy command lines from a blog post.

## A young version line, an active repository and a public domain licence

Project status is straightforward. The last push was on 2026-08-20, the repository is not archived, and the release list shows v0.1.16 from 2026-03-19, v0.1.15 from 2025-11-08 and v0.1.14 from 2024-09-04. A 0.1.x version line means the command and output formats can still change between releases, which is a real consideration if you are parsing imdl output in a script. The licence is CC0-1.0, the public domain dedication, which is a deliberate and unusually permissive choice for a software project and removes the obligations that come with attribution, though it is worth confirming how you want to treat that for your own release. The author is credited in the manifest as Casey Rodarmor, the same name attached to the blog post explaining the project goals, and the tree carries a CHANGELOG, a CONTRIBUTING file, a rustfmt configuration, a book directory, the www output directory and a Dockerfile, which is the shape of a project that expects to be read and built by other people.

## Conclusion

imdl is the right tool for anyone who scripts torrent creation, wants to check a metainfo file without launching a desktop client, or needs the same behaviour on a Linux server and on a laptop, since the binary is the whole interface and it runs identically on three operating systems. It is the wrong choice for a person who wants a graphical client with a seeding queue, and the wrong choice for a project that needs a stable 1.0 API, because the version line sits at 0.1.16 and the README is explicit that some functionality is behind an unstable flag. Verify three things before you depend on it: which commands are marked unstable in the book for your version, since that surface is expected to change, whether the container image's Rust version matches what the source needs, because the Dockerfile pins 1.78.0 while the workspace asks for 1.89.0, and that the licence position suits you, since the project is released under CC0-1.0. The last push was on 2026-08-20 and the newest tag is v0.1.16 from 2026-03-19.

## FAQ

### What can imdl actually do?

The README states that creation, viewing and verification of .torrent files is supported. It is a metainfo utility rather than a BitTorrent client, with no downloading, seeding or tracker management described in the feature set.

### How do I install imdl on Linux, macOS or Windows?

Pre-built binaries are on the releases page, and the project lists packages for Cargo, Homebrew, Scoop, XBPS and two AUR options. On Linux and macOS there is also an install script that downloads the latest binary to a directory you choose, with a bin directory in your home used by default.

### Does imdl work on a headless server?

The binary itself is a command line tool with no interface dependency, and the project publishes a Dockerfile that builds it and copies it into a distroless Debian image running as the nonroot user, which is a natural fit for scripting on a server.

### Which parts of imdl are unstable?

The README has a section on unstable features alongside one on semantic versioning, and the project tooling calls an unstable torrent statistics subcommand with an unstable flag. The documentation lives in the book hosted at imdl.io, which is where version specific behaviour is described.

## Sources

- [casey/intermodal on GitHub](https://github.com/casey/intermodal)
- [License: CC0-1.0](https://github.com/casey/intermodal/blob/master/LICENSE)
- [Project website](https://imdl.io)
- [README](https://github.com/casey/intermodal/blob/master/README.md)
- [Releases](https://github.com/casey/intermodal/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/casey-intermodal