MemberMatters

Prerequisites

You need 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 suitable starting size for evaluation and small spaces. Choose a larger size for bigger memberships.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 8000/tcp for the portal. MemberMatters serves plain HTTP on port 8000, so for production put it behind your own domain and TLS.

Step 1 - Deploy from the Azure Marketplace

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

On the Basics tab, 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 add a custom rule for port 8000.

Select Review + create, then Create.

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:membermatters-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name membermatters \
  --image sac1647283583153:membermatters-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name membermatters --port 8000 --priority 1010

Step 3 - Connect to your VM

Connect over SSH as azureuser:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the stack is running

The MemberMatters containers run as a Docker Compose stack managed by a single systemd unit. On first boot the stack rotates every secret, recreates itself on a fresh database, applies migrations and seeds the accounts.

The stack can take a minute or two to become fully healthy after the VM is created. Then run:

systemctl is-active membermatters.service cd /opt/membermatters && sudo docker compose ps

The unit reports active, and every service (mm-webapp, mm-postgres, mm-redis, mm-celery-worker, mm-celery-beat) reports Up.

Step 5 - Retrieve your per-VM credentials

Every VM generates its own admin and demo-member passwords on first boot and records them in a root-only file. Read the file with sudo:

sudo cat /root/membermatters-credentials.txt

The file lists the portal URL, the Django superuser (admin@sac.local), the Django admin URL, and an active demo member (demo@sac.local). Store these credentials somewhere safe and change them after your first sign-in.

Step 6 - Understand first-boot secret rotation

A one-shot membermatters-firstboot.service runs once on the first boot of every VM. It generates a fresh PostgreSQL password and a fresh Django SECRET_KEY, which is also the JWT signing key.

It then wipes the database volume so PostgreSQL initialises clean with the new password, applies migrations, and seeds the superuser and demo member. A sentinel file records that the service has run. To confirm, run:

systemctl is-active membermatters-firstboot.service ls -l /var/lib/sac/data/membermatters-firstboot.done
sudo ls -l /root/membermatters-credentials.txt

Step 7 - Sign in to the member portal

Browse to http://<vm-public-ip>:8000/. The MemberMatters portal opens on a login page.

Sign in with the admin email and password from Step 5. To see the member experience, sign in as the demo member instead.

Step 8 - Explore the member dashboard

After signing in, members land on the dashboard. It shows quick cards to report an issue and to view the events calendar, plus any resource cards your space configures.

Step 9 - Manage your profile

Each member manages their own profile from the account area. The profile covers name, screen name, contact details, digital ID and password.

Step 10 - Manage members as an admin

Sign in as the admin (staff) account and open Manage -> Members. The view lists every member with their subscription and membership status.

From here you can export a CSV or copy the email list. On a fresh VM, the seeded demo member and the admin account are both listed.

Step 11 - Verify the REST API

MemberMatters issues a JWT through POST /api/token/obtain/ and accepts it as a Bearer token on protected endpoints such as /api/profile/. The following round trip proves end-to-end authentication with your per-VM credentials:

EMAIL=$(sudo grep '^membermatters.admin.email=' /root/membermatters-credentials.txt | cut -d= -f2-)
PASSWORD=$(sudo grep '^MEMBERMATTERS_ADMIN_PASSWORD=' /root/membermatters-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -H 'Content-Type: application/json' \
  -d "{\"email\":\"$EMAIL\",\"password\":\"$PASSWORD\"}" \
  http://127.0.0.1:8000/api/token/obtain/ | python3 -c 'import sys,json;print(json.load(sys.stdin)["access"])')
curl -s -o /dev/null -w 'valid token -> HTTP %{http_code}\n' \
  -H "Authorization: Bearer $TOKEN" http://127.0.0.1:8000/api/profile/
curl -s -o /dev/null -w 'bad token -> HTTP %{http_code}\n' \
  -H 'Authorization: Bearer wrong.token.xyz' http://127.0.0.1:8000/api/profile/

A valid token returns HTTP 200. A bad token is rejected with HTTP 401.

Step 12 - Configure integrations (optional)

MemberMatters runs standalone out of the box. No external service is required to sign in or manage members.

When you are ready, enable integrations from the Admin Tools settings in the portal:

• Stripe: recurring membership payments and member-bucks top-ups
• Email (Sendgrid or Postmark) and SMS (Twilio): member notifications
• Door, interlock and tool controllers: physical access control
• OIDC / SSO: MemberMatters can act as an identity provider for other apps

Each integration is configured at runtime and stored in the database. None is baked into the image.

Security notes

• Change the seeded password. Change the admin@sac.local password immediately after your first sign-in, and create your own named staff accounts.
• No default credentials. The per-VM SECRET_KEY, JWT signing key and PostgreSQL password are unique to each VM and generated on first boot. No default credential ships in the image.
• Minimal exposure. Only 22/tcp and 8000/tcp are exposed. PostgreSQL and Redis are reachable only on the internal Docker network.
• Encrypt web traffic. For production, terminate TLS at your own domain in front of port 8000, and restrict SSH to your management network.

Support

SecureAnyCloud images come with 24/7 support. For help deploying or operating MemberMatters on Azure, contact SecureAnyCloud support.

Deploy on Azure

Launch MemberMatters 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