ITFlow 26.07 IT Documentation and MSP Management on Ubuntu 24.04 on Azure User Guide

Overview

ITFlow is the open source IT documentation and business management platform built for managed service providers and internal IT teams. It gives you one authoritative place to record every client together with their contacts, locations, assets, networks, racks and credentials, and then runs the work around them: tickets with email parsing and a client portal, projects, invoices, quotes, recurring billing, expenses, and domain and SSL certificate expiry tracking. An encrypted credential vault with TOTP support keeps client passwords and second factors under the same roof as the documentation that explains them.

The cloudimg image ships ITFlow 26.07 served by Apache and PHP 8.3 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. It is served over HTTPS from the moment it boots, which matters for a product that stores your clients' passwords: ITFlow itself refuses to present a sign in form over plain HTTP. The bundled MariaDB listens only on the loopback interface (127.0.0.1:3306) and keeps its data on a dedicated Azure data disk, alongside your uploaded client documents. No administrator password exists anywhere in the image: ITFlow installs itself on your own instance at first boot and generates a unique password and a unique TLS certificate for that instance. Backed by 24/7 cloudimg support.

What is included:

• ITFlow 26.07, the current monthly stable release, installed from the official upstream source and verified by checksum at build time
• Apache 2.4 with PHP 8.3 and OPcache, plus every PHP extension and shell command ITFlow requires
• HTTPS on port 443 with a self signed certificate generated for your instance at first boot, and port 80 permanently redirecting to it
• MariaDB bound to 127.0.0.1:3306, with its data directory on a dedicated 20 GiB data disk
• Your uploaded client documents, ticket attachments and invoice PDFs on that same dedicated data disk
• A unique administrator password, database password and TLS certificate generated on the first boot of every VM
• Scheduled jobs (mail queue, ticket email parser, domain and certificate refresh) on a systemd timer rather than a public web endpoint
• Hardening past a stock install: the web installation wizard is deleted, and PHP cannot execute from the writable uploads tree

Prerequisites

• An Azure subscription and permission to create virtual machines
• The Azure CLI installed and signed in (az login), if you deploy from the command line
• An SSH key pair for the VM administrator account (azureuser)
• Inbound TCP 443 (and 80 for the redirect) open to the clients and staff who will use ITFlow, plus TCP 22 for administration

Step 1 - Deploy from the Azure Marketplace

Find ITFlow 26.07 IT Documentation and MSP Management on Ubuntu 24.04 LTS by cloudimg in the Azure Marketplace and select Get It Now. Choose your subscription, resource group and region, keep the recommended Standard_B2s size or larger, set the administrator username to azureuser with your SSH public key, and allow inbound 443, 80 and 22. The image attaches its own 20 GiB data disk automatically.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group my-itflow-rg \
  --name my-itflow-vm \
  --image cloudimg:itflow-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

az vm open-port --resource-group my-itflow-rg --name my-itflow-vm --port 443 --priority 1001
az vm open-port --resource-group my-itflow-rg --name my-itflow-vm --port 80 --priority 1002

First boot installs ITFlow for this VM: it generates the TLS certificate, creates the database, creates your administrator account and writes the credentials to a root only file. That takes roughly 15 to 30 seconds after the VM reports as running.

Step 3 - Confirm the services are running

SSH in as azureuser and confirm Apache and MariaDB are up, the scheduler is armed, and the ports are as expected. ITFlow answers on 443; MariaDB is bound to loopback only and is not reachable from outside the VM.

systemctl is-active apache2 mariadb

active
active

systemctl is-enabled itflow-scheduler.timer

enabled

sudo ss -tlnp | grep -E ':443 |:80 |:3306 ' | sed 's/  */ /g' | cut -c1-90

