VIZid Flow (Network Rendering)

A VIZid Flow cluster: one server coordinating several render nodes.

VIZid Flow is the enterprise network render system of VIZid Suite. It spreads a model’s render jobs across a farm of render machines: a single server schedules and coordinates the work, and one render node runs on each render machine and does the actual rendering with its local copy of VIZid Suite.

Compared with the workstation render manager – which renders the queue one job at a time on the machine in front of the artist – VIZid Flow renders jobs (and the frames within them) on many machines at once, automatically picking machines whose hardware suits each job.

VIZid Flow replaces the earlier shared-folder render node. The old node watched a network folder for job manifests and required the project to be saved on a path the node could reach. VIZid Flow instead uses a managed server with a secured network connection: the add-on uploads the .blend to the server, the server hands out frame chunks to eligible nodes, and the project no longer has to live on a shared path. Transit is TLS-encrypted, every request is authenticated against a named account or API key, nodes are matched to jobs by hardware capability, and lost nodes are detected by heartbeat so their work is automatically re-queued.

The server is a multi-user, role-based service. It keeps named accounts (admins, operators and viewers) and machine identities (render nodes), so each person and machine has its own credential rather than everyone sharing one token. Jobs carry a priority tier, and the scheduler ages long-waiting work up so nothing starves. The whole service is built to run on a single coordinator on a studio LAN or as a horizontally-scaled, cloud-distributed deployment behind a load balancer.

Reference

Editor:

VIZid Render

Panel:

VIZid Render ‣ Network

How It Works

A VIZid Flow farm has three parts:

Server

One coordinator machine running the VIZid Flow Server service. It holds the job queue, stores uploaded .blend files and rendered frames, schedules work, and tracks the health of every node.

Render nodes

Each render machine runs the VIZid Flow Node service. A node advertises its hardware to the server, leases the render tasks it qualifies for, renders them headlessly with its local VIZid Suite, and uploads the frames.

Add-on

The VIZid Gloss add-on in VIZid Suite is the client. It submits jobs to the server and shows their progress.

When a job is submitted, the server expands its frame range into tasks – a still is one task; an animation is split into chunks of frames. Each task is leased to a node whose hardware satisfies the job’s requirements, and several nodes work on the same job in parallel. The job is finished when every task is done.

Setting Up the Server

The server is installed once, on the machine that will coordinate the farm.

1. On the coordinator machine, run the VIZid Flow Server installer from dist/VIZid-Flow-Server-Setup (double-click Install.cmd and approve the administrator prompt). It installs the VIZidFlowServer Windows service, set to start automatically, and opens the firewall for the server port (TCP 8787 by default).

2. On its first run the server generates a certificate authority (CA), bootstraps an admin account, and mints a node API key and an operator API key. These secrets are shown once – the installer prints them to the console and the server’s first-run log in the data directory. Copy them down now; the plaintext is never stored again:

   CA file and CA fingerprint

   The ca.crt certificate (and its SHA-256 fingerprint) that nodes and the add-on pin to trust the server.

   admin password

   The one-time password for the built-in admin account. Log in with it, then change it (see Accounts & Sign-in).

   node API key

   Authorises a render node to register with the server. Each node swaps it for its own per-node identity at registration.

   operator API key

   Authorises the Blender add-on to submit and manage jobs.

   Server URL

   The address nodes and the add-on connect to, for example https://flow-host:8787.

3. Distribute the credentials:

   • Copy the node API key and the ca.crt file to each render machine (place ca.crt on a share both machines can reach, or pin it by fingerprint instead of copying the file).

   • Give the operator API key and ca.crt to whoever submits renders from the add-on. Power users can instead log in with a named account.

The CA, identity store, audit log and job store live in the server data directory (C:\ProgramData\VIZid\Flow\) and survive a reboot or a service restart. Account passwords and API keys are never stored in plaintext: passwords are PBKDF2-hashed and API keys are kept hashed at rest.

Accounts & Sign-in

VIZid Flow is a multi-user service. Everyone and every machine that talks to the server has its own credential, and each credential carries a role that decides what it may do:

admin

Full control: manage users and API keys, view and reconfigure the cluster, and submit, cancel and re-prioritise any job.

operator

Submit jobs, cancel and re-prioritise their own jobs, and read status. This is the role the add-on uses day to day.

viewer

Read-only: list jobs and watch status, but cannot submit or change anything.

node

A render machine’s identity (not a person). A node authenticates with a node API key and may only do node work: register, heartbeat, lease tasks and upload frames.

On first run the server creates the built-in admin account and prints its one-time password (see Setting Up the Server). The administrator logs in with it and then creates the accounts and keys the studio needs:

1. Log in. Authenticate the admin account against POST /v1/auth/login with its username and password. The server returns a short-lived session token – a signed bearer token sent as Authorization: Bearer <token> on later requests. POST /v1/auth/logout ends a session and GET /v1/auth/whoami reports the current principal.

