Ci
Applications Azure

CiviCRM on Ubuntu 24.04 on Azure User Guide

| Product: CiviCRM on Ubuntu 24.04 LTS on Azure

Overview

CiviCRM is the leading open source constituent relationship management platform, purpose built for nonprofits, NGOs, associations and civic sector organisations. It brings contact and membership management, contributions, donations and fundraising, events and registration, bulk email and mailings, activities and cases, and reporting together in one web console gated by CiviCRM's own user and access control. This image ships CiviCRM in Standalone mode, so there is no separate content management system to install or maintain, served by nginx and PHP 8.3 FPM on a hardened, fully patched Ubuntu 24.04 LTS base, together with a bundled local MariaDB server so the appliance is complete and useful on its own. CiviCRM runs behind an nginx reverse proxy on port 80. The bundled MariaDB listens only on the loopback interface (127.0.0.1:3306) and keeps its database, along with CiviCRM's settings, uploads and template cache, on a dedicated Azure data disk. A unique administrator password and unique site and cryptographic keys are generated on the first boot of every VM, and no default or shipped CiviCRM login authenticates. Backed by 24/7 cloudimg support.

cloudimg is not affiliated with or endorsed by CiviCRM LLC or the CiviCRM project. CiviCRM is free and open source software distributed under the GNU AGPL v3 license; this image ships the unmodified upstream release.

What is included:

  • CiviCRM Standalone 6.16.0 served by nginx and PHP 8.3 FPM, managed by systemd
  • A bundled MariaDB server holding the CiviCRM database, already installed and ready
  • A ready to use CRM served on :80, with the full schema and the standaloneusers login extension in place
  • A per VM administrator password generated on first boot and recorded in a root only file
  • No default login: the admin is set to a unique per VM secret stored as a salted hash, and no known or blank credential authenticates
  • Per VM CIVICRM_SITE_KEY and cryptographic signing keys, rotated on every first boot
  • MariaDB bound to 127.0.0.1 only, never exposed to the network
  • A dedicated Azure data disk carrying the MariaDB database and CiviCRM's settings, uploads and cache
  • All required PHP extensions and CiviCRM's recommended PHP limits preconfigured, with the MariaDB settings CiviCRM requires
  • Asset URLs that follow the request host, so the console works by public IP or your own domain with no reconfiguration
  • nginx.service, php8.3-fpm.service and mariadb.service as enabled systemd units
  • An unauthenticated /healthz endpoint for Azure Load Balancer health probes
  • 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point; size up for larger or busier organisations. NSG inbound: allow 22/tcp from your management network and 80/tcp (and 443/tcp once you add TLS) for the console. CiviCRM serves plain HTTP on port 80 out of the box; for production, terminate TLS in front of it with your own domain. The bundled MariaDB is never exposed: it listens on 127.0.0.1 only, so port 3306 stays off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for CiviCRM by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Review the dedicated data disk on the Disks tab, then Review + create then Create.

Step 2 - Deploy with the Azure CLI (alternative)

Prefer the command line? Create the VM from the cloudimg CiviCRM image with your resource group, image URN, size and SSH key. Open ports 22 and 80 on the network security group, then browse to the public IP.

az vm create \
  --resource-group my-rg \
  --name civicrm \
  --image <cloudimg-civicrm-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

az vm open-port --resource-group my-rg --name civicrm --port 80 --priority 900

Step 3 - Confirm the services and retrieve the admin password

SSH in as azureuser. All three services plus the first boot unit are active, with nginx listening on port 80 and MariaDB bound to the loopback interface only, and the health endpoint returns 200.

systemctl is-active nginx php8.3-fpm mariadb civicrm-firstboot
ss -tlnp | grep -E ':80 |:3306 '
curl -s -o /dev/null -w '/healthz -> HTTP %{http_code}\n' http://127.0.0.1/healthz

