PowerJob

Prerequisites

• An active Azure subscription, an SSH key pair, and a VNet and subnet in the target region
• A VM size of Standard_B2s (2 vCPU / 4 GiB RAM), which is a comfortable starting size for the server and its database
• NSG inbound rules that allow 22/tcp from your management network, 7700/tcp from the operators who use the console, and 10010/tcp from the worker nodes that register with PowerJob

The appliance serves plain HTTP. For production, put it behind your own domain and TLS.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for PowerJob by SecureAnyCloud, and select Create.

On Basics, 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), then add 7700 and 10010 after deployment. Choose Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:powerjob:default:latest
az vm create \
  --resource-group <your-rg> \
  --name powerjob \
  --image sac1647283583153:powerjob:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name powerjob --port 7700 --priority 1010
az vm open-port --resource-group <your-rg> --name powerjob --port 10010 --priority 1020

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the stack is running

PowerJob runs as a Docker Compose stack managed by a single systemd unit. On first boot, the stack rotates every secret and creates a fresh scheduler database. It also seeds the per-VM ADMIN account and a per-VM worker application, and points its console URL at your VM's address.

The stack can take a minute or two to become fully healthy after you first create the VM. Check the services and containers:

systemctl is-active powerjob.service docker.service docker compose -f /var/lib/powerjob/docker-compose.yml ps --format '{{.Name}}\t{{.Status}}'

Both containers should report Up.

Step 5 - Retrieve your per-VM credentials

First boot writes a unique administrator password and worker application secret to a root-only file. Read the file over SSH:

sudo cat /root/powerjob-credentials.txt

The file records the console URL, the ADMIN username, the generated password, the per-VM worker application name (sac-app) and its secret. The file is mode 0600 and owned by root.

Step 6 - Verify the login and that no default credential survives

First boot initializes the built-in ADMIN account with a per-VM password instead of PowerJob's shipped default (ADMIN / powerjob_admin), so no known credential is ever live. You can prove this from the shell. The per-VM password authenticates ("success":true), while the shipped default is rejected ("success":false).

B=http://127.0.0.1:7700
PASS=$(sudo grep '^POWERJOB_ADMIN_PASSWORD=' /root/powerjob-credentials.txt | cut -d= -f2-)
# The per-VM ADMIN authenticates:
curl -s -X POST "$B/auth/thirdPartyLoginDirect" -H 'Content-Type: application/json' \
  -d "{\"loginType\":\"PWJB\",\"originParams\":\"{\\\"username\\\":\\\"ADMIN\\\",\\\"password\\\":\\\"$PASS\\\"}\"}" | head -c 120 echo
# The shipped default is rejected:
curl -s -X POST "$B/auth/thirdPartyLoginDirect" -H 'Content-Type: application/json' \
  -d '{"loginType":"PWJB","originParams":"{\"username\":\"ADMIN\",\"password\":\"powerjob_admin\"}"}' | head -c 120

The first call returns "success":true, which means the per-VM admin authenticated and a JWT was issued. The second call returns "success":false with a "password is incorrect" message, which means the shipped default was rejected.

Step 7 - Confirm the pinned image and exposed ports

The server image is pinned to v5.1.2. The VM exposes only SSH, the console port and the worker transport port. MySQL listens on the private Docker network only, never on the host.

docker compose -f /var/lib/powerjob/docker-compose.yml images --format '{{.Repository}}:{{.Tag}}' | sort -u sudo ss -tln '( sport = :7700 or sport = :10010 or sport = :22 or sport = :3306 )' | awk '{print $1" "$4}'

The output lists powerjob/powerjob-server and mysql:8.4, with listeners on :22, :7700 and :10010 only. :3306 (MySQL) is not bound on the host.

Step 8 - Sign in to the console

Browse to http://<vm-public-ip>:7700/, choose PowerJob Account, and sign in as ADMIN with the password from Step 5.

Step 9 - Open your application dashboard

After you sign in, you land on AppManage, which lists the applications registered with this scheduler. The image ships one per-VM application, sac-app, in the default namespace.

Select it with Enter to open its dashboard. The dashboard summarizes the live scheduler state: the number of jobs, running instances and registered worker nodes, plus the server's address and time.

Step 10 - Review the scheduler and its jobs

Open Job management to see the scheduled jobs. Each row shows the job name, its schedule (for example a CRON expression), the execution type, the processor type and its status.

From here, create your own jobs with New job, set their schedule, choose a routing strategy, and enable or disable them. You can also trigger a job immediately with Run.

Step 11 - Register a worker and run a job

Jobs are dispatched to workers, which are the powerjob-worker SDK embedded in your own applications. Open AppManage to see your applications. The image ships the per-VM application sac-app.

To connect your own worker, add the PowerJob worker dependency to your application. Point it at this server with the per-VM application name and secret from Step 5:

# In your application's PowerJob worker configuration: powerjob.worker.server-address=<vm-public-ip>:7700 powerjob.worker.app-name=<POWERJOB_APP_NAME> powerjob.worker.protocol=http # authenticate the application with the per-VM secret: powerjob.worker.app-secret=<POWERJOB_APP_PASSWORD>

When your worker registers, it appears on the application dashboard with its address. You can then route jobs to it and trigger them from Job management.

Step 12 - Production hardening

• TLS: The appliance serves plain HTTP on port 7700. For production, place it behind your own domain and a TLS-terminating load balancer or reverse proxy.
• Application secret: The per-VM worker application secret (Step 5) authorizes workers to register and receive dispatched commands. Keep it secret and give it only to your own worker nodes. You can add more applications, each with its own password, under AppManage.
• Admin password: Change the ADMIN password from the console (Personal) after your first sign-in. Alternatively, add your own users under UserManager and grant them roles.
• Network: Expose port 7700 only to your operators and 10010 only to your worker nodes, not to the public internet.
• Backups: The scheduler database lives in the powerjob_mysql_data Docker volume. Include the volume, and /var/lib/powerjob/.env (which holds your per-VM secrets), in your backup routine.

Managing the service

# Restart the whole stack
sudo systemctl restart powerjob.service
# Stop / start
sudo systemctl stop powerjob.service
sudo systemctl start powerjob.service
# Follow the server logs docker compose -f /var/lib/powerjob/docker-compose.yml logs -f powerjob-server

Support

Every SecureAnyCloud image is backed by 24/7 support. For questions about this PowerJob image, contact us at sales@secureanycloud.com.

Deploy on Azure

Launch PowerJob on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com