Rex is a Perl automation framework that refuses to pick a model for you

Three ideas, and the first one is a refusal

The readme opens with the main ideas behind Rex, and the first of them is that it puts you in charge. Rex acknowledges that instead of silver bullets, there is more than one way to manage it, and it is friendly to any combination of local and remote execution, push and pull style of management, or imperative and declarative approach. Instead of forcing any specific model on you, it trusts you to be in the best position to decide what to automate and how, allowing you to build the automation tool your situation requires. That is a genuine design position rather than a marketing line, and it is unusual. Most infrastructure automation tools have a model, and the ones that do not are usually hobby projects that lack the plumbing. Rex's claim is that the plumbing exists and the model is yours to choose.

It runs locally, which is what makes it easy to start

The second idea is easy to get on board. Automate what you are doing today and add more tomorrow. Rex runs locally, even when managing remotes over SSH. The readme is explicit about why this matters: it means it is instantly usable, without big rollout processes or anyone else to convince, which makes it ideal and friendly for incremental automation. That is the practical argument for the framework, and it is stronger than it first appears. A tool that only works after a central server, a policy document and a fleet-wide rollout is a tool you cannot use on the one server that is misbehaving at 4pm on a Friday. A tool that runs on your laptop and pushes work over SSH can be used on exactly that server. The topics the repository carries line up with this positioning, with automation, configuration-management, devops, infrastructure-as-code and infrastructure-automation all listed.

It is Perl, and that is an argument rather than an apology

The third idea is that it is just Perl. The readme's reasoning is that Perl is a battle-tested, mature language, and Rex code is just Perl code. The consequence offered is that whenever you reach the limitations of the built-in Rex features, a powerful programming language and module ecosystem is always at your fingertips, to extend it with modules from CPAN or with your own code. The bonus offered is that you can use the usual well-established tools and workflows, like IDE integration for syntax highlighting, linting and formatting, or authoring and publishing Rex modules on CPAN. And then there is the escape hatch that makes the argument complete: with the Inline and FFI::Platypus modules, it is friendly to code written in other languages too, so after all, it is not just Perl. The repository layout backs the tooling claim, with a .perlcriticrc and a .perltidyrc for linting and formatting, a ChangeLog, a MANIFEST.SKIP, a dist.ini for the Dist::Zilla build, a t/ directory for tests and an xt/ directory, plus bin/, lib/, doc/, misc/ and share/ directories.

Installing it from source is a Dist::Zilla workflow

There are several methods to install Rex, and the readme names three. Use your distribution's package manager, download it from CPAN, or build it from source. The Get Rex page on the website lists the options in detail. The source route starts with installing Dist::Zilla, which provides the dzil command.

    cpanm Dist::Zilla

Dist::Zilla then resolves the dependencies, with the author dependencies and the listed dependencies installed separately.

    dzil authordeps | cpanm
    dzil listdeps | cpanm

Some of the optional dependencies might not be available on all platforms, and there is a separate command for those.

    dzil listdeps --suggests | cpanm

Then the operating system specific dependencies and Rex itself are installed.

    dzil install

And if you want the release tarball rather than an installed copy, there is a build command.

    dzil build

That last step matters for the packaging story, because a .tar.gz release file built this way is what a distribution packager would consume, which is why the distribution's package manager route exists at all.

Documentation, support and the shape of the project

Getting started is a website guide rather than a repository file, and the readme points at a getting started guide on the site for the first steps. Help is handled in a particular way that says something about the project's values. If a new user has difficulties to get on board, then it is a bug, and the ask is to let the project know through one of the support channels. That is a stronger commitment than a typical documentation page, and it reframes onboarding as a defect rather than as a user problem. The contributing section widens the door further, listing documentation, patches, bug reports, ideas, promoting Rex at conferences and meetups, or anything else, with a contributing guide in the repository and a Help Rex page on the website. The project has a homepage at rexify.org, a primary language of Perl, and no GitHub releases, so the distribution channels are the website, CPAN and the distro packages rather than versioned artefacts in the repository.

Where this is the wrong choice

Three limits are worth naming. The first is the deliberate one, and it is a real cost. If your organisation has decided that infrastructure should be described declaratively and enforced from a single source of truth, Rex will not give you that, because it declines to impose the model. The price of that flexibility is that the consistency a declarative tool provides has to be provided by your own conventions, and a team that values that property above all others will be frustrated. The second is the language. Perl is battle-tested and mature, but a team that has standardised on Python, Go or Rust will find that the surrounding ecosystem, the hiring pool and the tooling all push the other way, and the Inline and FFI::Platypus escape hatches help at the edges rather than in the middle. The third is the release story, since the repository publishes no GitHub releases and the visible activity is the last push on 2026-06-27, which for a framework means you have to judge the project by its documentation and by the fact that it is still being worked on rather than by a release cadence.

Editorial conclusion

Rex suits a systems administrator who wants to automate one thing this afternoon rather than adopt a platform, and it suits a team with a large Perl codebase that a Python or Ruby rewrite would strand. It is the wrong tool if you want a declarative state model enforced on every run, because that is exactly the model Rex declines to impose. It is also the wrong choice if you need the tooling ecosystem that comes with a newer language. Before adopting it, read the getting started guide and pick the one task you would like to automate, since the project says incremental automation is the intended entry point, and note that the repository publishes no tagged releases, so the last push on 2026-06-27 is your only health signal. The last push was on 2026-06-27 and the project is distributed through the website, CPAN and the distro package managers.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. RexOps/Rex on GitHub