Open Web Analytics

Prerequisites

• An active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.
• Standard_B2s (2 vCPU, 4 GiB RAM) is a sensible starting point. Move up to Standard_D2s_v3 for high-traffic sites.
• Network security group inbound rules: allow 22/tcp from your management network, 80/tcp for the application, and 443/tcp if you terminate TLS on the VM.
• Port 3306 stays off the network, because the bundled MariaDB listens on 127.0.0.1 only.

Step 1 - Deploy from the Azure Marketplace

In the Azure portal, choose Create a resource. Search for Open Web Analytics on Ubuntu 24.04 LTS by SecureAnyCloud, and select Create.

Pick your subscription, resource group and region, and choose the Standard_B2s size. Select SSH public key authentication with the username azureuser, and allow inbound ports 22, 80 and 443.

Step 2 - Deploy from the Azure CLI

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

Then open ports 80 and 443:

az vm open-port --resource-group <your-rg> --name open-web-analytics --port 80,443

Step 3 - Confirm the services are running

SSH to the VM as azureuser and confirm that Apache, MariaDB and the first-boot service are all active. MariaDB is bound to 127.0.0.1:3306 only, while Apache serves on port 80.

systemctl is-active apache2 mariadb open-web-analytics-firstboot

ss -tlnp | grep -E ':80 |:3306 ' | sed 's/ */ /g'

Step 4 - Retrieve the per-VM administrator password

The first-boot service generates an administrator password unique to your VM and writes it to a root-only file. Read the file over SSH:

sudo cat /root/open-web-analytics-credentials.txt

OPEN_WEB_ANALYTICS_URL is the VM's own address as seen from inside the VM. Azure does not expose the public IP to the instance, so this is usually the private address.

Browsing the public IP shown in the Azure portal works identically. The image derives OWA's public URL from the request rather than baking one in at build time.

Step 5 - Sign in

Browse to http://<vm-ip>/ and sign in with the username admin and the password from the credentials file.

You land on the analytics Dashboard. It shows the site metrics chart with visits, unique visitors, page views, average visit duration, bounce rate and pages per visit. It also shows the top content, visitor types and traffic sources for the selected period.

Step 6 - Explore your reports

Use the sidebar to move between the report families:

• Content covers top pages, entry and exit pages, and page types.
• Visitors covers loyalty, recency, geolocation, browsers and operating systems.
• Traffic covers referring sites, search engines, keywords and campaigns.
• Action Tracking covers the actions you define.

Each report has its own date range picker and a live view toggle. The Top Pages report below breaks every tracked URL down by page views, visits and unique page views.

Step 7 - Track your own website

The image ships with a default site, so the dashboard works immediately. To track your own website, open Settings. Either edit the default site's domain or add a new site, and then open its Tracking Tag page.

Copy the generated JavaScript snippet into the HTML of your pages, just before the closing </body> tag. OWA starts recording visits straight away. A PHP tracker and a REST tracking API are also available for server-side tracking.

Step 8 - No known or default credentials

This image ships with no usable login. The administrator password created at build time is rotated to a random value that is discarded and never recorded.

Before OWA serves a single request, the first-boot service sets a fresh password unique to your VM, regenerates the application secrets and rotates the database password. The admin account is the only account that can sign in. The check below confirms that the per-VM password authenticates through the real OWA login form, while a blank password and common weak guesses are all rejected.

sudo mariadb --protocol=socket -uroot -N -e "SELECT CONCAT(user_id,' (the only account that can sign in)') FROM owa.owa_user"

sudo bash /usr/local/sbin/open-web-analytics-cred-roundtrip.sh

After you sign in for the first time, change the administrator password to one of your own under the OWA user settings.

Step 9 - Verify the stack

Confirm the installed release, the health endpoint and that the analytics engine is recording:

php -r "require '/var/www/owa/owa_env.php'; echo 'Open Web Analytics '.OWA_VERSION;"

curl -sI http://127.0.0.1/healthz | head -1

sudo mariadb --protocol=socket -uroot -N -e "SELECT CONCAT((SELECT COUNT(*) FROM owa.owa_session),' visits, ',(SELECT COUNT(*) FROM owa.owa_request),' page views across ',(SELECT COUNT(*) FROM owa.owa_document),' pages') AS tracked"