The nginx, php8.3-fpm, mariadb and civicrm-firstboot services all active, with nginx on port 80, MariaDB bound to loopback 127.0.0.1:3306 and the health endpoint returning HTTP 200

On the first boot of every VM, CiviCRM generates a unique administrator password and records it, together with the sign in URL, in a root only file. Read it with sudo:

sudo cat /root/civicrm-credentials.txt

The per VM CiviCRM credentials file, showing the admin login user, the generated password and the console sign in URL

Step 4 - Understand the no default credential security model

CiviCRM is installed with a build time password that is immediately discarded, and the shipped image carries no known credential. On first boot the admin is set to a unique per VM secret, stored as a salted Drupal 7 style hash, and the site key and cryptographic signing keys are regenerated. You can confirm the model at any time: the per VM admin password authenticates, while common guesses such as admin, password, civicrm and a blank password are all rejected.

sudo bash /usr/local/sbin/civicrm-cred-roundtrip.sh

Proof that the per VM admin authenticates through CiviCRM's own password check while default and weak credential guesses are rejected, and that the stored password is a salted hash

Step 5 - Sign in to CiviCRM

Browse to http://<your-vm-ip>/civicrm/login and sign in with the user admin and the password from the credentials file. CiviCRM presents its own sign in page. The base URL and all asset URLs follow the request host, so the console is reachable by the VM public IP or your own domain with no extra configuration.

The CiviCRM Standalone sign in page showing the username and password fields and the CiviCRM logo

After signing in you land on the CiviCRM home dashboard, with the main navigation for Search, Contacts, Contributions, Events, Mailings, Memberships, Reports and Administer across the top, and configurable dashlets below.

The CiviCRM home dashboard after signing in, showing the top navigation and the resources and news dashlets

Step 6 - Manage contacts

Open Contacts then Find Contacts to search and list the people and organisations in your database. Each contact carries its own record with communication preferences, groups, tags, relationships, activities and contribution history. Use New Individual or New Organization to add contacts, and import in bulk from CSV when migrating.

The CiviCRM Find Contacts results listing individuals and organisations with name, email and per row actions

Step 7 - Record contributions and run events

CiviCRM's fundraising tools live under Contributions: record donations and payments against contacts, define financial types, and report on totals over time. Under Events, the Manage Events page lists your events with their type, dates and public status; from here you configure registration, fees and participant tracking.

The CiviCRM Manage Events page listing an event with its type, public status and start date, and per event configuration actions

Step 8 - Where your data lives

The bundled MariaDB stores its database on a dedicated Azure data disk, and CiviCRM's settings, uploaded files and template cache are relocated onto the same disk. All of this is captured into the image and re-provisioned on every VM, so your CRM data is kept off the operating system disk.

df -h /data
mount | grep -E ' /data | /var/lib/mysql | /var/www/civicrm/(private|public) '

The dedicated 20 GiB Azure data disk carrying the MariaDB datadir and CiviCRM's private and public directories, all mounted from the data disk

Step 9 - Prepare for production

The appliance is ready to explore out of the box. Before you put it into production:

  • Add your own domain and TLS. Put CiviCRM behind HTTPS with your own certificate, and pin CIVICRM_UF_BASEURL in /var/www/civicrm/private/civicrm.settings.php to that domain.
  • Configure outbound email (SMTP). Set an SMTP relay under Administer then System Settings then Outbound Email so CiviMail and receipts can be delivered.
  • Add a payment processor. Connect your payment provider under Administer then CiviContribute then Payment Processors to accept online donations.
  • Review the System Status page under Administer then Administration Console then System Status, and work through any remaining recommendations.
  • Restrict access. Keep SSH limited to your management network and place the console behind TLS and, ideally, a web application firewall.

Support

This image is maintained by cloudimg and backed by 24/7 support. CiviCRM is free and open source software licensed under the GNU AGPL v3; cloudimg is not affiliated with or endorsed by CiviCRM LLC or the CiviCRM project. For help deploying or operating the image, contact cloudimg support.