OpenEMR Cloud Standard fails to start

I was testing the backup/restore capabilities of OpenEMR Cloud Standard edition from AWS Marketplace, and after another new clean install I noticed that the OpenEMR server is not running. I completely deleted the entire CF stack and tried to install again from the same marketplace product. No luck. Tried with versions 7.0.1-1 and 7.0.2. Also tried this on another AWS account. The ‘docker logs’ command show the issue below (see logs).

I checked the docker-compose.yaml file - all variables are properly set. But within the container the /var/www/localhost/htdocs/openemr/sites/default/sqlconf.php is not updated and contains the defaults. I tried to echo the environment variables from the ‘’ file, like MYSQL_HOST or MYSQL_ROOT_USER, nothing is shown. Maybe this will help with anything.

Btw, I asked my coworker to try installing this as well today, and the deployment fails with the same error. I don’t see what could be wrong, as the CF template parameters are pretty straightforward and the deployments succeeds, this is the server which does not start.

OpenEMR Version
7.0.1-1, 7.0.2

I’m using: Safari

Operating System
I’m using: macOS Sonoma 14.3

This issus seems to be new. I tried to install also from the CF template for version 7.0.1 which was successfully deployed several months ago - same error.


Couldn't set up. Any of these reasons could be what's wrong:
 - You didn't spin up a MySQL container or connect your OpenEMR container to a mysql instance
 - MySQL is still starting up and wasn't ready for connection yet
 - The Mysql credentials were incorrect

@jesdynf have you seen this? Any thoughts on what could have changed?

That’s my fault, see OpenEMR Standard: SSL Rotation Required . I’ve already got a new image waiting with AWS Marketplace for approval.

Thank you for such a quick reply! Does it mean that our existing OpenEMR servers, which are connecting to the older RDS instances, might fail as well some day? At this point of time everything works fine.

Yes. Amazon rotates the certificates on their RDS instances regularly. The issue you saw today is because new RDS instances are using a newer certificate. Older instances are running for now, but they’ll come up for mandatory maintenance eventually, forcing a certificate rotation and knocking the current certificate out of play if you don’t catch it up before this happens. See Using SSL/TLS to encrypt a connection to a DB instance - Amazon Relational Database Service for more information about what RDS is thinking, and see my linked post earlier for how to rotate a certificate manually.

1 Like

Thanks! I’ve just tested some scenarios with certificate rotation and backup/restore using automated/manual recovery - everything works as documented.