REI3

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 sensible starting size. Choose a larger size for many concurrent users or large applications.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 443/tcp so your browser can reach REI3. Also allow 80/tcp if you want the automatic redirect from http:// to work.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for REI3 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), HTTPS (443) and HTTP (80).

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:rei3-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name rei3 \
  --image sac1647283583153:rei3-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open the web ports so your browser can reach REI3:

az vm open-port --resource-group <your-rg> --name rei3 --port 443 --priority 1001
az vm open-port --resource-group <your-rg> --name rei3 --port 80 --priority 1002

Step 3 - Confirm the services are running

SSH in as azureuser. First boot creates this VM's PostgreSQL role and database, builds the REI3 schema, creates your administrator, deletes REI3's seeded default account and generates this VM's TLS certificate. It completes in well under a minute, after which REI3 listens on :443.

systemctl is-active postgresql rei3 nginx nftables

systemctl show -p Result -p ActiveState --value rei3-firstboot.service

REI3 serves HTTPS itself on :443. nginx exists only to redirect :80 to it. PostgreSQL is bound to loopback and is never exposed to the network.

ss -tlnH | awk '{print $4}' | sort -u

Step 4 - Confirm no default credential shipped

Run this check on any appliance that has a documented default login. REI3's initialiser seeds an admin / admin account whenever it meets an empty database. First boot deletes it, so exactly one account exists on your VM and it is yours.

sudo -u postgres psql -tAc "SELECT count(*) FROM instance.login" rei3

sudo -u postgres psql -tAc "SELECT count(*) FROM instance.login WHERE name='admin'" rei3

The second command must print 0. You can also confirm it against the live login endpoint, which refuses the published default:

curl -ks -o /dev/null -w 'admin/admin -> HTTP %{http_code}\n' -X POST \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"admin"}' https://127.0.0.1/api/auth

Step 5 - Review the host firewall

The image ships a default-drop nftables ruleset. PostgreSQL therefore stays a same-box dependency, even if you later widen the network security group.

sudo nft list ruleset | sed -n '/chain input/,/}/p'

Step 6 - Retrieve this VM's administrator credentials

First boot writes them to a root-only file. The file records the sign-in URL, your administrator login and password, and the PostgreSQL credentials REI3 uses.

sudo stat -c '%n mode %a owner %U:%G' /root/rei3-credentials.txt

sudo grep -E '^(REI3_URL|rei3\.admin\.login)=' /root/rei3-credentials.txt

Read the whole file, including the password:

sudo cat /root/rei3-credentials.txt

Confirm that the password authenticates. This command posts to REI3's own login endpoint and checks the response body, not just the status line:

