IDURAR ERP CRM

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for IDURAR ERP CRM 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 HTTP (80). Then select Review + create, and then Create.

To deploy with the Azure CLI instead of the portal, run the following commands:

RG="idurar-prod"; LOCATION="eastus"; VM_NAME="idurar-01" IMAGE_URN="sac1647283583153:idurar-erp-crm-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name idurar-vnet --address-prefix 10.100.0.0/16 --subnet-name idurar-subnet --subnet-prefix 10.100.1.0/24 az network nsg create -g "$RG" --name idurar-nsg az network nsg rule create -g "$RG" --nsg-name idurar-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name idurar-nsg --name allow-http --priority 110 \
  --destination-port-ranges 80 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:idurar-erp-crm-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name idurar-vnet --subnet idurar-subnet --nsg idurar-nsg --public-ip-sku Standard

Connect over SSH as azureuser, then confirm that all four units are active. idurar-firstboot.service is a one-shot unit that reports active after it completes successfully.

systemctl is-active mongod nginx idurar idurar-firstboot

Expected output:

active active active active

Check the installed release and confirm that the console answers:

cat /var/lib/sac/data/idurar-version curl -s -o /dev/null -w 'IDURAR web console: HTTP %{http_code}\n' http://127.0.0.1/

Expected output:

idurar.tag=4.1.0 idurar.package_json=4.1.0 idurar.tarball_sha256=556e732f03f5292a6e0f0d7789660f4e9213b0fd0f5fe9d7d04504e07ec1afaa phantomjs.version=2.1.1 node.version=v22.23.1 IDURAR web console: HTTP 200

The first boot generates every secret on this VM, and the secrets exist nowhere else. The image writes them to a root-only file.

sudo cat /root/idurar-credentials.txt

Only root can read the file. Confirm this yourself:

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

Expected output:

/root/idurar-credentials.txt mode=600 owner=root:root

Copy the administrator email and password into your password manager now, then continue.

Browse to http://<your-vm-public-ip>/. The IDURAR sign-in page appears. Enter the idurar.admin.email and idurar.admin.password values from the credentials file.

You can verify the same credentials from the command line before you open a browser. The command reads the generated password straight from the credentials file, so there is nothing to paste:

ADMIN_EMAIL="$(sudo grep '^idurar.admin.email=' /root/idurar-credentials.txt | cut -d= -f2-)" ADMIN_PASSWORD="$(sudo grep '^idurar.admin.password=' /root/idurar-credentials.txt | cut -d= -f2-)" curl -s -X POST http://127.0.0.1/api/login \
  -H 'Content-Type: application/json' \
  -d "{\"email\":\"${ADMIN_EMAIL}\",\"password\":\"${ADMIN_PASSWORD}\"}" \
  | jq '{success, email: .result.email, role: .result.role}'

Expected output:

{ "success": true, "email": "admin@example.com", "role": "owner" }

After you sign in, you land on the dashboard, which summarizes invoices, quotes and customers for the current month.

The administrator email is a documented sample value, not a secret. Change it to a real address that you control, and set your own password. Use Settings in the console sidebar or the profile menu at the top right. Do this before you invite anyone else.

The core workflow is Customers > Quote > Invoices > Payments. Add a customer from Customers > Add New Client. Then raise an invoice from Invoices > Add New Invoice: choose that customer, add line items, and select a tax rate.

You can do the same over the API. The following commands create a customer and an invoice, then read back the calculated totals:

