xplr: A Lua-Scriptable TUI File Explorer That Delegates Instead of Replacing
A hackable, minimal, fast TUI file explorer
At a glance
- What is it?
- xplr is an MIT-licensed Rust file explorer for the terminal whose main design bet is that the file manager should be a scriptable orchestrator over existing CLI tools rather than a self-contained application. The README is explicit that it does not aim to replace shell commands or GUI file managers.
- Who is it for?
- Adopt xplr if you already live in a terminal, want file navigation to be a scriptable surface, and are willing to write configuration rather than accept defaults. Do not adopt it if you want a file manager that works well out of the box, or if you need a stable configuration API across releases: the jump from v1.0.1 to v1.1.0 to v1.1.1 in roughly thirteen months suggests the surface is still moving.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem xplr targets: file navigation as a scriptable surface
Most terminal file managers make an implicit promise: install, open, and you get a working browser with sensible keys. xplr inverts that. Its README states the project aims to be a flexible, interactive orchestrator for command-line utilities that work with the file system, and it explicitly says xplr is not meant to be a replacement for standard shell commands or GUI file managers. That framing matters because it defines the audience. If your file workflow already consists of tools like fzf, ripgrep, bat or a preview renderer wired together with shell aliases, xplr is a candidate for the missing visual layer. If you want a file manager that is complete on first launch, xplr is not competing for that slot and its own documentation says so.
The topics list on the repository names vim among its tags, and the linked documentation covers key bindings and layouts as first-class configuration areas. That is the shape of the project: navigation state is exposed, and the user decides what keys do and what the screen looks like. The cost of that flexibility is that the initial experience depends on how much configuration you bring.
How xplr works: a Rust core with Lua configuration and external tool integration
The implementation language is Rust, and the binary is distributed through crates.io as the crate xplr, with the README pointing package maintainers at a RELEASE.md file in the repository. The README also links to pages for layouts, key bindings, plugins and integrations on xplr.dev, which is the pattern that separates xplr from a monolithic file manager: the explorer handles traversal and rendering, and the documentation directs users toward plugins and integrations for behaviour that other projects would build in.
The README does not describe the internal architecture in the truncated material available here, so I cannot state how the message loop, the directory watcher or the Lua binding layer are implemented. What can be confirmed is the direction of the data flow implied by the documentation structure: the explorer produces a selection and a directory context, and configured scripts and plugins consume it. The repository topics include file-launcher and launcher alongside file-manager, which is consistent with the README's claim that xplr is an ideal candidate for further integration. Treat the plugin and integration pages as the authoritative description of the extension mechanism rather than the README, which is a landing page with links.
Installing xplr and where the configuration actually lives
The README's install link points to xplr.dev/en/install, and the repository carries a Repology badge that tracks which distributions and package repositories ship a given version. The practical route for most users is a distribution package or the crate on crates.io; the README does not enumerate cargo install or platform-specific commands in the text available here, so check the install page before assuming a method. The RELEASE.md file in the repository is addressed to package maintainers, which tells you the project expects downstream packaging to be the normal distribution channel.
Configuration is the part that decides whether xplr suits you. The README links to xplr.dev/en/configure-key-bindings and xplr.dev/en/layouts, and the project describes itself as keyboard controlled and scriptable. The extension points documented at xplr.dev/en/awesome-plugins and xplr.dev/en/awesome-integrations are where behaviour such as previewing, launching and integration with other tools is expected to be assembled. Because the README is a link hub rather than a reference, the specific config keys and file paths are on those documentation pages; I have not reproduced them here because the supplied material does not contain them. Anyone evaluating xplr should budget an hour on the key bindings and layouts pages before installing, since the default experience is deliberately thin.
The limitation: a thin default experience and a moving configuration surface
The same design choice that makes xplr flexible makes it a poor fit for someone who wants a finished product. A file explorer whose README points to separate pages for key bindings, layouts, plugins and integrations is telling you that those things are user-supplied. That is a real cost, not a philosophical one: on a fresh install you get the explorer, and the behaviour that other file managers ship as defaults has to be configured or installed as a plugin.
The release cadence is the second thing to weigh. v1.0.1 landed in July 2025, v1.1.0 in December 2025, and v1.1.1 in August 2026. That is a minor version bump inside a year, and the project is not archived, so development is active. Active development on a configuration-driven tool means your Lua configuration is a dependency you maintain alongside the binary. The README does not promise configuration stability across minor releases, and the supplied material contains no changelog, so treat an upgrade as something to test against your own config rather than assume. If you maintain a shared dotfiles repository across machines, that test is your problem to schedule, not the project's.
Alternatives and the difference in approach
The obvious comparison is a terminal file manager that ships opinionated defaults and a fixed keymap, where the feature set is defined by the upstream project and configuration is a matter of toggling options. The difference is not quality, it is where the decisions live. In the defaults-first model, the maintainer decides what a preview pane does and how a file is opened; in xplr's model, the README's own framing pushes those decisions to plugins and integrations. That means xplr can be shaped to a workflow that no upstream maintainer would have predicted, and it also means two xplr installs on two machines can behave completely differently.
A second comparison is the shell itself. The README states plainly that xplr is not a replacement for standard shell commands, so the honest alternative for some users is a set of aliases and a fuzzy finder rather than a TUI at all. xplr's argument against that is the real-time visual interface named in the README, which a pipeline of shell commands does not give you interactively. If you have never felt the absence of that interface, xplr is solving a problem you do not have.
Licence, packaging and what maintenance actually costs you
The licence is MIT, which is permissive and imposes no copyleft obligation on your own configuration or scripts. That matters for a tool you will embed in a personal workflow and possibly in a team's shared dotfiles: MIT lets you redistribute and modify without publishing changes. This is not legal advice; read the LICENSE file in the repository if the distinction between MIT and a copyleft licence affects how you intend to distribute anything derived from xplr.
Maintenance cost has two components. The first is the binary: because the project is packaged downstream and tracked on Repology, staying current may be as simple as your distribution's package manager, but packaged versions lag upstream, and the gap between a distribution build and v1.1.1 is something to check rather than assume. The second is your configuration, which lives in your dotfiles and is yours to keep working. The README's links to plugins and integrations imply that some of what you configure may live in third-party repositories with their own release cadence. Neither the README nor the release list tells you how many plugins exist or how actively they are maintained, so audit the specific plugin you depend on before building a workflow around it.
Who should adopt xplr
Adopt xplr if the idea of a file explorer as an orchestration layer matches how you already work, if you are comfortable writing configuration in Lua, and if you treat your dotfiles as a maintained artifact rather than a one-time setup. The README's claim that xplr is an ideal candidate for further integration is the whole pitch, and it is only true for users who intend to do that integration. The repository topics naming vim, raspberry-pi and wsl suggest the project is aimed at people running terminals in constrained or remote environments, where a TUI explorer that delegates to existing tools is more useful than one that bundles its own.
Skip xplr if you want a file manager that is complete after installation, if you are unwilling to maintain configuration across minor releases, or if you need a written guarantee about which plugin APIs will keep working. Before adopting, verify three things in order: that your distribution or crates.io gives you a build close to v1.1.1, that the key binding and layout documentation at xplr.dev describes behaviour you actually want rather than behaviour you would have to invent, and that the specific plugin or integration you plan to rely on is maintained. If the third check fails, xplr still works as a plain explorer, but you are paying the configuration cost without the payoff.
Editorial conclusion
Adopt xplr if you already live in a terminal, want file navigation to be a scriptable surface, and are willing to write configuration rather than accept defaults. Do not adopt it if you want a file manager that works well out of the box, or if you need a stable configuration API across releases: the jump from v1.0.1 to v1.1.0 to v1.1.1 in roughly thirteen months suggests the surface is still moving. Before committing, read the configure-key-bindings and layouts pages at xplr.dev, install a packaged build for your distribution, and confirm that the Lua configuration you write against v1.1.1 survives your next upgrade.
Community notes