Tips & Tricks

OpenEMR Tips & Tricks on CloudSOE Images

2026-07-30 · openemr docs

A collection of practical advice for running the CloudSOE OpenEMR image in production, on either cloud.

Back up the two things that matter

An OpenEMR system is its database plus the sites tree (configuration and patient documents). A simple nightly backup:

sudo mysqldump openemr | gzip > /home/$(whoami)/openemr-db-$(date +%F).sql.gz
sudo tar czf /home/$(whoami)/openemr-sites-$(date +%F).tar.gz -C /var/www/html sites

Ship those files off the instance — encrypted, and to storage that meets your regulatory requirements; this is patient data. Cloud-level snapshots (EBS on AWS, disk snapshots on Azure) are a good complement, but application-level dumps restore faster and across instance types.

Keep things updated

  • OpenEMR patch releases are announced on open-emr.org; follow the project’s upgrade instructions and take a full backup first.
  • OS security updates come from Ubuntu’s repositories: sudo apt update && sudo apt upgrade on your own schedule.
  • New CloudSOE image versions are published to the marketplaces — for major moves, launch a fresh instance and restore your backup rather than upgrading in place.

Security hardening

The image already disables password SSH, rotates the Administrator password per instance, redirects HTTP to HTTPS and denies web access to patient documents. For a medical records system, go further:

  • Change the rotated Administrator password after your first login, and create named per-user accounts — don’t share Administrator.
  • Restrict ports 80/443 in your security group / NSG to your clinic’s network or VPN where practical.
  • Get a trusted certificate before real use — certbot is preinstalled; see the configuration guide.
  • Review OpenEMR’s own audit log (Administration → System → Logs) periodically.
  • Your regulatory obligations (e.g. HIPAA) also cover backups and access control around the VM itself — encrypt disks and backups.

Troubleshooting first boot

The first-boot service deliberately waits about a minute before rotating credentials, so don’t panic if the credentials file isn’t there seconds after launch. If it still hasn’t appeared after a few minutes:

systemctl status openemr-firstboot
journalctl -u openemr-firstboot --no-pager

If the automatic password reset failed

The credentials file tells the truth: if rotation failed, it lists the build default and warns you to change it immediately. Do that either in the UI, or from the shell:

sudo php /usr/local/bin/change-password.php 'my-new-strong-password'

Never leave the build-default password in place on an internet-facing instance.

The MOTD shows the wrong IP

The login banner captures the public IP at first boot. If you later attach a new Elastic IP / public IP, the banner will be stale (the system itself is unaffected). Edit /etc/motd to update it.

Test HTTPS from outside

On Azure especially, a VM often cannot reach its own public IP from within. Always verify the system from your own machine:

curl -skI https://<public-ip>/

The certificate’s CN should be your public IP (or your domain once you’ve switched to a trusted certificate — see the configuration guide).