Wexflow

• In the Azure Portal, choose Create a resource and search the Marketplace for Wexflow on Ubuntu 24.04 LTS by SecureAnyCloud.
• Select the offer and choose Create.
• On the Basics tab, pick your subscription, resource group and region, set the VM name, and choose size Standard_B2s.
• Leave the authentication type as SSH public key and the username as azureuser.
• Under Inbound port rules, allow SSH (22) and HTTP (80).
• Select Review + create. The VM is ready in about a minute. First boot then generates this instance's own administrator password and token signing key, and nothing listens on port 80 until it has.

az group create --name wexflow-rg --location eastus
az vm image terms accept --urn sac1647283583153:wexflow:default:latest
az vm create \
  --resource-group wexflow-rg \
  --name wexflow-vm \
  --image sac1647283583153:wexflow:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
# the public address of the new VM
az vm show --resource-group wexflow-rg --name wexflow-vm \
  --show-details --query publicIps --output tsv

Open the admin panel port:

az network nsg rule create --resource-group wexflow-rg \
  --nsg-name wexflow-vmNSG --name allow-http \
  --priority 1010 --destination-port-ranges 80 \
  --protocol Tcp --access Allow --direction Inbound

ssh azureuser@<vm-ip>

Every instance generates its own administrator password on first boot and writes it to a root-only file. Read it:

sudo cat /root/wexflow-credentials.txt

Expected output:

# Wexflow on Ubuntu 24.04 LTS by sac — per-VM credentials
# Generated at first boot on 2026-08-07T21:31:08Z. Keep this file private.
#
# Deployment guide: https://secureanycloud.com/stacks/wexflow/ WEXFLOW_URL=http://20.124.233.51/admin/ WEXFLOW_ADMIN_USERNAME=admin WEXFLOW_ADMIN_PASSWORD=<the unique password generated for your instance>
# Sign in at http://20.124.233.51/admin/ and change this password from Users in the admin panel.
# The JWT signing key and the HTTPS pfx passphrase were also generated uniquely for this
# instance and live in /opt/wexflow/Wexflow.Server/appsettings.json (root:wexflow 0640).

The address shown is your own instance's public address, and the password is unique to it. No SecureAnyCloud image ever ships a shared or published password.

Confirm that both services are up and check exactly which upstream artifact this image shipped:

systemctl is-active wexflow.service nginx.service cat /opt/wexflow/VERSION curl -s http://127.0.0.1/api/v1/hello

Expected output:

active active product=Wexflow version=10.0 upstream=https://github.com/aelassas/wexflow release=https://github.com/aelassas/wexflow/releases/download/v10.0/wexflow-10.0-linux-netcore.zip release_sha256=4c7c051b12d2bea108ad4f1c819ad1849fe2daed14bdbdd1ef7e1974f406bf5a licence=MIT (verbatim text at /opt/wexflow/LICENSE.txt) runtime=aspnetcore-runtime-10.0 10.0.10-0ubuntu1~24.04.1 (Ubuntu archive, noble-updates/main) datastore=SQLite (embedded, /opt/wexflow/Wexflow/Database/Wexflow.sqlite) entry_point=http://<this-vm-public-ip>/admin/ built_by=sac {"message":"Wexflow Service is running..."}

Open http://<vm-ip>/admin/ in a browser. The root of the site redirects there, so http://<vm-ip>/ works too.

Sign in with the username admin and the password from /root/wexflow-credentials.txt. You land on the Dashboard, which shows live counters for pending, running, completed, failed, warning, rejected and stopped jobs, and a searchable list of recent entries.

Choose Manager in the top navigation. It lists every workflow the engine has loaded from the embedded database, with its id, launch type, whether it is enabled, whether it needs approval, and its description.

The image ships the complete upstream example catalogue, one workflow per task type, plus the SecureAnyCloud health check. Open, copy and adapt them as you like.

To count them from the shell, run:

