Architecture and Deployment Planning
Alteryx Server is a multi-tier web application. The core components are the Controller (coordinates job distribution, holds the MongoDB persistence layer, and serves the web/API tier), the Worker (executes workflows and renders apps), and the Gallery (the web UI/API surface, typically co-located with the Controller). A single-machine install bundles all roles together; a distributed deployment separates them. The MongoDB database stores users, subscriptions, schedules, workflow metadata, and results-not the workflow files themselves, which live in the persisted workflow directory on the Controller. The AlteryxService Windows service runs on each node and is the process that must be running for the node to participate.
Key planning concepts: sizing workers by CPU cores (a common rule is roughly two execution threads per core, minus headroom), separating the Controller from Workers for scale, placing MongoDB on dedicated hardware in large deployments, and choosing a service account with the right local and network rights. High availability means Controller failover and MongoDB replica sets, not just multiple workers.
Traps candidates miss: assuming workflows are stored in MongoDB (they are on disk); assuming Workers can run schedules independently (the Controller drives scheduling); forgetting that the Gallery is a role, not a separate product; and treating a multi-node deployment as automatically highly available when there is only one Controller.
Worked example: For 8 concurrent workflows averaging 10 minutes each, you need enough worker threads to avoid queueing. If each worker node has 8 cores, plan roughly 12–16 execution threads per node after reserving headroom, so two worker nodes comfortably cover the load with room for spikes.
Rule of thumb: scale out with Workers for throughput, scale up and add failover for the Controller for reliability-these are different problems.