SuiteCRM

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for SuiteCRM by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size (Standard_B2ms or larger). Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTPS (443).

Select Review + create, then Create.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:suitecrm-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name suitecrm \
  --image sac1647283583153:suitecrm-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open HTTPS so your team can reach the platform:

az vm open-port --resource-group <your-rg> --name suitecrm --port 443 --priority 900

Connect over SSH as azureuser:

ssh azureuser@<vm-public-ip>

First boot takes two to four minutes. During that window, the appliance generates this VM's own secrets and only then starts the web server. A browser refuses the connection until first boot finishes, and that is deliberate.

The image is built to fail closed. If first boot fails, the VM stays unreachable instead of serving a half-configured CRM.

Check the four services that make up the stack:

systemctl is-active mariadb php8.3-fpm apache2 suitecrm-cron.timer

All four report active:

active active active active

Check the HTTPS front door and the HTTP redirect, and confirm that nothing unexpected listens off the VM:

curl -sk -o /dev/null -w 'HTTPS front door: %{http_code}\n' -H "Host: $(hostname -I | awk '{print $1}')" https://127.0.0.1/
curl -s -o /dev/null -w 'HTTP port 80: %{http_code} -> %{redirect_url}\n' -H "Host: $(hostname -I | awk '{print $1}')" http://127.0.0.1/ ss -lntH | awk '{print $4}' | grep -vE '^(127\.|\[::1\])' | sed -E 's/.*:([0-9]+)$/\1/' | sort -un | paste -sd, -

HTTPS front door: 200 HTTP port 80: 301 -> https://10.0.0.10/ 22,80,443

Exactly three ports are reachable from outside the VM: SSH, the HTTPS application, and port 80, which only redirects. MariaDB is bound to 127.0.0.1 and PHP-FPM talks to Apache over a UNIX socket, so neither is a network service.

The VM generates the administrator password on its first boot and writes it to a file that only root can read:

sudo cat /root/suitecrm-credentials.txt

# sac :: SuiteCRM 8 appliance credentials
# Generated on this VM's first boot. This file is readable only by root. # Change the administrator password after your first sign-in. suitecrm.admin.user=admin suitecrm.admin.pass=******** suitecrm.db.name=suitecrm suitecrm.db.user=suitecrm suitecrm.db.pass=********

Confirm that the file is locked down and that first boot completed:

sudo stat -c '%a %U:%G %n' /root/suitecrm-credentials.txt
sudo stat -c '%n' /var/lib/sac/data/suitecrm-firstboot.done

600 root:root /root/suitecrm-credentials.txt /var/lib/sac/data/suitecrm-firstboot.done

SuiteCRM records the address it serves on in site_url, and the appliance refreshes that value on every boot. If your VM's public IP changes across a stop and start, the platform follows it with no edit from you. Read the current value:

php -r '$sugar_config=[];require "/var/www/suitecrm/public/legacy/config.php"; echo $sugar_config["site_url"], "\n";'

https://20.42.103.140

That is this VM's own public address. If you later put SuiteCRM behind a DNS name, Step 11 shows how to switch over.

Browse to https://<vm-public-ip>/. Your browser warns about the self-signed certificate until you install your own (Step 11). Accept the warning to continue.

Sign in with the username admin and the password from Step 5.

Your first sign-in opens SuiteCRM's setup wizard. The "Welcome to SuiteCRM!" page asks for your name and contact details, your locale (time zone, date and time format) and your default currency. This is SuiteCRM's own first-run experience, and it is left in place on purpose because those details are yours to set. Fill them in and select Finish. Later sign-ins go straight to the dashboard.

Then change the administrator password from the user menu at the top right. SuiteCRM locks an account for thirty minutes after five failed sign-in attempts, so keep the credentials file at hand until you have set a password you will remember.

In the top navigation, choose Accounts > Create Account, give the account a name, and select Save. The record view shows the account with its relationship panels and the opportunity insights alongside.

Then choose Contacts > Create Contact, enter a first and last name, and select Save. Set Account Name on the contact to link the two records.

Choose Accounts > View Accounts to list what you have created. The Quick Charts panel summarises new accounts by month.

This check matters, because it is the most important difference between this image and a hand-rolled SuiteCRM install. Both installer entry points are deleted from the image, and the web server refuses those routes. Verify it yourself:

A=$(hostname -I | awk '{print $1}') for p in /install.php /legacy/install.php /legacy/install/installConfig.php /legacy/config.php; do printf '%-40s %s\n' "$p" "$(curl -sk -o /dev/null -w '%{http_code}' -H "Host: $A" https://127.0.0.1$p)" done printf '%-40s %s\n' "/ (the application itself)" "$(curl -sk -o /dev/null -w '%{http_code}' -H "Host: $A" https://127.0.0.1/)"

/install.php 403 /legacy/install.php 403 /legacy/install/installConfig.php 403 /legacy/config.php 403 / (the application itself) 200

