Although hosting companies won’t let you define your own Perl modules, you can simply define your own CPAN library-directory, install your local CPAN materials into it, and then employ the use lib statement to put that directory at the front of your search path.

See:   perldoc FindBin.

There are copious prior threads on “how to install Perl as a non-root user,” etc., which will show you how to configure CPAN locally so that, when you install and update libraries, they go into your local directory.

When I first signed-up with my hosting provider, I was very startled to discover that they were running a very old version of Perl.   Fortunately, they upgraded their systems.

I would also echo the notion that... you probably do want to get your own virtual-machine, instead of using shared-hosting.   The reason for this is, “memory space.”   Hosting companies generally set very small limits on how much memory a particular CGI-request can allocate.   Not so bad for PHP (which puts most of its goodies into its code-segment, compiled into its executable), but it can be a problem for Perl.   (I made this discovery, shall we say, “at a most inconvenient time.”)

When you have your own virtual-machine, you can do anything you need to do with it.   Both the expense and the actual workload are usually similar to that of shared-hosting, but you get a lot more bang for your buck.   Furthermore, it is much more difficult for the other subscribers to be able to nose-around with your stuff ... which, as it happens, they tend to do frequently.   :-O

Incidentally, I employ the use libs trick on all of my sites, giving them their own CPAN-module space separate from “the system’s” space ... even on a virtual machine.   I do the same thing on the development machines.   The reason for this is:   isolation.   The Perl modules (and other accoutrements) associated with website-X are all stored in a directory-tree that is local to website-X.   Thus, when it is time to update website-Z, I’m confident that I can do so without breaking website-X.   “Global” changes, likewise, are much less likely to unexpectedly “bring all of my sites down.”   (When several different sites really do use exactly the same library base, I use rsync (locally...) to equalize what the (still separated!!) directories contain.)   You do have to be mindful of which “system-wide” packages might be being used, so that you do not inadvertantly put new wine into old wineskins...