Komodo

In the Azure Marketplace, find Komodo on Ubuntu 24.04 LTS and choose Create. Select Standard_B2ms or larger.

On the Networking tab, allow inbound 443 and 22. Leave everything else at its default and create the VM.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:komodo-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-resource-group \
  --name my-komodo \
  --image sac1647283583153:komodo-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open port 443 for the web interface. Port 22 is used for SSH:

az vm open-port --resource-group my-resource-group --name my-komodo --port 443 --priority 1001

Connect over SSH as azureuser:

ssh azureuser@<vm-public-ip>

Komodo is four containers plus an encrypted front door, and all of it starts automatically at boot. Check the services and containers:

systemctl is-active docker nginx komodo-postgres komodo-ferretdb komodo-core komodo-periphery

sudo docker ps --format 'table {{.Names}}\t{{.Status}}'

Each of the four images is pinned to exact content rather than to a moving tag. None of them is fetched at runtime.

This image does not ship with a password. Your VM generated its own on first boot, before Komodo was allowed to start. Print the credentials file with the password hidden:

sudo sed -E 's/^(KOMODO_ADMIN_PASSWORD=).*/\1REDACTED/' /root/komodo-credentials.txt

The file is 0600 root:root. To read the real password, run:

sudo grep '^KOMODO_ADMIN_PASSWORD=' /root/komodo-credentials.txt | cut -d= -f2-

The sign-in address is in the same file:

sudo grep '^KOMODO_URL=' /root/komodo-credentials.txt | cut -d= -f2-

Open https://<KOMODO_ADDRESS>/ in a browser. The certificate was generated on your VM, so your browser warns that it is not signed by a public authority. This is expected for an appliance reached by IP address.

Sign in with the user <KOMODO_ADMIN_USER> and the password from Step 5. The home view lists every resource Komodo knows about. On a new appliance it shows one server: this VM.

To use a real certificate instead, replace /etc/ssl/komodo/komodo.crt and /etc/ssl/komodo/komodo.key and reload nginx. Keep the private key 0600 root:root.

Only two ports on this VM answer from off the machine: SSH and the encrypted Komodo front door. The database, the document engine and the agent are reachable from neither the network nor the containers Komodo deploys. List the listening ports:

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

Run the bundled checker. It asserts that set of ports by equality, rather than by looking for a handful of unwanted ports:

sudo /usr/local/sbin/komodo-port-check.sh

Then confirm that no MongoDB component is present on the VM, in any of the four container images, or in the unit files that start them:

sudo /usr/local/sbin/komodo-no-sspl-assert.sh

By default, Komodo allows self registration, and lets the first visitor to an appliance with no administrator claim it. This image closes both. It also reports this to the browser, so no sign-up button is ever shown. Query the login options:

ADDR="$(sudo grep '^KOMODO_ADDRESS=' /root/komodo-credentials.txt | cut -d= -f2-)" curl -s --cacert /etc/ssl/komodo/komodo.crt --resolve "${ADDR}:443:127.0.0.1" \
  -H 'Content-Type: application/json' \
  -d '{"type":"GetLoginOptions","params":{}}' \
  "https://${ADDR}/auth/login" echo

In the response, registration_disabled is true and every external login provider is false.

Your VM also re-checks this on every boot. If the administrator account is ever missing, it stops the front door rather than leaving an open sign-up on a machine that manages containers.

systemctl is-active komodo-postboot-verify.service

Komodo limits sign-in attempts to 5 in any 15 second window. This is a Komodo feature, not a limitation of this image, and it applies to the checks that follow. If you run several checks back to back and one reports a refusal, wait twenty seconds and run it again.

Run the full verification with one command:

sudo /usr/local/sbin/komodo-verify.sh

On the running appliance, it asserts that:

• the four images still match the content they were pinned to
• the off-VM listening set is exactly SSH and 443
• no MongoDB component is present
• the database and the agent publish no port
• self registration is closed
• Komodo Core is published only on the loopback interface
• the encrypted front door forwards the live-update websocket
• containers are denied the Azure instance metadata service
• the certificate names this VM rather than the machine the image was built on
• the administrator credential recorded on this VM opens it, while a wrong one is refused

It finishes by feeding each of its own offline checks a deliberately bad input and requiring each to fail on it, because a check that cannot fail proves nothing.

For the heavier version, run sudo /usr/local/sbin/komodo-selftest.sh --customer-vm --full. It also starts a deliberately insecure throwaway Komodo on its own temporary database, to prove that the sign-up check can detect an open sign-up. It takes a few minutes and removes everything it created.

In the web interface, choose Deployments, then New Deployment. Give the deployment a name, pick the server called Local (this VM), and set the image to alpine:3.22, which is already present. Then choose Deploy.

You can do the same from the command line. The image ships a check for it. The check signs in through the front door exactly as you did, creates a deployment and runs it. It reads the container's own output back out of Komodo, then removes both the deployment and the container:

sudo /usr/local/sbin/komodo-deploy-probe.sh

The check reports the container's own output rather than a status code on purpose. A Komodo that created a deployment and silently ran nothing would return success for every call in that sequence.

A container that Komodo deploys is code you chose to run. Ordinary networking works normally. The container can resolve names and reach the internet, so images pull and packages install:

sudo docker run --rm alpine:3.22 sh -c 'nslookup ghcr.io >/dev/null 2>&1 && echo "name resolution works" || echo "name resolution is broken"'

A deployed container cannot reach the Azure instance metadata service, which is where a virtual machine's own cloud credentials are handed out. Without that boundary, being able to deploy a container here would quietly mean holding this subscription's identity. Verify the block:

sudo docker run --rm alpine:3.22 sh -c 'wget -q -T 5 -O /dev/null http://169.254.169.254/metadata/instance 2>/dev/null && echo "metadata reachable" || echo "metadata unreachable, as intended"'

The rules are installed as a systemd unit and reapplied whenever Docker restarts. Check them:

sudo /usr/local/sbin/komodo-egress-filter.sh check

Only containers are filtered. The VM itself keeps its own access to that service, which is how it learned its public address on first boot.

Everything Komodo stores lives in two Docker volumes. That includes every resource you define, every user and every update record. List the volumes:

sudo docker volume ls --format '{{.Name}}'

The compose files, repositories and build contexts that Komodo manages live on the VM at /etc/komodo:

ls /etc/komodo

Komodo writes dated database backups into /etc/komodo/backups, which is mounted into Core. Back up that directory and the two volumes together, and you can rebuild this appliance elsewhere.

Your per-VM secrets live in /etc/komodo-secrets, mode 0700. The directory is deliberately mounted into no container. Check its permissions:

sudo stat -c '%a %U:%G %n' /etc/komodo-secrets

Change the administrator password in the web interface under Settings, or through the API with the UpdatePassword request. Do this before you connect Komodo to anything important, and keep self registration switched off.

To add a second person, sign in as the administrator, then create and enable the account under Settings. With self registration off, only someone who is already signed in can create accounts.

Security updates for Ubuntu, nginx and the container engine install themselves. Confirm that unattended upgrades are enabled:

systemctl is-enabled unattended-upgrades.service

The four container images are pinned to exact content, so nothing changes underneath you. To move to a newer Komodo, edit the image reference in /etc/systemd/system/komodo-core.service and /etc/systemd/system/komodo-periphery.service. Then run sudo systemctl daemon-reload and restart the two units.

Take a backup first, and read the Komodo release notes, because the database schema can change between minor versions.

For a clean upgrade path with none of that work, deploy the next SecureAnyCloud image release and restore your backup into it.