The last line shows that the denies are targeted, not a blanket block. The 403 (rather than 404) is deliberate. The web server refuses the route before SuiteCRM's front controller sees it. This matters because the application rewrites unknown paths to itself and would otherwise answer 200 with the app.

SuiteCRM's scheduler drives workflow, email reminders, inbound mailboxes and report generation. On this image it runs from a systemd timer every five minutes as the web user, instead of from a publicly reachable URL. Check the timer:

systemctl list-timers suitecrm-cron.timer --no-pager | head -3

NEXT LEFT LAST PASSED UNIT ACTIVATES Sun 2026-09-20 09:57:34 UTC 3min 26s Sun 2026-09-20 09:52:34 UTC 1min 33s ago suitecrm-cron.timer suitecrm-cron.service

To confirm that jobs are executing and not merely scheduled, read what the schedulers recorded:

sudo mariadb -u root suitecrm -BN -e "SELECT name, last_run FROM schedulers WHERE deleted=0 ORDER BY last_run DESC LIMIT 4;"

Run Report Generation Scheduled Tasks 2026-09-20 09:52:35 Check Inbound Mailboxes 2026-09-20 09:52:35 Run Email Reminder Notifications 2026-09-20 09:52:35 Process Workflow Tasks 2026-09-20 09:52:35

Those timestamps advance every five minutes. To manage which jobs are active, open Admin > Schedulers inside SuiteCRM.

Point a DNS A record at the VM's public IP, then issue a real certificate. Install certbot and request a certificate:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-apache
sudo certbot --apache -d crm.example.com

Certbot rewrites the Apache virtual host for you. Then tell SuiteCRM its new address:

sudo php -r '$c=[];require "/var/www/suitecrm/public/legacy/config.php"; $c=$sugar_config; $c["site_url"]="https://crm.example.com"; $c["host_name"]="crm.example.com"; $o="<?php\n"; foreach($c as $k=>$v){$o.="\$sugar_config[".var_export($k,true)."] = ".var_export($v,true).";\n";} file_put_contents("/var/www/suitecrm/public/legacy/config.php",$o);'
sudo systemctl restart apache2

The appliance's boot-time refresh would otherwise reset site_url to the VM's IP address. Once you use a DNS name, disable that refresh so your setting sticks:

sudo systemctl disable --now suitecrm-baseurl.service

SuiteCRM sends notifications, password resets and campaigns through an SMTP relay that you supply. Configure the relay inside the application at Admin > Email Settings, and enter your provider's host, port and credentials.

Nothing on this image listens for or relays mail, and no mail server is installed.

Check the component versions and the SSH hardening settings:

cat /var/www/suitecrm/VERSION php -v | head -1 mariadb --version | sed -E 's/.*(10\.[0-9.]+-MariaDB).*/MariaDB \1/' apache2 -v | head -1 sshd -T | grep -E '^(permitrootlogin|passwordauthentication|clientaliveinterval) '

8.10.2 PHP 8.3.6 (cli) (built: Sep 2 2026 12:56:02) (NTS) MariaDB 10.11.14-MariaDB Server version: Apache/2.4.58 (Ubuntu) clientaliveinterval 120 permitrootlogin no passwordauthentication no

The image does the following for you:

• No shared secret. The administrator password, database password, session salt, Symfony application secret and REST API signing key pair are all generated on your VM's first boot. Two VMs launched from this image share none of them.
• No installer. Both installation entry points are removed and denied, so there is no unauthenticated setup page to find.
• Loopback-only data plane. MariaDB listens on 127.0.0.1 and PHP-FPM on a UNIX socket. Neither is reachable from the network.
• Root login refused. PermitRootLogin no and PasswordAuthentication no are set. Administer the VM as azureuser with your SSH key.

These steps remain your responsibility:

• Restrict 22/tcp to your management network in the NSG.
• Install a real certificate (Step 11).
• Change the admin account password.
• Create individual named users instead of sharing the administrator account.

A SuiteCRM backup consists of the database, the uploaded files and the configuration:

sudo mariadb-dump -u root --single-transaction --routines suitecrm > /var/backups/suitecrm-$(date +%F).sql
sudo tar czf /var/backups/suitecrm-files-$(date +%F).tar.gz \
  /var/www/suitecrm/public/legacy/upload \
  /var/www/suitecrm/public/legacy/custom \
  /var/www/suitecrm/public/legacy/config.php \
  /var/www/suitecrm/.env.local

Copy both files off the VM, to Azure Blob Storage or your own backup target. Test a restore before you rely on the backup.

The image ships with unattended security updates enabled, so the operating system keeps itself patched. To apply pending updates on your own schedule, run:

sudo apt-get update && sudo apt-get -y upgrade

Apply SuiteCRM point releases with the product's own upgrade tooling, either from Admin > Upgrade Wizard or from the command line with bin/console suitecrm:app:upgrade. Always take the Step 14 backup first, and read the upstream release notes for the version you are moving to.

SecureAnyCloud publishes refreshed images for new SuiteCRM releases. Moving to a new image is the cleanest path for a major version change.