Error after update to 5.12.17-L174

5.12.17

self hosted - linux

Laravel log says:
[2025-08-18 14:10:44] production.ERROR: Connection refused [tcp://127.0.0.1:6379] {“userId”:1,“exception”:"[object] (Predis\Connection\ConnectionException(code: 111): Connection refused [tcp://127.0.0.1:6379] at /var/www/invoiceninja/vendor/predis/predis/src/Connection/AbstractConnection.php:144)
[stacktrace]

I tried updating to latest this morning, and half way expected something to go wrong because I recently spun up a blank vm of this version and immediately got errors - I was correct.

I will roll back my production vm but leaving this information here so perhaps it can be addressed before next update.

The error occurred when I tried to archive some invoiced tasks. Gave me “500 internal server error”.

Linking the post about the blank vm error on first setup for reference.

Apparently I can not roll back because my snapshots were not firing as of a few days ago. So this is now a lot more time sensitive as I can not invoice or create new work tasks. Any ideas would be much welcome.
If I have to spin up a new server and transfer the data into it, I can do that.

Hi,

It may help to manually copy over the .16 release.

you mean to install the prior version over .17 on the existing VM?

I did just find this article:

which appears to match my problem.

is Redis now a required component of the installation or will this be addressed in a future update?

should I try installing the prior version and copying over the storage directory and .env file?

if there is a post with the process you are suggesting I try, please point me to it

Thanks -

Redis isn’t required. If you need a quick fix you can try downgrading, otherwise you can wait for the next release.

just unzip the .16 over the current, or do I need to rename the current/copy out storage dir and /env file, then unzip and copy those two items back?
I’ve never downgraded before, so I need to make sure I am doing it correctly.
thanks

You just need to untar over it, if you have concerns you can make a backup of the database and .env file.

Rolling back to 5.12.16 solved the problem.

Earlier, I though it had not, but that was because I unzipped into the parent directory, which, of course, produced odd results.
Rolled my vm back, correctly installed 5.12.16 over 5.12.17 and I am now able to work again.

Thanks, Hillel!

If you’re planning to roll back your self-hosted Invoice Ninja installation, it’s best to avoid overwriting the current setup directly. Instead, here’s a clean and reliable method I recommend:

Safe Rollback Method

  1. Create a new directory for the version you want to install.
  2. Copy over your public/storage folder and your .env file from the current installation.
  3. Rename the old install directory to something like invoice-ninja-backup to keep it as a fallback.
  4. Rename the new install directory to match your production path.
  5. Run php artisan optimize in the new directory to finalize the setup.

This approach lets you cleanly install any version while preserving your configuration and uploaded files. It also gives you a quick way to revert if something goes wrong.

Additional Best Practices

  • Backup your database first
    Always a good precaution, even though Invoice Ninja’s database migrations are generally backward-compatible. In most cases, rolling back won’t cause schema issues—but having a backup is still wise.
  • Check for breaking changes
    Review the changelog of the version you’re rolling back to. Some features or settings may have changed or been deprecated.
  • Verify file permissions
    After copying and renaming directories, ensure correct permissions and ownership—especially for storage and bootstrap/cache.
  • Clear all caches
    Run these commands to avoid stale config or view data:
php artisan config:clear
php artisan cache:clear
php artisan view:clear
php artisan route:clear

Note: If you’re using the compiled ZIP release from GitHub, all dependencies are already included, so there’s no need to run composer install.

This method has worked reliably for me many times, and I even use a script to automate it. It’s safer than relying on auto-updaters or server-level backups, which can be hit-or-miss (especially with cPanel).

1 Like

New release with a fix