V5.3.79 - No longer getting update notifications

OK thanks! But my cron is running php artisan schedule:run every minute, as per the installation instructions. Do I need to run something else?

Upon further reading it seems like my auto-update would fail because my IN installation is not owned by the webuser (www-data in my environment). I could not find a way to run this setup under a under a cPanel user, I would just get 403 errors no matter what I tried. On the other hand, Softaculous updates have been unreliable for me recently (failed updates requiring manual updates on top of them, thus making the automatic process redundant).

I am currently trying to go the git way, and I have successfully installed IN using git. It makes the whole install base take more disk space, but I like that the update process is streamlined through 3 simple commands:

git pull
composer install
php artisan ninja:post-update

Can I put this into a script and run it via cron, say, every day? Would that work as some kind of “poor man’s auto-update”, or would it just waste resources and be prone to errors?


It certainly will work, and it is exactly how we initially built the updater. However a lot of platforms don’t allow git, and there simply were too many issues to use it reliably as an auto updater.

As long as you never modify any of the files in the folder (they will register as changes and block git pull) this should be a reasonable way to perform upgrades.

1 Like

Great! Sounds like a good plan then, I might try that.

That being said, let me quote myself:

That’s what the self-host docs say but… now look at this, from tonight:


Apparently the updater doesn’t absolutely need the web server to be the owner of the files.

Also, it looks like the git install checked for dependencies and provided me with some kind of missing package that would allow the check to work! But then I thought the invoiceninja.zip file was just the whole github directory in a compressed file… I don’t know what’s different. I also added allow_url_fopen to my php.ini since I noticed that it was a missing piece to allow Snappdf to download chrome… maybe it’s related to the IN updates too?

Anyway, the update worked :open_mouth: :

I guess I can delete the .git folder for now and wait for the next version to see what happens then!


There are a few moving parts here:

  1. We have a cron job which performs checks on the latest version. So regardless of how you have installed the application, this notification will appear.

  2. Unless the entire directory - recursively - is owned by the web user, the preflight checks we use before the upgrade will fall and advise the file which fails to be writable.

  3. git install will pull in the latest repository files, however, if we ever change a dependency in the application and/or an existing dependency is updates, then the app may fail to boot up… So as part of your upgrade/update cycle you’ll also need to include

composer install -o -no-dev

To ensure your packages are up to date.

What/where is that cron job? How can I make sure it runs? Because it wasn’t running on my three servers since v5.3.79 at least… but it worked today!

But it looks like my whole install was updated, without being owned by the web user (it’s 100% owned by my user user). How can that be possible?

OK thanks for the tip! For updates, though, the docs just refer to running composer install (without arguments), is there a reason for that?

And about having packages up to date, do you recommend using composer update too or should I just stick to the versions inside the lock file?

What/where is that cron job? How can I make sure it runs? Because it wasn’t running on my three servers since v5.3.79 at least… but it worked today!

This runs on the scheduler (app/console/kernel.php) all of the apps scheduled jobs runs in there.

The only way the up would be able to update, is if those permission checks pass. So whatever user ran the command, had the right permissions.

I would always suggest people use

composer install -o --no-dev

The -o flag rebuilds the autoloader, and most importantly --no-dev installs the production packages, and not the development packages. If you install the development packages and then expose your app to the internet, your .env credentials may leak along with other data.

1 Like

Thanks for the info!

Maybe those arguments could be added to the self host documentation, so that no dev packages are installed during updates:

I have another question related to git/composer : when I run composer install -o --no-dev, it uninstalls the packages that were installed when ran the command to install the Snappdf libraries (composer require beganovich/snappdf), 63 packages in total.

How can I keep both libraries without them conflicting?

you shouldn’t have had to use compose require

we already have it as a dependency in composer.json

Okok, thanks. I was just following the instructions at GitHub - beganovich/snappdf: Convert webpages or HTML into the PDF file using Chromium-powered browsers.

So if I understand I should not have to do that to be able to run Snappdf? Because it looks like this installs 63 packages that are not in the IN composer.json!

the only thing you “may” need to do is the snappdf download to bring down the binary itself.

composer determines all the required dependencies and matches them depending on what else is required in the project, so that part can certainly be left out.

1 Like