New technologies, Perl Scripts ·
Running an Old Perl Application in a Container
By Manu Mathew, Technical Lead Engineer · Published 11 October 2026 · Last updated 11 October 2026
Your team has a Perl application that has run on the same server for years. The server is getting old, nobody wants to touch it, and someone suggests putting the application in a container.
It’s a sensible idea, but it helps to know what you’re signing up for. Running a Perl application in a container changes how it’s packaged and run. It doesn’t change the code, and it won’t fix problems the code already has.
Quick answer
A container packages a Perl application with the exact Perl version, modules and system libraries it needs, so it runs the same way on any server, while the code stays the same. What changes is everything around it: stored files, logs, scheduled jobs, email, settings and passwords. Plan for those first, and test old and new side by side.
What does running Perl in a container actually mean?
It means bundling the application and everything it depends on into one image, which then runs as an isolated process on a host server.
An image is a read-only package built from a short recipe file. A container is a running copy of that image. Docker’s guide to what a container is explains the idea well if you’re new to it.
For an old Perl application, the image usually holds:
- A fixed Perl version. The same one production uses today, not whatever a new server happens to ship with.
- The modules the code needs. At the versions that work now, written down rather than remembered.
- System libraries. Database client libraries, image tools or anything else the modules rely on.
- The application code. Copied in when the image is built.
Ready-made official Perl images on Docker Hub exist for many Perl versions, which saves building one from scratch.
What stays the same?
The Perl code itself stays the same, and that’s the main appeal. You don’t have to rewrite anything to start.
The application still talks to the same database, reads the same input and produces the same output. Its bugs and quirks come along too. If a script has no tests today, it has no tests inside a container either.
That’s why I treat containerising as a change to how the application is run, not a modernisation of the code. It can be a good first step before code changes, because it gives you a repeatable environment to test them in.
What changes when you run a Perl application in a container?
Mostly the things the application assumed about its server: where files live, where logs go, how jobs run and where settings come from.
| Area | On the old server | In a container |
|---|---|---|
| Uploaded and generated files | Written to a local folder | Lost on restart unless stored in a volume or elsewhere |
| Logs | Files under a log folder | Usually written to standard output and collected by the host |
| Scheduled jobs | The server’s crontab | A separate scheduled container or the platform’s scheduler |
| Settings and passwords | Hardcoded or in a config file | Passed in as environment variables or secrets |
| Outgoing email | A local mail program | Sent through a mail server or service |
| Time zone and locale | Set once on the server | Set in the image, or dates and sorting may change |
Where do uploaded and generated files go?
A container’s own file system is temporary. Anything the application writes, such as uploads, reports or caches, disappears when the container is replaced, unless it goes to a Docker volume or other storage.
Old Perl code often writes to fixed paths. Those paths need finding before the move, not after a restart.
What happens to logs and errors?
Containers usually expect logs on standard output and standard error, where the host can collect them. The twelve-factor guidance on logs describes this approach.
An application that writes to its own log files can keep doing so, but someone has to make sure those files are stored and rotated. Otherwise the first sign of trouble may be a full disk.
How do scheduled jobs run?
Many Perl systems are really a set of cron jobs. In a container setup, these usually run as separate short-lived containers on a schedule, rather than inside the web application’s container.
It’s worth listing every job, what time it runs and in which time zone. A job that ran at 2 AM local time can quietly shift if the container runs on UTC.
What about settings, passwords and email?
Database passwords and API keys shouldn’t be built into the image. They’re passed in when the container starts, which often means a small code change where values were hardcoded.
Email needs a check too. Scripts that called a local mail program will find nothing there, so they need a mail server to send through.
Is containerising worth it for an old Perl application?
Often yes, when the server is ageing or nobody can rebuild it with confidence. It’s less useful when the application is about to be retired.
It tends to help when:
- The current server can’t be rebuilt. Nobody knows exactly what’s installed or why.
- You need a test copy. The same image can run on a developer’s laptop, a test server and production.
- You plan to change the code later. A fixed environment makes before-and-after comparisons fair.
- You’re moving hosts or to the cloud. An image is easier to move than a hand-built server.
It’s probably not worth it when the application will be switched off soon, or when it depends heavily on the old machine in ways that are hard to separate, such as other programs writing into the same folders.
How do I approach a Perl container move with a client?
In small, reversible steps, with the old server kept running until the new setup has proved itself.
My usual order of work:
- Make an inventory. Perl version, modules and their versions, system packages, cron jobs, file paths, outgoing connections and email.
- Agree what “working” means. A short list of pages, reports and jobs we can compare between old and new.
- Build the image. Match production first; upgrade nothing yet.
- Run old and new side by side. Compare outputs, the way you would when testing legacy Perl code before changing it.
- Move the outside pieces. Volumes for files, log collection, schedules and secrets.
- Switch over with a way back. Keep the old server ready until the new setup has run cleanly for an agreed period.
At each step I write down what changed and what we decided not to change yet, so the team can review it. Containers and Kubernetes are a regular part of my day-to-day work, and that habit of small, checked steps comes from there.
Frequently asked questions
Do I need to upgrade Perl before putting the application in a container?
No, and it’s usually safer not to. Build the first image with the same Perl version production uses, so any difference you see comes from the container rather than the upgrade. Once the containerised application runs cleanly, you can upgrade Perl as a separate, tested step.
Can a CGI application run in a container?
Yes, a CGI application can run in a container alongside a web server configured to run it. That keeps the application working while you plan a move to a modern setup. It doesn’t remove the limits of CGI, but it gives you a stable, repeatable base for that later work.
Is a container the same as a virtual machine?
No. A virtual machine runs a whole operating system of its own, while a container shares the host’s operating system kernel and packages only the application and its dependencies. Containers usually start faster and use fewer resources, but they suit one main process each rather than a whole server’s worth of programs.
Will containerising make my Perl application faster?
Not by itself, because the same code does the same work, so speed is usually similar. Gains, where they appear, tend to come from a newer host server or from tuning done along the way, such as fixing slow database queries. Treat any speed change as something to measure, not assume.
Do I need Kubernetes to run a containerised Perl application?
No, a single server running containers is enough for many applications. Kubernetes and similar platforms help when you run many containers across several servers and need automatic restarts and scaling. For one ageing Perl application, start simple and add a platform only if a real need appears.
Need help with an old Perl system?
If you have Perl code that needs fixing, upgrading or moving to a new setup, I’m happy to take a look. The Perl development page covers the kinds of work I take on, and working remotely explains how I work with teams in other countries.
You can reach me through the contact section or email me at manu@manu.co.in. A few lines about the system and what you need is a good start.