sudo sqlite3 /opt/wexflow/Wexflow/Database/Wexflow.sqlite 'select count(*) from workflows;' ls /opt/wexflow/Wexflow/Workflows | head -6

Expected output:

120 Workflow_Approval.xml Workflow_Approval_Import.xml Workflow_Approval_Reject.xml Workflow_ApproveDocument.xml Workflow_ApproveInvoice.xml Workflow_ApproveTimesheet.xml

Three of the upstream examples launch themselves: one at every startup, one periodically and one on a cron schedule. They ship disabled, so a new instance does not silently execute jobs and accumulate history before you have looked at it. Step 9 shows how to switch one on.

In Manager, click the row for sac_Health_Check to select it, then click Start.

Go back to Dashboard. The Done counter has advanced, and the run appears in the entries table with a green Done status, its id, its name and the time it finished.

The workflow did real work: it created a file and copied it. Confirm on the instance:

sudo ls -l /var/lib/wexflow/healthcheck/out/
sudo journalctl -u wexflow.service --no-pager | grep sac_Health_Check | tail -6

Expected output:

total 0 -rw-r--r-- 1 wexflow wexflow 0 Aug 7 21:31 sac-healthcheck.txt 2026-08-07 21:29:45,309 INFO [13] - [sac_Health_Check / 6] [Touch] File /var/lib/wexflow/healthcheck/src/sac-healthcheck.txt created. 2026-08-07 21:29:45,309 INFO [13] - [sac_Health_Check / 6] [Touch] Task finished. 2026-08-07 21:29:45,309 INFO [13] - [sac_Health_Check / 6] [FilesCopier] Copying files... 2026-08-07 21:29:45,309 INFO [13] - [sac_Health_Check / 6] [FilesCopier] File copied: /var/lib/wexflow/healthcheck/src/sac-healthcheck.txt -> /var/lib/wexflow/healthcheck/out/sac-healthcheck.txt 2026-08-07 21:29:45,309 INFO [13] - [sac_Health_Check / 6] [FilesCopier] Task finished. 2026-08-07 21:29:45,310 INFO [13] - [sac_Health_Check / 6] Workflow finished.

The same proof runs as a single command, which is what this instance ran on itself during first boot. The command also re-proves that every published upstream default credential is refused:

sudo /usr/local/sbin/wexflow-verify-workflow.sh

Expected output:

wexflow runtime verification ok all five published upstream default credentials rejected with 401 ok the second seeded administrator account no longer exists ok a token forged with the published upstream signing key is rejected ok privileged endpoints reject unauthenticated calls ok the per-VM admin password authenticates and returns a token ok the token opens a privileged endpoint ok workflow 900 started, instance 237462e8-6e02-4b44-92f6-28ee42d621a2 ok the workflow produced /var/lib/wexflow/healthcheck/out/sac-healthcheck.txt ok the engine's completed-workflow counter advanced 5 -> 6 WEXFLOW_VERIFY_OK

Choose Designer in the top navigation, click Browse, pick a workflow and click Open. The workflow renders as a diagram of its tasks in order. You can also switch the same workflow to the Graph, JSON or XML view, edit it there, and save.

Choose New workflow to start an empty one. Give it an unused id, a name and a description, then choose a launch type. Add tasks from the palette and set their options. Save writes the workflow to the database, and the engine picks it up immediately. Run starts it without leaving the designer.

The example catalogue is the fastest way to learn a task. Open the example named after the task, read its settings, then copy the pattern into your own workflow. Every task is also documented in XML on the instance:

ls /opt/wexflow/Documentation | head -8 cat /opt/wexflow/Documentation/FilesCopier.xml

History lists every run the engine has ever recorded, with its status, date, workflow and description. Filter it by date range and free text. Dashboard shows the same information for the current period, along with the live counters.

Approvals and Records are the human-in-the-loop side of the product. A workflow marked as an approval workflow pauses at its Approval task until somebody approves or rejects it from the Approvals page. Records attach documents to that decision, and the records hot folder at /opt/wexflow/Wexflow/Records/_HotFolder picks up files dropped into it.