Adding your own domain and TLS

Open Web Analytics derives its public URL from the request. Pointing a DNS name at the VM is all you need for the tracking snippet and links to use that name, and no configuration change is required.

To terminate TLS on the VM itself, install a certificate with Certbot:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-apache
sudo certbot --apache -d analytics.your-domain.com

Certbot configures the Apache virtual host and renews the certificate automatically. OWA switches its generated snippet and links to https:// on its own once requests arrive over TLS.

To pin one fixed public URL instead of following the request, replace the SecureAnyCloud host-derived block in /var/www/owa/owa-config.php with a single line, for example define('OWA_PUBLIC_URL', 'https://analytics.your-domain.com/');.

Backing up

Everything that matters lives in the MariaDB database. Dump the database, and snapshot the OS disk from the Azure portal for a complete point-in-time backup:

sudo mariadb-dump --protocol=socket -uroot --single-transaction --routines owa > /var/tmp/owa-backup.sql

Security notes

• The administrator password is unique to every VM. First boot generates it into a 0600 root:root file, alongside a rotated database password and freshly generated application secrets. No default or shared login ships in the image.
• The image ships a clean, empty analytics dataset. The demo traffic used to validate the build is removed before capture.
• The install and CLI entrypoints are denied from the web: /install.php and /cli.php return 403, and owa-config.php is never web-readable.
• MariaDB listens on 127.0.0.1:3306 only and is never reachable from the network. On-box maintenance uses sudo mariadb as root@localhost over the unix socket, with no password.
• The session cookie is host-only, so it is scoped to exactly the address you browse to.
• The OS is fully patched at build time, and unattended security upgrades stay enabled on your VM.
• Restrict 22/tcp to your management network, and put the site behind TLS before you collect production traffic.

Trademark

Open Web Analytics is a trademark of its respective owner. SecureAnyCloud is not affiliated with or endorsed by the Open Web Analytics project. All product and company names are trademarks or registered trademarks of their respective holders.

Support

SecureAnyCloud provides 24/7 technical support for this image by email (sales@secureanycloud.com) and live chat. The average response time for critical issues is one hour.

Deploy on Azure

Launch Open Web Analytics on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Connecting to your instance

Connect over SSH on port 22 using the private key for the key pair you selected at launch. On Ubuntu 24.04, the SSH login user is ubuntu.

ssh -i /path/to/your-key.pem ubuntu@<instance-public-ip>

Prerequisites

• An AWS account, an EC2 key pair, and a VPC subnet.
• m5.large (2 vCPU, 8 GB RAM) is the recommended instance type and is sufficient for low to medium traffic. Move to an m5.xlarge or larger for high-traffic sites or many tracked properties.
• A security group that allows inbound TCP 80 from the addresses that should reach the dashboard and send tracking requests, and TCP 22 for administration. To serve HTTPS later, also allow TCP 443.

Step 1 - Launch from AWS Marketplace

In the AWS Marketplace console, find Open Web Analytics by SecureAnyCloud. Choose Continue to Subscribe, then Continue to Configuration, then Continue to Launch.

Pick your Region, the m5.large instance type, your VPC subnet and your key pair. Choose a security group that allows inbound ports 22 and 80.

Step 2 - Launch from the EC2 CLI

aws ec2 run-instances \
  --image-id <ami-id-from-the-listing> \
  --instance-type m5.large \
  --key-name your-key \
  --security-group-ids sg-xxxxxxxx \
  --subnet-id subnet-xxxxxxxx \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=open-web-analytics}]'

Step 3 - Confirm the services are running

Both services that back Open Web Analytics should report active, and the application should answer HTTP 200. MariaDB listens on 127.0.0.1:3306 only, so the database is never exposed to the network:

for s in apache2 mariadb; do echo "$s -> $(systemctl is-active "$s")"; done ss -tlnH | awk '{print $4}' | grep -E ':80$|:3306$' curl -s -o /dev/null -w 'healthz -> HTTP %{http_code}\n' http://127.0.0.1/healthz curl -s -o /dev/null -w 'login -> HTTP %{http_code}\n' -L http://127.0.0.1/index.php

Expected: apache2 -> active, mariadb -> active, the two listening sockets (127.0.0.1:3306 and *:80), healthz -> HTTP 200, and login -> HTTP 200.