LISTEN 0 80 127.0.0.1:3306 0.0.0.0:* users:(("mariadbd",pid=991,fd=23))
LISTEN 0 511 *:443 *:* users:(("apache2",pid=5675,fd=6),("apache2",pid=5535,fd=6),("apache
LISTEN 0 511 *:80 *:* users:(("apache2",pid=5675,fd=4),("apache2",pid=5535,fd=4),("apache2

The health endpoint answers over HTTPS, and plain HTTP redirects to it:

curl -ks -o /dev/null -w 'https /healthz -> HTTP %{http_code}\n' https://127.0.0.1/healthz
curl -s -o /dev/null -w 'http  /       -> HTTP %{http_code} -> %{redirect_url}\n' http://127.0.0.1/

https /healthz -> HTTP 200
http  /       -> HTTP 301 -> https://127.0.0.1/

/healthz is deliberately left reachable over plain HTTP so an Azure load balancer probe works without following a redirect. Everything else on port 80 redirects to 443.

Step 4 - Retrieve the per VM administrator password

No password ships in the image. Your instance generated its own on first boot and wrote it to a file only root can read.

sudo cat /root/itflow-credentials.txt

The file gives you ITFLOW_ADMIN_EMAIL, ITFLOW_ADMIN_PASSWORD and the internal database credentials. The sign in account is admin@example.com; you can change that address once you are signed in.

Step 5 - Sign in

Browse to https:// followed by your VM's public IP address or DNS name.

Your browser will warn you that the certificate is not trusted. That is expected: the appliance generated a self signed certificate for your instance at first boot, because no image can know the DNS name you will put in front of it. Accept the warning to continue, or jump to Installing your own TLS certificate below to replace it first.

Sign in with the email and password from Step 4.

If you see the message "Login is restricted as ITFlow defaults to HTTPS only for enhanced security", you have browsed to http:// rather than https://. Use HTTPS.

Step 6 - Set the base URL that emailed links are built from

This step matters before you invite any client. ITFlow builds the links it emails (ticket portal links, invoice and quote links, guest share links, and new user password setup links) from a single setting called $config_base_url. First boot sets it to the address your VM could prove it had, which on Azure is its private IP, because Azure's instance metadata service does not report a VM's public IP address.

Check what it is set to:

grep -E '^\$config_base_url' /var/www/itflow/config.php

$config_base_url = '10.0.0.5';

Once the VM has the public DNS name or IP your clients will actually use, set it here. Substitute your own hostname for <your-domain>:

sudo sed -i "s|^\$config_base_url = .*|\$config_base_url = '<your-domain>';|" /var/www/itflow/config.php
grep -E '^\$config_base_url' /var/www/itflow/config.php

Every ITFlow installation has to make this choice; it is not specific to this image. Signing in and using the product works regardless, but emailed links will point at whatever this value says.

Step 7 - The dashboard

After signing in you land in the agent interface. The dashboard summarises income, expenses and profit, recurring revenue, unbilled tickets and new clients, with a cash flow chart. Use the Financial and Technical toggles at the top to show each panel.

Change your administrator password now that you are in: open the user menu at the top right and choose My Preferences. The password from Step 4 is a bootstrap credential that is unique to your instance, and replacing it with your own is good practice.

Step 8 - Add your first client

Clients are the object everything else in ITFlow hangs from. Select Clients in the sidebar, then New Client. Give the client a name and a primary contact, then select Create Client.

Open the client to reach its overview. This is where ITFlow earns its keep: contacts, locations, assets, licences, credentials, networks, racks, certificates and domains for that client, alongside its tickets, quotes, invoices and billing position, plus a running activity log.

Credentials stored against a client are encrypted. The encryption key is unwrapped by your own password when you sign in, which is why ITFlow asks you to sign in again after a password change and why nobody with only database access can read them.

Step 9 - Tickets

Select Tickets to reach the support queue. Tickets can be raised by hand, through the client portal, or created automatically from inbound email once you connect a mailbox under Admin then Mail Settings. The mail queue and the ticket email parser run automatically on this image; see Step 11.

Step 10 - No known or default credentials

This image contains no administrator account at all. Rather than shipping a preinstalled copy whose password would have to be rotated, ITFlow installs itself on your instance at first boot and creates the administrator with a password generated there and then. That ordering is deliberate: ITFlow derives the credential vault's encryption key from the administrator password, so the per instance password has to be the original password rather than a replacement.

You can prove the result on your own VM. The round trip below signs in against the real login form with the password from the credentials file, and the query confirms exactly one account exists:

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

PASS: the credential in /root/itflow-credentials.txt authenticates (index.php -> https://127.0.0.1/agent/clients.php)

The paths that upstream protects with .htaccess files are denied by the web server configuration on this image, including the guard that stops PHP executing from the writable uploads tree:

for p in /config.php /scripts/setup_cli.php /cron/cron.php /uploads/probe.php /plugins/vendor/autoload.php /setup/; do
  printf '%-32s HTTP %s\n' "$p" "$(curl -ks -o /dev/null -w '%{http_code}' https://127.0.0.1$p)"
done

/config.php                      HTTP 403
/scripts/setup_cli.php           HTTP 403
/cron/cron.php                   HTTP 403
/uploads/probe.php               HTTP 403
/plugins/vendor/autoload.php     HTTP 403
/setup/                          HTTP 404

/setup/ returns 404 because the web installation wizard is deleted from this image rather than merely disabled. Upstream leaves it in the web root, gated by a configuration flag; it is an unauthenticated database configuration endpoint, and this image does not need it.

Step 11 - The scheduled jobs

ITFlow needs scheduled jobs for its mail queue, inbound ticket email parsing, and domain and certificate expiry refresh. Upstream asks you to add these to a crontab. This image runs them from a systemd timer every five minutes, so there is no public web endpoint that an anonymous visitor could trigger.

systemctl is-enabled itflow-scheduler.timer

enabled

Run a pass by hand at any time:

sudo systemctl start itflow-scheduler.service
sudo systemctl is-active itflow-scheduler.timer

Step 12 - Verify the stack and where your data lives

The certificate is issued for your instance and is valid for a year:

sudo openssl x509 -in /etc/ssl/cloudimg/itflow.crt -noout -subject -dates

subject=C = GB, O = cloudimg, CN = 10.0.0.5
notBefore=Jul 16 18:40:00 2026 GMT
notAfter=Jul 16 18:40:00 2027 GMT

Both the database and your uploaded client documents live on the dedicated data disk, not the OS disk, so they can be snapshotted and grown independently:

findmnt -no SOURCE,TARGET,FSTYPE,SIZE /data
findmnt -no SOURCE,TARGET /var/lib/mysql
findmnt -no SOURCE,TARGET /var/www/itflow/uploads

/dev/sda /data  ext4   19.5G
/dev/sda[/mysql] /var/lib/mysql
/dev/sda[/itflow-uploads] /var/www/itflow/uploads

The installed schema version:

sudo mariadb --protocol=socket -uroot -N -e "SELECT CONCAT('ITFlow database schema ', config_current_database_version) FROM itflow.settings"

ITFlow database schema 2.4.4

Installing your own TLS certificate

The self signed certificate keeps traffic encrypted from the first second, but browsers will warn about it. Once your VM has a public DNS name, replace it.

To use a certificate you already hold, copy the certificate and key onto the VM and point Apache at them. The Apache configuration already reads these two paths, so replacing their contents is all that is needed:

sudo cp <your-domain>.crt /etc/ssl/cloudimg/itflow.crt
sudo cp <your-domain>.key /etc/ssl/cloudimg/itflow.key
sudo chown root:root /etc/ssl/cloudimg/itflow.key
sudo chmod 0600 /etc/ssl/cloudimg/itflow.key
sudo apache2ctl configtest
sudo systemctl restart apache2

To use Let's Encrypt, point a DNS A record at the VM, open port 80, then:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-apache
sudo certbot --apache -d <your-domain>

Certbot writes its own certificate paths into the Apache configuration and renews automatically. After either route, set $config_base_url to the same hostname as in Step 6 so emailed links match the certificate.

Backing up

Everything that matters is the MariaDB database plus the uploads tree, and both are on /data. The simplest protection is an Azure snapshot of the data disk. For a logical dump of the database:

sudo mariadb-dump --protocol=socket -uroot --single-transaction itflow > ~/itflow-backup.sql

ITFlow also has a backup feature in the admin area that packages the database and uploads together.

Security notes

• No credential ships in the image. ITFlow is installed on your instance at first boot, so there is no default account, no shipped password hash and no database in the image to inherit one from.
• HTTPS only. ITFlow refuses to present a sign in form over plain HTTP, and this image honours that: port 443 serves the product, port 80 only redirects, and the session cookie is marked Secure and HttpOnly.
• The credential vault is bound to your password. The site encryption key is sealed with a key derived from the administrator password, so database access alone does not reveal stored client credentials.
• MariaDB is loopback only. It listens on 127.0.0.1:3306 and is not reachable from outside the VM.
• The installer is gone. The web installation wizard is deleted from the web root, not merely disabled.
• No PHP execution in the uploads tree. Client documents and ticket attachments land in a writable directory, so the web server is configured to refuse to execute anything from it.
• Scheduled jobs are not web reachable. They run from a systemd timer via the PHP command line interface.
• No telemetry. The appliance is installed with telemetry off and does not phone home. Opting in stays your choice, in the admin settings.
• Restrict inbound 443 and 22 to the networks that need them, and replace the self signed certificate before exposing ITFlow to clients.

Trademark

ITFlow is a trademark of its respective owners. cloudimg is not affiliated with, endorsed by, or sponsored by the ITFlow project. This image packages the unmodified open source ITFlow release, which is distributed under the GNU General Public License version 3, together with cloudimg's configuration and hardening. The ITFlow name is used here solely to identify the software included in this image.

Support

cloudimg provides 24/7 technical support for this image by email (support@cloudimg.co.uk) and live chat, with a one hour average response time for critical issues. We help with deployment, TLS certificate installation, mail and ticket parsing setup, the client portal, invoicing and recurring billing, upgrades, backup and restore, and MariaDB administration.