Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

SOLVED Is there an easy way to update an old PHP 7.2 LAMP app to PHP 7.3?

  • When I set up my app, I chose the LAMP app that just said "LAMP" and not one that specified the version - and am now realizing that I should have chosen 7.3 specifically.
    So, I'm wondering if there's an easy way to update the PHP in that app without needing to create a new app (with new database information, new redis information, etc.).

  • Staff

    There is indeed no easy way to do this currently. The cli tool used to be able to override existing apps with another package appstore id, however that is not the case anymore.
    The approach would be to restore from an app backup into a new instance of the lamp app with php 7.3

    Usually this should not be required as we update apps with new versions directly, this however was not easily possible with the LAMP app since it would break too many existing installations 😕

  • To be clear: When you say "The approach would be to restore from an app backup into a new instance of the lamp app with php 7.3"
    Do you mean that I do the normal stuff of downloading the DB, copying over all the files, then editing DB/redis credentials across the app - or do you mean download the backup file for the LAMP app the Cloudron supplies, create a new LAMP app, and use the "import from external file" function?

  • Staff

    The approach would be outlined in
    This case however is special since usually this only works for the same app package (ie you cannot import a Nextcloud backup into say WordPress) but since in your case both apps are sufficiently similar it should just work.

  • Confirmed. I just tested @nebulon 's suggested method here, and it worked flawlessly.

    I did the following steps to

    Upgrade my LAMP application from PHP 7.2 to PHP 7.3

    • Backed up my LAMP with php7.2.
    • Downloaded the "Backup Configuration" JSON file for the backup of the old container
    • Created a new LAMP container.
    • Went to Backups -> Restore
    • Uploaded the "backup configuration file" downloaded from the old container
    • Entered the secret for my storage block storage space
    • Clicked restore

    After that everything worked, and I was on PHP 7.3
    The LAMP application I migrated was a regular forum; Vanillaforums php/mysql stack.

    Thanks @nebulon

  • I tried to migrate to 7.3 using the steps provided above - and all seemed to be working swimmingly until it errored out with "ECONNRESET" importing the mysql DB.
    It's a very large mysql DB (5.8 GB). Any idea why the connection might reset (the backup is on a linode volume connected to the local filesystem)? Or a way to go about upgrading this app without hitting the same error again?

    EDIT: To make matters worse, I also can't uninstall the app where I tried to do the upgrade for likely the same reason. Error was: " Error : Addons Error - Error tearing down mysql: socket hang up "

    EDIT 2: I resolved, at least the uninstall problem, by allocating more RAM to mysql. Seeing if that solves the over all problem now!

  • Caution. There are dragons.

    Although this approach worked perfectly.

    I just totally screwed up.
    To do a little cleanup, I deleted the "old" container with my 7.2 LAMP application.
    Little did I know that my migrated 7.3 app was still persisting data to the 7.2 database instance!
    It was all my fault, but this was not obvious to me. Make sure to check which Mysql database your 7.3 version is actually connecting to!

    This has now led me down the disaster recovery path to try and fish out a backup package of the 7.2 version.
    About to write another post about this situation. (link to disaster recovery thread)

  • @makemrproper yes, I think this method isn't going to work for me. Especially if it still refers to the old app's database. (Though, if that's the case, I'm not sure why it continually fails due to a MySQL disconnection error) I'll just transfer the files and the database myself. Seems like way less headache!

  • Staff

    @Nicolas One way to avoid this mistake is use getenv('CLOUDRON_MYSQL_USERNAME'), getenv('CLOUDRON_MYSQL_DATABASE') instead of the raw values. This way when you migrate next time, it will pick up the correct database connection values.

    The full env list for MySQL is at