CODE=$(curl -ks -o /tmp/rei3-auth.json -w '%{http_code}' -X POST \
  -H 'Content-Type: application/json' \
  -d '{"username":"<REI3_ADMIN_LOGIN>","password":"<REI3_ADMIN_PASSWORD>"}' \
  https://127.0.0.1/api/auth)
echo "per-VM administrator -> HTTP ${CODE}" test "${CODE}" = "200" || {
echo "ERROR: the per-VM administrator did not authenticate"; exit 1; } grep -q '"token"' /tmp/rei3-auth.json || {
echo "ERROR: no session token in the response"; exit 1; }
echo "OK: authenticated and received a session token" rm -f /tmp/rei3-auth.json

A wrong password is refused:

curl -ks -o /dev/null -w 'wrong password -> HTTP %{http_code}\n' -X POST \
  -H 'Content-Type: application/json' \
  -d '{"username":"<REI3_ADMIN_LOGIN>","password":"DefinitelyNotThePassword123"}' \
  https://127.0.0.1/api/auth

Step 7 - Sign in to REI3

Browse to https://<your-vm-public-ip>/ and sign in with the login and password from Step 6. REI3 serves HTTPS with a certificate generated on this VM's first boot for this VM's own addresses.

The certificate is self-signed, so your browser warns you the first time. This is expected on a freshly deployed appliance. Step 11 shows how to install your own certificate.

A new instance starts in maintenance mode, which is REI3's normal state for a system that has not been set up yet. Administrators can sign in and use the Builder, and everyone else is held out until you are ready. Step 10 switches the instance to production mode.

Step 8 - Install your first applications

A new instance has no applications yet. REI3 offers three ways to get started: install the ready-made Core Company set, install individual modules from the repository, or import an application from a file.

Core Company is the fastest way to see the platform doing real work. It installs a connected set of business applications: absence management, time tracking, projects and tasks, ticketing, a password safe, IT asset management and an organisation directory. Choose Install Core Company and allow a minute or so for it to download and build its schema.

Once installed, the home page lists your applications grouped by area. The platform version is shown in the corner.

Step 9 - Give your account access, then use an application

REI3 separates installing an application from being allowed to use it, so a freshly installed module is not visible to anyone until roles are assigned.

Open Administration (the icon by your user name), then Memberships. Pick a role from the list at the top, add your user to it, and choose Save. Repeat for each application you want access to.

Back on the home page, the applications are now open to you. Choose Tasks, then New, to open a real form with a title, rich-text description, deadline, priority, progress, state, owner and file attachments. Saving it writes a row to PostgreSQL that immediately appears in the list.

Every record you create is an ordinary row in an ordinary PostgreSQL table on this VM. Confirm it directly:

sudo -u postgres psql -tAc \
  "SELECT count(*) FROM pg_tables WHERE schemaname NOT IN ('pg_catalog','information_schema')" rei3

Step 10 - Administration and production mode

Administration shows the platform version, the update state, this VM's public hostname, the password policy, session lifetime, email accounts, backups, logs and the scheduler. The public hostname is set to your VM's address on first boot, so the links REI3 generates point at the right place.

When you have finished setting up the system, turn Maintenance mode off to put the instance into production mode so your users can sign in. Add those users under Users, and grant them application access under Memberships, as in Step 9.

Confirm that the public hostname points at this VM:

sudo -u postgres psql -tAc \
  "SELECT value FROM instance.config WHERE name='publicHostName'" rei3

Step 11 - Install your own TLS certificate

REI3 reads its certificate and key from /opt/rei3/data/certificates/. The shipped pair is generated on first boot for this VM and is self-signed.

To use your own certificate, copy the PEM-encoded certificate and key over cert.crt and cert.key. Keep them owned by the rei3 user, then restart the service:

sudo install -o rei3 -g rei3 -m 0644 /path/to/fullchain.pem /opt/rei3/data/certificates/cert.crt
sudo install -o rei3 -g rei3 -m 0640 /path/to/privkey.pem /opt/rei3/data/certificates/cert.key
sudo systemctl restart rei3

Confirm the certificate that the running server presents:

sudo openssl x509 -in /opt/rei3/data/certificates/cert.crt -noout -subject -ext subjectAltName

Step 12 - Check persistence and hardening

The stack is enabled to return after a reboot, the credentials file is root-only, and no swap is baked into the OS disk (an Azure image requirement). Unattended security upgrades keep the base operating system patched.

systemctl is-enabled postgresql rei3 nginx nftables rei3-firstboot

swapon --show | wc -l

apt-mark showhold | wc -l

Both counts must be 0: no swap devices, and no packages held back from security updates.

Step 13 - Back up and maintain your VM

REI3 has an integrated backup feature under Administration, then Backups. It uses the PostgreSQL client tools shipped in this image. Set a target directory and a schedule there.

For VM-level protection, take Azure snapshots or use Azure Backup on the OS disk. This captures the database, your applications and their data together.

To back up the database by hand, run:

sudo -u postgres pg_dump -Fc rei3 > /var/backups/rei3-$(date +%F).dump

The base operating system applies security updates automatically through unattended upgrades. To move to a newer REI3 release, take a database backup first, then follow the upstream upgrade notes at rei3.de.

Security notes

• No default credential ever exists on your VM. REI3's documented admin / admin account is created by its own initialiser against an empty database and is deleted during first boot, before the service is reachable. Step 4 proves it is gone.
• Every secret is unique to your VM. The administrator password, the PostgreSQL role password, REI3's internal token-signing secret and the TLS private key are all generated on your VM's first boot. Nothing is baked into the image.
• The instance is not reachable until it is secured. rei3.service will not start until first boot has written its bootstrap marker, so an unprovisioned REI3 can never come up and seed a default account ahead of it.
• PostgreSQL is not on the network. It listens on loopback and the default drop firewall does not open 5432.
• Restrict SSH and use your own certificate. Limit 22/tcp to your management network, and install your own certificate (Step 11) before exposing REI3 to the internet.
• Change the administrator password. Do this from the user menu after your first sign-in, and set your password policy under Administration.
• Keep Builder mode off in production. It is a design-time tool.

Architecture summary

Component Detail

REI3 3.12.7, official upstream Linux server binary, MIT licensed

Web interface HTTPS on :443, served by REI3 itself

Port 80 nginx, 301 redirect to HTTPS, proxies nothing

Database PostgreSQL 16 on the same VM, loopback only

Application data Ordinary PostgreSQL tables in the rei3 database

Files and thumbnails /opt/rei3/data/, with ImageMagick and Ghostscript

TLS Self-signed, generated on first boot for this VM's addresses

First boot rei3-firstboot.service: database, administrator, TLS, and deletion of the seeded default account

Credentials /root/rei3-credentials.txt, mode 0600, owner root

Firewall nftables, default drop, allowing 22, 80, 443

Base image Ubuntu 24.04 LTS, patched at build time, unattended security upgrades enabled

Support

SecureAnyCloud provides 24/7 support for this image. Email sales@secureanycloud.com with your VM's region and size, the output of Step 3, and what you were doing when the problem appeared. REI3 product documentation is at rei3.de.

Deploy on Azure

Launch REI3 on Ubuntu 24.04 LTS with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com