Step 4 - Retrieve your administrator credentials

On the first boot of every instance, a one-shot service (open-web-analytics-firstboot.service) generates credentials that are unique to that instance. These are a fresh MariaDB application password, fresh application nonce and authentication secrets, and a fresh Open Web Analytics administrator password. No shared or default credential ships in the image.

sudo stat -c '%a %U:%G %n' /root/open-web-analytics-credentials.txt
sudo awk -F= '/^OPEN_WEB_ANALYTICS_ADMIN_USER=/{print} /^OPEN_WEB_ANALYTICS_URL=/{print}' /root/open-web-analytics-credentials.txt

The file is mode 0600 and owned by root, so only root can read it. It contains the dashboard URL, the administrator username (admin) and password, and the database credentials. Read the administrator password with sudo cat /root/open-web-analytics-credentials.txt.

You can prove that the database credentials authenticate, and that a wrong password is rejected, from the instance's own shell without printing any secret:

DB_USER=$(sudo awk -F= '$1=="MARIADB_USER"{print $2}' /root/open-web-analytics-credentials.txt)
DB_PASS=$(sudo awk -F= '$1=="MARIADB_PASSWORD"{print $2}' /root/open-web-analytics-credentials.txt)
DB_NAME=$(sudo awk -F= '$1=="MARIADB_DATABASE"{print $2}' /root/open-web-analytics-credentials.txt)
OK=$(sudo mariadb -h 127.0.0.1 -u "$DB_USER" -p"$DB_PASS" -D "$DB_NAME" -N -B -e 'SELECT 1' 2>/dev/null || sudo mariadb -u "$DB_USER" -p"$DB_PASS" -D "$DB_NAME" -N -B -e 'SELECT 1' 2>/dev/null || true)
BAD=$(sudo mariadb -h 127.0.0.1 -u "$DB_USER" -p'wrong-password' -D "$DB_NAME" -N -B -e 'SELECT 1' 2>/dev/null || true)
echo "correct password -> ${OK:-rejected}"
echo "wrong password -> ${BAD:-rejected}"

Expected: correct password -> 1 and wrong password -> rejected.

Step 5 - Sign in

Browse to http://<instance-public-ip>/ and sign in with the username admin and the password from the credentials file.

You land on the Sites Roster. It lists the tracked web sites with their visits, page views and bounce rate, and links to view reports, edit the profile or get the tracking code.

The image does not bake an address into the configuration. OWA derives its public URL from the incoming request. The dashboard, the tracking snippet and every absolute link therefore answer correctly on the instance's public address, its private address, or a custom domain you point at it later, with no reconfiguration. You can check this yourself:

curl -s -o /dev/null -w 'custom host -> HTTP %{http_code}\n' -H 'Host: analytics.mydomain.test' http://127.0.0.1/index.php
PAGE=$(curl -s -H 'Host: analytics.mydomain.test' 'http://127.0.0.1/index.php?owa_do=base.loginForm')
echo "$PAGE" | grep -qi 'analytics.mydomain.test' && echo 'host-derived: OWA emitted absolute URLs for the request host' || echo 'host-derived: not found'

Expected: an HTTP status for the custom host and host-derived: OWA emitted absolute URLs for the request host.

Step 6 - Explore the reports

Choose View Reports for your site to open the dashboard. The Site Metrics chart plots visits over time. The metric cards summarise visits, unique visitors, page views and average visit duration, with a Top Content table beneath.

The left navigation groups the reports into Content, Action Tracking, Visitors, Traffic and Goals. The Web Pages report, for example, breaks down page views, visits and unique page views for each page.

Step 7 - Settings

Open Settings to see the general configuration options for the platform and to confirm the installed version.

Step 8 - Confirm the version and the locked-down entrypoints

The install wizard and the command-line entrypoint are completed in advance and denied from the web, so they return HTTP 403. The configuration file, which holds the application's database password, is denied too:

awk -F"'" '/define\(.OWA_VERSION./{print "OWA " $4}' /var/www/owa/owa_env.php php -v | head -1 for p in /install.php /cli.php /owa-config.php; do echo "$p -> HTTP $(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1$p)"; done

Expected: OWA 1.8.2, a PHP 8.3 line, and HTTP 403 for /install.php, /cli.php and /owa-config.php.

