Ortelius

Search the Azure Marketplace for Ortelius, select the SecureAnyCloud publisher, and select Create.

Choose Standard_B2ms or larger. ArangoDB and a persistent Next.js server benefit from the extra headroom over Standard_B2s.

Configure the Network Security Group to allow TCP 8080 (dashboard) and TCP 3000 (API) from your administrative networks, and TCP 22 for administration. Port 3000 is required because the browser talks to the API directly. ArangoDB stays on loopback and is never exposed.

Run the following to create the network resources, accept the Marketplace terms and create the VM:

RG="ortelius-prod"; LOCATION="eastus"; VM_NAME="ortelius-01" IMAGE_URN="sac1647283583153:ortelius:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name ortelius-vnet --address-prefix 10.93.0.0/16 --subnet-name ortelius-subnet --subnet-prefix 10.93.1.0/24 az network nsg create -g "$RG" --name ortelius-nsg az network nsg rule create -g "$RG" --nsg-name ortelius-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 ortelius-nsg --name allow-dashboard --priority 110 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 8080 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name ortelius-nsg --name allow-api --priority 120 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 3000 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:ortelius:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2ms --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name ortelius-vnet --subnet ortelius-subnet --nsg ortelius-nsg --public-ip-sku Standard

On first boot the image rotates ArangoDB's root password and enables database authentication. It generates this VM's JWT signing key, token-encryption key and administrator password, and starts the API and dashboard. It also adds the ortelius/ortelius repository as a proof-of-life Favorite, and verifies that the new administrator password works and that common defaults are rejected. This completes in seconds.

SSH in as azureuser and read the details:

sudo cat /root/ortelius-credentials.txt

The file is mode 0600 and owned by root, so only a privileged user can read it. It contains the dashboard URL, the API URL, the administrator username and password, and the ArangoDB root password.

All three services should report active. The ss command confirms that the API and dashboard are listening while ArangoDB is bound to loopback only. The Apache-2.0 licence text ships in the image.

systemctl is-active arangodb3.service ortelius-backend.service ortelius-frontend.service ss -tln 2>/dev/null | grep -E ':(3000|8080|8529) ' head -3 /usr/share/doc/ortelius/LICENSE

You can prove the same login from the command line. The script below logs in through the API with the per-VM password and confirms that every common default credential is rejected. It then proves the core catalog function end to end by creating and listing a tracked repository:

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

Browse to http://<your-vm-public-ip>:8080/. The Ortelius sign-in form appears. Unauthenticated visitors can still browse public repository vulnerability data, under the banner "You are viewing public open source repositories. Sign In or Sign Up to see your organization data."

Sign in with the username admin and the password from the credentials file. You land on the Organizations view. It shows the ortelius organization that the first-boot proof-of-life repository created automatically, with its release count, vulnerability status and dependency count.

Open Welcome, either from the onboarding banner or at /welcome. First boot already added ortelius/ortelius as a proof-of-life Favorite, so you land on real data instead of an empty screen.

This is the core of what Ortelius does: it turns a tracked repository into a populated entry in the vulnerability catalog.

There are two ways to add repositories to the catalog:

• Connect GitHub (recommended for your own repositories): select Connect GitHub Account, authorize the Ortelius GitHub App, and choose which repositories, public or private, to grant it access to.
• Favorite a public repository by name: search by owner/repo for something you run in production (the form suggests nginx, curl and redis), select Search, then Favorite the result. This is useful for public repositories you do not have GitHub access to yourself.

curl -s -b <(sudo bash -c 'echo "auth_token=<your session token>"') \
  -H 'Content-Type: application/json' \
  -d '{"provider":"github","owner":"<owner>","name":"<repo>"}' \
  http://<vm-ip>:3000/api/v1/tracked-repos

CVE matching depends on SBOM data reaching a release. Connecting or favoriting a repository creates a release record, but it does not attach an SBOM immediately.

For fully automated SBOM and Scorecard collection, you can deploy the companion relscanner-job CronJob separately. It is not part of this image. It scans every tracked repository on a 15 minute schedule and attaches SBOMs through OCI attestations, Cosign, GitHub Release assets, or Syft and cdxgen generation.

Once your organization has release and SBOM data, these views are available:

• Dashboard ("The Posture") shows Mean Time To Remediate, SLA compliance by severity (Critical 15 days, High 30 days, Medium 90 days, Low 180 days), 180-day vulnerability trend analysis, and NIST SP 800-53/800-137/800-190/800-218 alignment.
• Synced Endpoints ("Where It's Running") shows where deployed software is running: Kubernetes, Docker, VM or serverless.
• Project Releases ("Where to Fix It") tracks vulnerabilities by release version.

Sign in as admin and open User Management to review accounts, or System Settings for application configuration.

The Ortelius role hierarchy is owner, admin, editor, viewer, scoped per organization. You can apply RBAC configuration as GitOps-style YAML through the API.

The entire catalog lives in ArangoDB's vulnmgt database: releases, SBOMs, CVEs, endpoints and the dependency graph. Take a logical backup with arangodump on a schedule that suits your rate of change:

sudo arangodump --server.username root --server.password "<arangodb-root-password-from-credentials-file>" \
  --server.database vulnmgt --output-directory "/root/ortelius-backup-$(date +%Y%m%d)"

Store the dump off the VM, for example in Azure Blob Storage, on another host or in your existing backup pipeline. To restore, run arangorestore against an empty vulnmgt database.

The image serves HTTP only, on both the API (3000) and dashboard (8080) ports. If you point a domain at this VM, put a reverse proxy (nginx, Caddy or an Azure Application Gateway) in front of both ports with your own TLS certificate.

Then set RUNTIME_REST_ENDPOINT / RUNTIME_GRAPHQL_ENDPOINT in /etc/ortelius/frontend.env and CORS_ALLOWED_ORIGINS in /etc/ortelius/backend.env to your HTTPS domain, and restart both services. The browser calls the API origin directly, so both files must agree on the externally visible address.

In the Ortelius UI, open Profile to change your password. To rotate it through the API instead, run:

curl -s -b <(echo "auth_token=<your session token>") -H 'Content-Type: application/json' \
  -d '{"old_password":"<current>","new_password":"<new-strong-password>"}' \
  http://<vm-ip>:3000/api/v1/auth/change-password