Pleroma

• Open the Azure Marketplace and search for Pleroma on Ubuntu 24.04 LTS by SecureAnyCloud.
• Select Create, and then choose your subscription, resource group and region.
• Pick a VM size of Standard_B2s or larger.
• Under Administrator account, select SSH public key and supply your public key.
• Under Inbound port rules, allow SSH (22) and HTTPS (443).
• Select Review + create, and then select Create.

az group create --name pleroma-rg --location eastus

az vm image terms accept --urn sac1647283583153:pleroma-ubuntu-24-04:default:latest
az vm create \
  --resource-group pleroma-rg \
  --name pleroma-vm \
  --image sac1647283583153:pleroma-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
az vm open-port --resource-group pleroma-rg --name pleroma-vm --port 443 --priority 1010

ssh azureuser@<vm-ip>

Pleroma runs as a systemd service behind nginx, with PostgreSQL on the same VM. Two one-shot units run once on first boot. pleroma-firstboot creates the per-VM secrets and configuration before the server is allowed to start, and pleroma-postboot creates the per-VM administrator once the server is up. Check that the services are active:

systemctl is-active postgresql nginx pleroma

Expected output:

active active active

The Pleroma server listens only on the loopback interface, and nginx is the single public listener on ports 80 (which redirects to HTTPS) and 443. Rather than grepping for the ports you expect, list every socket that is bound to something other than loopback. This way, anything unexpected shows up:

sudo ss -ltn | awk 'NR>1{print $4}' | grep -vE '^(127\.|\[::1\])' | sort -u

The only entries are 22 (SSH) and 80 and 443 (nginx), on both IPv4 and IPv6. Everything else that the image runs is bound to loopback and is not reachable from off the VM. This includes Pleroma itself on 127.0.0.1:4000, PostgreSQL on 127.0.0.1:5432 and the Erlang port mapper on 127.0.0.1:4369.

Because the command lists the full set rather than a filtered subset, you can also run it again after you install anything else on the VM.

Every VM generates its own secrets and administrator on first boot. They are written to a root-only file. Read it with:

sudo cat /root/pleroma-credentials.txt

This file contains:

• WEB_USER and WEB_PASSWORD are the outer HTTP Basic credential that gates anonymous access at the nginx proxy.
• ADMIN_USER, ADMIN_EMAIL and ADMIN_PASSWORD are the per-instance Pleroma administrator account.
• PLEROMA_URL is the HTTPS URL of your instance.

Keep this file safe, and change the passwords once you have logged in.

Pleroma has no published default administrator. Accounts are only ever created explicitly. The security-sensitive values that upstream would otherwise leave you to set are all generated uniquely on the first boot of every VM, before the server is reachable:

• The Phoenix secret_key_base and the session signing salts, which sign and encrypt session cookies
• The web push VAPID keypair and the JWT signer
• The PostgreSQL password
• The per-instance administrator account and password
• A per-instance self-signed TLS certificate
• A per-instance web credential for the nginx gate

The two layers of authentication, the nginx Basic gate and Pleroma's own account login, both use the HTTP Authorization header. The image therefore configures nginx to let authenticated API traffic (which carries a Bearer token) through to Pleroma's own authentication, while it challenges anonymous visitors for the web credential. The web UI, the mobile apps and the API all work normally behind the gate.

You can verify the model end to end with the bundled self-test. It proves that the front door refuses a missing or wrong credential, that a wrong administrator password is rejected, and that a status posted through the real login is read back from the timeline:

sudo /usr/local/sbin/pleroma-roundtrip.sh

Open your instance in a browser:

https://<vm-ip>/

The TLS certificate is self-signed and unique to the VM, so your browser warns once. Accept the warning to continue, or install a CA certificate for a real domain as described below to remove it. You then authenticate in two steps:

• When the browser prompts for the web credential, enter WEB_USER and WEB_PASSWORD from your credentials file.
• On the Pleroma sign-in page, log in as ADMIN_USER with ADMIN_PASSWORD.

After you sign in, you land on your timeline, ready to post.

Write a post in the compose box and publish it. The post appears immediately on your local timeline. Once your instance federates (see below), it is also delivered to your followers on other Fediverse servers.

The same works from any Mastodon-compatible app. Point the app at https://<vm-ip>/ (or your domain), and log in with the administrator account.

Self-registration is closed by default on this image, which is a single-administrator appliance. Create additional accounts, or grant moderator and admin rights, with pleroma_ctl:

# create a regular user (they can log in and post); -y skips the confirmation prompt
sudo -Hu pleroma bash -c 'cd /opt/pleroma && PLEROMA_CONFIG_PATH=/etc/pleroma/config.exs ./bin/pleroma_ctl user new alice alice@example.com --password "$(openssl rand -base64 18)" -y'

To open public registration instead, set registrations_open: true in /etc/pleroma/config.exs and restart Pleroma:

sudo sed -i 's/registrations_open: false/registrations_open: true/' /etc/pleroma/config.exs
sudo systemctl restart pleroma