2. Create users. POST /v1/admin/users adds an operator or viewer account with a username, password and role; GET /v1/admin/users lists them. Admins can also reset a password or disable an account from the same endpoint.

3. Issue API keys. POST /v1/admin/keys mints an API key for a given role – a node key for render machines or an operator key for an add-on seat. The key’s plaintext is shown once; store it securely. GET /v1/admin/keys lists keys and DELETE /v1/admin/keys/{id} revokes one.

How each party authenticates:

• Render nodes present the node API key. The first time a node registers it swaps the shared bootstrap key for its own per-node identity, so a single compromised node can be revoked without disturbing the rest of the farm.

• The add-on presents an operator API key (the simplest setup), or a power user signs in with a named operator account and uses the session token.

Sessions are deliberately short-lived; the add-on and tools re-authenticate when a token expires. API keys are long-lived and are the right choice for unattended machines.

Adding Render Nodes

A render node is installed on every machine that will render. Each node needs the server URL, the node API key and the CA from the server installer’s printout, and it needs its own working copy of VIZid Suite to render with.

Note

A render node must have a current VIZid Suite build installed – the build whose add-on includes the VIZid Flow render runner. The node calls that local VIZid Suite to render; an out-of-date or missing build cannot render Flow jobs.

1. On the render machine, run the VIZid Flow Node installer from dist/VIZid-Flow-Node-Setup. The guided install (Install.cmd) prompts for the values; for many machines, the scripted install passes them as flags:

   -Server

   The server URL, e.g. https://flow-host:8787.

   -ClusterToken

   The node API key from the server printout. (The flag keeps its old name for compatibility; pass the node API key where the old cluster token went.)

   -CA

   The path to ca.crt (or use -CAPin with the CA fingerprint to pin the server without copying the file).

   -Blender

   The path to this machine’s VIZidSuite.exe. If omitted, the installer auto-detects it.

   Optional flags assign node -Labels (such as calibrated or lic:keyshot) and -Slots (how many tasks the node renders at once).

2. The installer registers the VIZidFlowNode Windows service, set to start automatically, and starts it. On registration the node advertises its hardware to the server: CPU cores, RAM, each GPU’s vendor / model / VRAM, the render backends it supports (OptiX, CUDA, HIP, oneAPI and CPU), its VIZid Suite version and any labels.

The node then runs unattended: it heartbeats the server, leases tasks it qualifies for, renders them and uploads the frames, and leases more when free.

Connecting the Add-on

The add-on is pointed at the server once, in the preferences:

1. Open Edit ‣ Preferences ‣ Add-ons and expand the VIZid Gloss add-on.

