Recently, Gabor ran a poll in a Perl Facebook community asking which version of Perl people used in their production systems. The results were eye-opening—and not in a good way. A surprisingly large number of developers replied with something along the lines of “whatever version is included with my OS.”

If that’s you, this post is for you. I don’t say that to shame or scold—many of us started out this way. But if you’re serious about writing and running Perl in 2025, it’s time to stop relying on the system Perl.

Let’s unpack why.

---

What is “System Perl”?

When we talk about the system Perl, we mean the version of Perl that comes pre-installed with your operating system—be it a Linux distro like Debian or CentOS, or even macOS. This is the version used by the OS itself for various internal tasks and scripts. It’s typically located in /usr/bin/perl and tied closely to system packages.

It’s tempting to just use what’s already there. But that decision brings a lot of hidden baggage—and some very real risks.

Which versions of Perl are officially supported?

The Perl Core Support Policy states that only the two most recent stable release series of Perl are supported by the Perl development team [Update: fixed text in previous sentence]. As of mid-2025, that means:

• Perl 5.40 (released May 2024)

• Perl 5.38 (released July 2023)

If you’re using anything older—like 5.36, 5.32, or 5.16—you’re outside the officially supported window. That means no guaranteed bug fixes, security patches, or compatibility updates from core CPAN tools like ExtUtils::MakeMaker, Module::Build, or Test::More.

Using an old system Perl often means you’re several versions behind, and no one upstream is responsible for keeping that working anymore.

---

Why using System Perl is a problem

1. It’s often outdated

System Perl is frozen in time—usually the version that was current when the OS release cycle began. Depending on your distro, that could mean Perl 5.10, 5.16, or 5.26—versions that are years behind the latest stable Perl (currently 5.40).

This means you’re missing out on:

• New language features (builtin, class/method/field, signatures, try/catch)

• Performance improvements

• Bug fixes

• Critical security patches

• Support: anything older than Perl 5.38 is no longer officially maintained by the core Perl team

If you’ve ever looked at modern Perl documentation and found your code mysteriously breaking, chances are your system Perl is too old.

2. It’s not yours to mess with

System Perl isn’t just a convenience—it’s a dependency. Your operating system relies on it for package management, system maintenance tasks, and assorted glue scripts. If you install or upgrade CPAN modules into the system Perl (especially with cpan or cpanm as root), you run the risk of breaking something your OS depends on.

It’s a kind of dependency hell that’s completely avoidable—if you stop using system Perl.

3. It’s a barrier to portability and reproducibility

When you use system Perl, your environment is essentially defined by your distro. That’s fine until you want to:

• Move your application to another system

• Run CI tests on a different platform

• Upgrade your OS

• Onboard a new developer

You lose the ability to create predictable, portable environments. That’s not a luxury—it’s a requirement for sane development in modern software teams.

---

What you should be doing instead

1. Use perlbrew or plenv

These tools let you install multiple versions of Perl in your home directory and switch between them easily. Want to test your code on Perl 5.32 and 5.40? perlbrew makes it a breeze.

You get:

• A clean separation from system Perl

• The freedom to upgrade or downgrade at will

• Zero risk of breaking your OS

It takes minutes to set up and pays for itself tenfold in flexibility.

2. Use local::lib or Carton

Managing CPAN dependencies globally is a recipe for pain. Instead, use:

• local::lib: keeps modules in your home directory.

• Carton: locks your CPAN dependencies (like npm or pip) so deployments are repeatable.

Your production system should run with exactly the same modules and versions as your dev environment. Carton helps you achieve that.

3. Consider Docker

If you’re building larger apps or APIs, containerising your Perl environment ensures true consistency across dev, test, and production. You can even start from a system Perl inside the container—as long as it’s isolated and under your control.

You never want to be the person debugging a bug that only happens on production, because prod is using the distro’s ancient Perl and no one can remember which CPAN modules got installed by hand.

---

The benefits of managing your own Perl

Once you step away from the system Perl, you gain:

• Access to the full language. Use the latest features without backports or compatibility hacks.

• Freedom from fear. Install CPAN modules freely without the risk of breaking your OS.

• Portability. Move projects between machines or teams with minimal friction.

• Better testing. Easily test your code across multiple Perl versions.

• Security. Stay up to date with patches and fixes on your schedule, not the distro’s.

• Modern practices. Align your Perl workflow with the kinds of practices standard in other languages (think virtualenv, rbenv, nvm, etc.).

---

“But it just works…”

I know the argument. You’ve got a handful of scripts, or maybe a cron job or two, and they seem fine. Why bother with all this?

Because “it just works” only holds true until:

• You upgrade your OS and Perl changes under you.

• A script stops working and you don’t know why.

• You want to install a module and suddenly apt is yelling at you about conflicts.

• You realise the module you need requires Perl 5.34, but your system has 5.16.

Don’t wait for it to break. Get ahead of it.

---

The first step

You don’t have to refactor your entire setup overnight. But you can do this:

• Install perlbrew and try it out.

• Start a new project with Carton to lock dependencies.

• Choose a current version of Perl and commit to using it moving forward.

Once you’ve seen how smooth things can be with a clean, controlled Perl environment, you won’t want to go back.

---

TL;DR

Your system Perl is for your operating system—not for your apps. Treat it as off-limits. Modern Perl deserves modern tools, and so do you.

Take the first step. Your future self (and probably your ops team) will thank you.