Step 9 - Confirm the security model

A round-trip check confirms that the per-instance administrator authenticates through the real web login form and that blank and common weak passwords are all rejected. It also checks that the first-boot sentinel exists, which confirms first boot completed, and that MariaDB is bound to loopback only:

sudo bash /usr/local/sbin/open-web-analytics-cred-roundtrip.sh
sudo test -f /var/lib/sac/data/open-web-analytics-firstboot.done && echo 'sentinel present - first boot completed' ss -tlnH 'sport = :3306' | awk '{print "mariadb listening on " $4}'

Expected: OK per-VM administrator authenticates via the web login form; blank + weak guesses rejected, sentinel present - first boot completed, and mariadb listening on 127.0.0.1:3306.

Step 10 - Add your site and install the tracking snippet

Open Web Analytics ships with one default site already created. To track your own site, choose Reporting, then Add New, or edit the default site. Give the site a domain and a name, and then choose Get Tracking Code.

Copy the generated JavaScript snippet into your site's HTML before the closing </body> tag. You can also use the WordPress, MediaWiki or PHP tracker documented in the OWA wiki. As soon as the snippet is in place, visits appear in the reports.

First-boot service and security model

open-web-analytics-firstboot.service is a one-shot unit ordered After=network-online.target mariadb.service. On the first boot of each instance, it does the following:

• Rotates the application database password in lock step with the MariaDB grant, then re-authenticates to prove it.
• Regenerates the four OWA nonce and authentication secrets.
• Sets the administrator password to a fresh per-instance random value.
• Writes the credentials file at mode 0600.
• Drops a sentinel at /var/lib/sac/data/open-web-analytics-firstboot.done so the service runs exactly once.

The service resolves the instance's public address through EC2 IMDSv2 for the credentials-file URL, and falls back to the private address.

Because every secret is generated on your own instance, no two SecureAnyCloud deployments of this image share a credential, and nothing sensitive exists in the published image. The image ships a clean, empty analytics dataset. The demo data used to prepare the screenshots above is removed before capture.

Using your own domain and HTTPS

The image serves plain HTTP on port 80 so that it works immediately on any address. For production, point your domain at the instance and terminate TLS. The quickest route is Certbot with the Apache plugin:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-apache
sudo certbot --apache -d analytics.your-domain.com

Because no address is baked into the configuration, OWA starts answering on your domain as soon as DNS resolves. It emits the tracking snippet and absolute links for that domain, and there is nothing to reconfigure. It also switches to https:// automatically once a certificate is in front of it.

Alternatively, place an Application Load Balancer with an AWS Certificate Manager certificate in front of the instance.

Administration from the command line

MariaDB root uses socket authentication, so on-box database maintenance needs no password:

sudo mariadb

To reset the administrator password from the shell, temporarily lift the command-line lockdown, run OWA's own command, and then restore the lockdown:

sudo a2disconf sac-owa-lockdown && sudo systemctl reload apache2
sudo -u www-data php /var/www/owa/cli.php cmd=change-password user=admin password='your-new-password'
sudo a2enconf sac-owa-lockdown && sudo systemctl reload apache2

Keeping Open Web Analytics up to date

Open Web Analytics is pinned to the version verified at build time, so the image you launched is the image that runs. To upgrade, download the newer packaged release into /var/www/owa and keep your owa-config.php. Then run the schema update from the OWA dashboard or CLI. Always take a backup first, and test the upgrade outside production.

Backup and maintenance

Back up the database and the application configuration:

sudo mariadb-dump --single-transaction owa > /var/backups/owa-$(date +%F).sql
sudo cp /var/www/owa/owa-config.php /var/backups/owa-config-$(date +%F).php

The operating system receives unattended security upgrades. The two data tiers each use their own EBS volume (/var/lib/mysql and /var/www), so you can snapshot and resize each one independently.

Licensing

Open Web Analytics is distributed under the GNU General Public License, version 2 (GPL-2.0). The licence text ships in the image at /var/www/owa/LICENCE. SecureAnyCloud charges only for the packaging, maintenance and support of the image. The software itself remains under its open-source licence.

Support

Every SecureAnyCloud image includes 24/7 support. Contact sales@secureanycloud.com with your AWS account ID and the instance ID.

Deploy on AWS

Launch Open Web Analytics with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com