2. Set the VIZid Flow server URL (e.g. https://flow-host:8787).

3. Paste the operator API key from the server printout (or sign in with a named operator account).

4. Set the CA file to the ca.crt copied from the server.

Once these are set, the add-on can submit jobs to the farm and read their status. Because the operator API key carries the operator role, the add-on can submit, cancel and re-prioritise its own jobs; a viewer credential can watch the farm without changing it.

Submitting Jobs and Hardware Requirements

Submitting a job with its network hardware requirements.

A render job is sent to the farm from the render manager:

1. In the job’s Job Settings, set Render On to Network.

2. In the Network Hardware box, set the job’s hardware requirements:

   Backend

   The render backend the job needs, for example OptiX, CUDA, HIP, oneAPI or CPU.

   Require GPU

   Restricts the job to nodes that have a GPU.

   GPU vendor

   Pins the job to a GPU vendor (NVIDIA, AMD or INTEL), or Any.

   Min VRAM

   The minimum graphics memory a node’s GPU must have, in GB.

   Min RAM

   The minimum system memory a node must have, in GB.

   Labels

   Node labels the job requires, used to pin work to specific machines (for example a licensed or colour-calibrated node).

3. Press Submit to Network. The add-on uploads the saved .blend and the job specification to the server.

The server only sends a job to nodes that satisfy all of its requirements. A GPU / OptiX job never lands on a CPU-only node; a 24 GB-VRAM job only goes to nodes with enough graphics memory; a labelled job only goes to nodes carrying those labels – which is how licensed or calibrated machines are reserved for the work that needs them. Among the nodes that are eligible and free, the server load-balances, choosing the best fit so that large GPUs are left available for the jobs that actually need them. The job’s frames are chunked across those nodes so they render in parallel.

Queue Priority

Every job carries a priority tier. The scheduler always runs eligible tasks from higher-priority jobs before lower-priority ones, so urgent work overtakes the backlog without anyone reordering the queue by hand. Four tiers are available:

Low

Background work that should yield to everything else.

Normal

The default for a new job when no tier is set.

High

Ahead of normal work.

Urgent

The top tier – runs before everything else that is eligible.

Among jobs in the same tier the oldest job goes first, so work within a tier is fair (first-in, first-out).

To stop a flood of high-tier work from starving older low-tier jobs forever, the scheduler ages waiting jobs: the longer a job waits, the more its effective priority climbs. The bonus is bounded and gradual, so a long-waiting Low job will eventually overtake fresher high-tier work, but only after a long, bounded delay – nothing starves, yet genuinely urgent work still leads.

An operator can change the tier of a job that is still queued with POST /v1/jobs/{id}/priority: operators may re-prioritise their own jobs, and admins may re-prioritise any job. A job that has already finished, failed or been cancelled cannot be re-prioritised.

Monitoring

The VIZid Flow status panel in the render manager shows the state of submitted jobs. Pressing Refresh updates it with each job’s status, the number of tasks done out of the total, and per-node activity – which nodes are busy, idle or offline, and how many tasks each has completed.

Administrators can query the cluster directly for the live node registry (each node’s advertised hardware and state) and the queue depth and throughput, to see how the farm is loaded. These cluster views require the admin role.

Security

VIZid Flow is hardened for enterprise use. Its security rests on transport encryption, named credentials and a defended HTTP surface:

• TLS with a pinned CA. All traffic between the add-on, the server and the nodes runs over TLS. Nodes and the add-on pin the server’s CA (by certificate or fingerprint), so a man-in-the-middle cannot impersonate the server.

• Bearer credentials. Every request carries a bearer credential – either a short-lived signed session token from a login, or a long-lived API key. Each credential maps to a role (admin / operator / viewer / node) that gates what it may do.

• Secrets stored hashed. Account passwords are PBKDF2-hashed with a per-user salt, and API keys are stored hashed at rest, so a leaked identity store exposes no usable password or live key.

• Login rate limiting. The login route is rate-limited per client address to blunt credential-stuffing, on top of a general per-IP request limit.

• Job isolation. Operators and viewers see and act on only the jobs they submitted – listing returns just their own jobs, and reading, cancelling or re-prioritising another person’s job is refused as if the job did not exist (so job identifiers cannot be probed). Administrators see and manage every job.

• Submission limits. The server rejects a submission that asks for too many render jobs or that would expand into an unreasonable number of frame tasks, and one with an inverted frame range – so a malformed or malicious job cannot exhaust the server.

• Sandboxed rendering. A node opens each submitted .blend with Blender’s auto-run of embedded Python disabled, so a booby-trapped file cannot run code on the render machine, and it verifies every downloaded .blend against its expected content hash before rendering.

• Audit log. The server keeps an append-only audit log (who did what, from where) – logins, job submissions, cancellations, re-prioritisations and user/key changes – in the data directory.

• Conservative timeouts. The server enforces TLS 1.2+ with modern ciphers and slow-loris-resistant read/write/idle timeouts and body-size caps.

Note

Behind a load balancer or reverse proxy. So that the rate limiter and audit log record the real client address rather than the proxy’s, configure the server’s set of trusted proxies. The forwarded-address header is otherwise ignored (it is easily spoofed), which stops a client from forging its source address to evade the rate limiter or the audit log.

Note

Keep the toolchain patched. VIZid Flow’s TLS is provided by the Go standard library, so the relevant 2025/2026 Go TLS security advisories are fixed simply by building with a current Go toolchain (go1.26.4 or newer). No VIZid Flow code change is required.

Operating advice:

• Keep the admin password and the node and operator API keys secret; store the CA file and credentials only on the machines that need them.

• Rotate keys through the admin endpoints – issue a replacement with POST /v1/admin/keys and revoke the old one with DELETE /v1/admin/keys/{id}. Change the bootstrap admin password promptly after first run.

• Disable an account or key rather than sharing one credential among people.

Running in the Cloud

VIZid Flow does not have to run on a single coordinator. Both the Flow server and the shared Asset Library can run as horizontally-scaled services behind a load balancer, because their authentication is stateless:

• Signed sessions, no session store. A session token is an HMAC-signed claim, not a server-side record. Any instance can verify a token any other instance issued, so no sticky sessions are required – round-robin across instances.

• Shared signing key. For multiple instances to verify each other’s sessions, set the same signing key on every instance via the VIZID_FLOW_SIGNING_KEY environment variable (hex or base64, at least 32 bytes), supplied from your secrets manager. A single instance generates and persists its own key, so this is only needed when scaling out.

• Shared store / volume. Point every instance at the same data directory (the identity store, audit log and job store) and job-blob storage on a shared volume or object-storage mount, so any instance can serve any request.

• Health endpoints. Wire the load balancer’s health check at the server’s health endpoint so traffic is held back from an instance that is still starting or has lost its mount.

The asset-library mediator follows the same model – stateless signed sessions, a shared signing key, RBAC and health probes – so the two services scale the same way. See the library’s cloud notes for the shared-storage and key-distribution details that apply to both.