A workflow's launch type decides when it runs. Set it in the designer, in the workflow XML, or through the API.

Launch type When it runs

trigger Only when you start it, from the manager, the designer or the API

startup Once, every time the engine starts

periodic Every period, expressed as dd.hh:mm:ss

cron On a Quartz cron expression, for example 0 0/1 * * * ? for every minute

The three shipped examples that use the last three launch types are disabled. To look at one before enabling it:

sudo sqlite3 /opt/wexflow/Wexflow/Database/Wexflow.sqlite \
  "select XML from workflows where XML like '%Workflow_Cron%' limit 1;" | head -12

To enable it, open it in the designer, select Enabled and save. Do this rather than editing the database, so the engine's in-memory schedule stays in step with what is stored.

File-triggered workflows are the other common pattern. A workflow whose first task is FileSystemWatcher starts itself when a file appears in the folder it watches. Most overnight file handling is wired up this way. cat /opt/wexflow/Documentation/FileSystemWatcher.xml documents its options.

Everything the interface does is available over HTTP. Sign in once to get a token, then send it as a bearer token. In the commands below, <WEXFLOW_ADMIN_PASSWORD> stands for the password from /root/wexflow-credentials.txt.

TOKEN=$(curl -s -X POST http://127.0.0.1/api/v1/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"<WEXFLOW_ADMIN_PASSWORD>","stayConnected":false}' \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["access_token"])')
curl -s -H "Authorization: Bearer $TOKEN" http://127.0.0.1/api/v1/status-count echo
curl -s -H "Authorization: Bearer $TOKEN" 'http://127.0.0.1/api/v1/search?s=sac' \
  | python3 -m json.tool | head -12

Expected output:

{"PendingCount":0,"RunningCount":0,"DoneCount":2,"FailedCount":0,"WarningCount":0,"DisabledCount":3,"RejectedCount":0,"StoppedCount":0} [ { "DbId": "120", "Id": 900, "InstanceId": "3a344963-066d-4280-971b-bc9d4a4752f8", "Name": "sac_Health_Check", "FilePath": null, "LaunchType": 1, "IsEnabled": true, "IsApproval": false, "EnableParallelJobs": true,

Start a workflow and read back the engine's counters:

TOKEN=$(curl -s -X POST http://127.0.0.1/api/v1/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"<WEXFLOW_ADMIN_PASSWORD>","stayConnected":false}' \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["access_token"])')
curl -s -X POST -H "Authorization: Bearer $TOKEN" 'http://127.0.0.1/api/v1/start?w=900' echo sleep 5
curl -s -H "Authorization: Bearer $TOKEN" http://127.0.0.1/api/v1/status-count echo

A browsable description of the whole API is served at http://<vm-ip>/swagger. To call the API from your own machine, replace 127.0.0.1 with your instance's address.

Treat the generated password as a starting point. Change it from Users in the admin panel: select admin, set a new password and save. The same page adds further users.

Wexflow has three user profiles. A super administrator sees and controls every workflow. An administrator sees only the workflows assigned to them, which you set per user on the Users page. A restricted user has no manager access at all and is used for the approvals and records side of the product.

The engine looks up the account named admin at startup, so keep that name. Change its password freely.

The image ships on plain HTTP so that it works the moment it boots, with no certificate and no domain name required. For anything beyond a trial, put a certificate in front of it. nginx is already the entry point, so this is ordinary nginx work:

• Point a DNS name at the instance and open TCP 443 in the network security group.
• Install a certificate for that name, either your own or one from a certificate authority.
• Add a listen 443 ssl; server block to /etc/nginx/sites-available/wexflow with your certificate paths. Keep the same location blocks, and redirect port 80 to it.
• Reload with sudo nginx -t && sudo systemctl reload nginx.

The admin single-page application addresses the API on the same origin it was loaded from, so it follows the change with no further configuration.