ADMIN_EMAIL="$(sudo grep '^idurar.admin.email=' /root/idurar-credentials.txt | cut -d= -f2-)" ADMIN_PASSWORD="$(sudo grep '^idurar.admin.password=' /root/idurar-credentials.txt | cut -d= -f2-)" TOKEN="$(curl -s -X POST http://127.0.0.1/api/login -H 'Content-Type: application/json' \
  -d "{\"email\":\"${ADMIN_EMAIL}\",\"password\":\"${ADMIN_PASSWORD}\"}" | jq -r .result.token)" CLIENT_ID="$(curl -s -X POST http://127.0.0.1/api/client/create \
  -H "Authorization: Bearer ${TOKEN}" -H 'Content-Type: application/json' \
  -d '{"name":"Example Customer Ltd","country":"United Kingdom","email":"accounts@example.com"}' \
  | jq -r .result._id)" curl -s -X POST http://127.0.0.1/api/invoice/create \
  -H "Authorization: Bearer ${TOKEN}" -H 'Content-Type: application/json' \
  -d "{\"client\":\"${CLIENT_ID}\",\"number\":5001,\"year\":$(date -u +%Y),\"status\":\"draft\",\"date\":\"$(date -u +%Y-%m-%d)\",\"expiredDate\":\"$(date -u -d '+30 days' +%Y-%m-%d)\",\"taxRate\":20,\"items\":[{\"itemName\":\"Consulting\",\"description\":\"Example line item\",\"quantity\":2,\"price\":500,\"total\":1000}]}" \
  | jq '{success, number: .result.number, subTotal: .result.subTotal, taxTotal: .result.taxTotal, total: .result.total}'

Expected output:

{ "success": true, "number": 5001, "subTotal": 1000, "taxTotal": 200, "total": 1200 }

Open any invoice and choose Download PDF. The document is rendered on the VM by PhantomJS.

HTTP offers the same download. The download path is /download/invoice/invoice-<invoice-id>.pdf:

ADMIN_EMAIL="$(sudo grep '^idurar.admin.email=' /root/idurar-credentials.txt | cut -d= -f2-)" ADMIN_PASSWORD="$(sudo grep '^idurar.admin.password=' /root/idurar-credentials.txt | cut -d= -f2-)" TOKEN="$(curl -s -X POST http://127.0.0.1/api/login -H 'Content-Type: application/json' \
  -d "{\"email\":\"${ADMIN_EMAIL}\",\"password\":\"${ADMIN_PASSWORD}\"}" | jq -r .result.token)" INVOICE_ID="$(curl -s http://127.0.0.1/api/invoice/list -H "Authorization: Bearer ${TOKEN}" | jq -r '.result[0]._id')" curl -s -o /tmp/invoice.pdf -w 'invoice PDF: HTTP %{http_code}, %{size_download} bytes\n' \
  "http://127.0.0.1/download/invoice/invoice-${INVOICE_ID}.pdf" file /tmp/invoice.pdf

Expected output:

invoice PDF: HTTP 200, 70693 bytes /tmp/invoice.pdf: PDF document, version 1.4, 1 page(s)

Verify these three properties yourself.

cd /opt/idurar/backend && echo "administrator accounts: $(sudo node sac-admin.js count)" curl -s -o /dev/null -w 'upstream default credential -> HTTP %{http_code}\n' \
  -X POST http://127.0.0.1/api/login -H 'Content-Type: application/json' \
  -d '{"email":"admin@admin.com","password":"admin123"}' curl -s -o /dev/null -w 'anonymous API request -> HTTP %{http_code}\n' http://127.0.0.1/api/client/list

Expected output:

administrator accounts: 1 upstream default credential -> HTTP 404 anonymous API request -> HTTP 401

• One account, no default. The upstream project's setup routine creates admin@admin.com with the password admin123. The build deletes that account and fails if any account survives, so it does not exist in this image. Your VM's single administrator was created on first boot with a random password.
• No self-service sign-up. IDURAR exposes no registration route at all, so a passer-by cannot enroll on a public instance. The administrator adds new users from the console.
• The API and the database are private. The Express API listens on 127.0.0.1:8888 and MongoDB on 127.0.0.1:27017. Only nginx on port 80 is reachable from the network. Confirm with:

ss -tlnp 2>/dev/null | awk 'NR==1 || /:80 |:8888 |:27017 /' | sed 's/users:.*//'

One caveat. Upstream mounts the PDF download route outside its authentication middleware, so anyone who knows an invoice's identifier can fetch that invoice's PDF without signing in. This is upstream behavior, not something this image introduces. Do not expose port 80 to the public internet without the TLS and access restrictions in Step 10.

The image serves plain HTTP on port 80 so that it works immediately at any address. For anything beyond a trial, terminate TLS with your own certificate and restrict access with a network security group.

Point a DNS A record at the VM's public IP, allow 443/tcp in the NSG, then install a certificate. Replace the example values with your own:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain> -m <your-email> --agree-tos --redirect

The admin console calls the API on the same origin using relative paths, so you need no rebuild or reconfiguration when you move to a hostname or to HTTPS. It works at the new address.

All business data lives in the idurar MongoDB database. Take a dump with the application credentials from the credentials file:

MONGO_APP_PASSWORD="$(sudo grep '^mongo.app.password=' /root/idurar-credentials.txt | cut -d= -f2-)" sudo mkdir -p /var/backups/idurar
sudo mongodump --host 127.0.0.1 --port 27017 \
  -u idurar -p "${MONGO_APP_PASSWORD}" --authenticationDatabase idurar \
  --db idurar --out /var/backups/idurar/$(date -u +%Y%m%d)

Uploaded files (customer logos and attachments) live outside the database, so back them up too:

sudo mkdir -p /var/backups/idurar
sudo tar czf /var/backups/idurar/uploads-$(date -u +%Y%m%d).tar.gz \
  -C /opt/idurar/backend/src/public uploads

To restore, run mongorestore with the same credentials and untar the uploads back into place.

MongoDB is deliberately not reachable from the network. To use a graphical client from your workstation, forward the port over SSH:

ssh -N -L 27017:127.0.0.1:27017 azureuser@<vm-ip>

Then connect to mongodb://127.0.0.1:27017 using the mongo.admin.user and mongo.admin.password values from the credentials file, with admin as the authentication database.