Tracktor

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Tracktor 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 Create.

Create the resource group, network and security rules, accept the Marketplace terms, then create the VM.

RG="tracktor-prod"; LOCATION="eastus"; VM_NAME="tracktor-01" IMAGE_URN="sac1647283583153:tracktor:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name tracktor-vnet --address-prefix 10.100.0.0/16 --subnet-name tracktor-subnet --subnet-prefix 10.100.1.0/24 az network nsg create -g "$RG" --name tracktor-nsg az network nsg rule create -g "$RG" --nsg-name tracktor-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 tracktor-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:tracktor: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 tracktor-vnet --subnet tracktor-subnet --nsg tracktor-nsg --public-ip-sku Standard

Replace <sub-id> and <version> with your subscription ID and the image version shown on the listing. Replace <your-mgmt-cidr> with the network you administer from.

On the first boot of each VM, Tracktor generates its own per-instance secrets and claims its own owner account before the web port is opened. Nothing is baked into the image.

Give the instance a minute after first boot, then SSH in and read the credentials file (mode 0600 root:root):

sudo cat /root/tracktor-credentials.txt

The file contains everything unique to this instance:

• TRACKTOR_USERNAME / TRACKTOR_PASSWORD: the owner login you use in the web UI. The owner has full access to the fleet.
• TRACKTOR_URL: the web address of this instance, resolved from its public IP on first boot.

Confirm that the services are healthy:

sudo systemctl is-active tracktor-firstboot tracktor tracktor-postboot nginx

active active active active

The application answers a health check on the loopback port. A successful answer also proves that the SQLite schema migrated on startup:

curl -s http://127.0.0.1/api/health

{"success":true,"data":{"timestamp":"2026-08-08T00:00:00.000Z"},"message":"Tracktor API is working"}

Upstream Tracktor creates the first account through an open /register form. The web page closes once an owner exists, but the underlying registration API stays reachable. On a raw deployment, a passer-by could therefore still create an account. On a VM with a public IP that is a real risk, so SecureAnyCloud removes it in two independent ways.

First, tracktor-postboot.service claims the owner account itself, over the loopback port, with a password generated for this VM. It does this before the public listener ever comes up.

Second, host nginx, the only public listener, permanently returns 404 for both /register and /api/auth/register. Public registration is therefore structurally impossible. nginx does not start at all until the owner has been claimed: it is gated on a bootstrap-ready marker that the post-boot service creates only after the owner exists. Port 80 is therefore closed for the whole bootstrap window.

The encryption secret (APP_SECRET, used by Tracktor to encrypt any notification credentials you add) is also generated on first boot. A startup guard refuses to launch the application at all if that secret is empty, too short or a known default. The upstream empty default never runs on your VM.

The app is on loopback only, and nginx is the single public door on port 80. Confirm this:

ss -tln | grep -E ':(80|3000) ' | awk '{print $1, $4}'

LISTEN 127.0.0.1:3000 LISTEN 0.0.0.0:80 LISTEN [::]:80

Public registration is closed, and anonymous callers cannot read vehicle data. Check both:

curl -s -o /dev/null -w 'public POST /api/auth/register -> %{http_code}\n' -X POST http://127.0.0.1/api/auth/register -H 'Content-Type: application/json' --data '{"username":"passerby","password":"nope123"}'
curl -s -o /dev/null -w 'anonymous GET /api/vehicles -> %{http_code}\n' http://127.0.0.1/api/vehicles

public POST /api/auth/register -> 404 anonymous GET /api/vehicles -> 401

Exactly one account exists on a fresh instance, and it is the owner you were given. Query the database:

sudo sqlite3 /var/lib/tracktor/tracktor.db 'SELECT username FROM users;'

admin

The image ships a script that exercises the whole security model and a real authenticated action through the public front door. It confirms that:

• The app answers
• Public registration is refused
• Anonymous callers are rejected
• A wrong password is rejected
• The per-instance password logs in, then creates and reads back a vehicle and a fuel log

Run it:

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

OK round-trip: url=http://<vm-ip>/ user=admin; health 200; anon vehicles 401; public register blocked 404; wrong password 401; login 200; created + read back vehicle and a fuel log

Open http://<vm-ip>/ in your browser. Sign in with the TRACKTOR_USERNAME and TRACKTOR_PASSWORD from the credentials file.

After you sign in, the dashboard is the home view. It summarises your fleet: the vehicles you have added, recent activity, upcoming reminders and the running costs Tracktor derives from your fuel and service history.