PDF generation didn't work on 1.6.46 (5.5.50) with Cloudron

I just wanted to report, after my Cloudron updated IN to 1.6.46 the PDF generation was completely hosed, basically. It wouldn’t load at all on the invoice preview, when I would click “View PDF” if it had been generated before it would load there, if it hadn’t it either wouldn’t load or had the improper colors and formatting.

The solution for me was to roll back to a saved backup of 1.6.45 and everything is happy once again.

EDIT: Oops, in non-cloudron speak this was going from v5.5.49 to v5.5.50, and then back again.


Which PDF generator are you using?

cc @david

Hi! How can I find out for sure? It’s whatever Cloudron setup by default, which appears to be local generation simply by seeing a short CPU spike when that happens.

In my env file is this:


What is PDF_GENERATOR set to?

That’s actually not present in the env file. I don’t know if cloudron is setting the variable somewhere else, or if it “just works” without that set and is part of the issue when it upgrades (doesn’t work unset on 5.5.50).

It may help to add PDF_GENERATOR=hosted_ninja to the .env file.

You can check which generator is being used using the health check option in the about dialog.

Interesting, okay. Will this still use SnapPDF locally? (I prefer local generation, if possible)

I checked with the health dialog - great resource I had forgotten about, it is SnapPDF right now on 5.5.49.

Would I need to run a php artisan optimize after adding this?

Side notes on the health check:
It tells me that README.md is not writable and that PHP memory limit is too low (below 512M) to support the in-app update, but, I think this has been okay because I’m careful to let Cloudron handle the updates. Interesting notes here on setting the memory limit in Cloudron for IN for anyone reading.

No, you would need to set it to snappdf to use that option.

That’s correct, if you’re using Clourdon to update the app you can ignore those messages.

@david what’s the .env property that Softaculous set hide the update options? We can ask Cloudron to set the same property.


I believe it is


Awesome, and that makes sense. There really doesn’t seem to be much downside for the hosted_ninja option either. When I update again, this will give me plenty to experiment with. Thank you. :slight_smile:

I wonder if you guys request the change if Cloudron will update the env files, or if they pretty much leave those static (and it would be on me) once they are generated?

I think this could be a good idea, if delegating the system users may not realize how updates are managed.

Thanks, I’ll reach out to them.

I imagine this change would only be applied against future installs.

1 Like

I did some more testing on all of these things. Yes, new Cloudron installs add the DISABLE_AUTO_UPDATE=true to the env file, and it works great. But also, there was an update released for the ones previously installed! I had already added it to my installation manually, so I’m guessing there is a check before it adds to the env file because it didn’t change (or duplicate within) mine, but you can see the update dialog for the change here:


Finally, I couldn’t get self hosted pdf generation on 5.5.50 to work even when adding PDF_GENERATOR=snappdf to my env file within the Cloudron environment (this didn’t appear to change anything anyway, according to the Health check in the about dialog), but PDF_GENERATOR=hosted_ninja works perfectly so I will leave that for now.

Could the PDF_GENERATOR be affected by the PHP memory limit? Everything works well, however my Cloudron is only providing 307MB according to the health check, of course noting that it doesn’t reach the recommended 512MB for in-app/non-Cloudron updates.

Snappdf worked great on the last version 5.5.49 with the same setup. I guess it could just be a Cloudron thing as well (though I do love Cloudron for this app for the ease of automating updates and backups).


We’ve had some queries regarding this issue with cloudron, there may be dependency issues in chrome that have changed which could cause this. We’d need the errors from the logs to understand more.

1 Like