I’m using InvoiceNinja on an AWS instance using a custom URL, let’s say http://billing.example.com for the sake of this post. I’ve set the URL under “Settings > System Settings” (which then updates APP_URL to ‘http://billing.example.com/’ in /opt/bitnami/apps/invoiceninja/htdocs/.env)
However, whenever the instance/server is restarted the APP_URL automatically goes back to my AWS Public DNS value, even though I have an Elastic IP assigned (not that that should matter in this context) and even though I’ve already set the URL to http://billing.example.com/
I saw something potentially related on the post below at but wasn’t sure if it directly applied.
It may help to explain that the System Settings page is a just a wrapper for the .env file in the root folder of the project. If you’re having trouble with a value it may be best to work with the file directly to eliminate other variables.
I’ve been working with the .env file directly, I was more describing the other way to get to it in case other users were having the same issue. In an attempt to stop it from happening I set the permissions to 444, but after rebooting the permissions are changed to 644, APP_URL is changed (as described above) and the timestamp is updated.
I’m not certain, but with this evidence it appears that .env is being regenerated on each reboot.
Warning: “Stopping” an instance is completely different from “terminating” an instance! When you terminate an EC2 instance, by default it deletes the EBS boot volume and other volumes that were created at run time. Make sure you understand the difference before you start doing one or the other.
I’m not sure why you are bringing up terminating an instance as I’ve made no reference to doing so in my post. All I am doing is either $ sudo reboot from within the console, or Actions > Instance State > Reboot within the EC2 management console. (Neither of which should be deleting any volumes or instances.)
In case anybody is reading this in the future, I was unable to find a workaround for this. Instead, I built the self-hosted solution from scratch rather than using the Bitnami instance. I’m not 100% certain that the issue was caused by the Bitnami instance, but it appears that it was.
There were also issues where it was generated thousands of recurring invoices and triple-charging credit cards, both of which have been resolved by non-Bitnami self-hosting. Again, I can’t verify if it was solely the Bitnami instance as it appears that other people have been working fine with it.