Alteryx Server Implementation cheat sheet

A Server deployment has three tiers: a Controller (web/app + MongoDB metadata), Worker nodes (AlteryxEngine execution), and a shared file store for workflow assets and outputs.

The Controller hosts the Gallery web app and the AlteryxService; Workers run only the engine and connect to the Controller at port 80/443.

MongoDB stores metadata (schedules, users, workflow versions, results); it does not store the workflow package files themselves.

A single-machine install co-locates Controller, Worker, and MongoDB; a distributed install separates them for scale and isolation.

Design for the largest single workflow's memory footprint on any Worker; concurrent jobs multiply that figure.

Persisted data (Gallery DB, file store) must be backed up together; restoring MongoDB alone yields dangling references.

Network ports to plan: 80/443 (Gallery/API), 27018 (MongoDB), and Worker-to-Controller communication.

The Server license controls the number of Workers; a Controller-only license cannot execute workflows.

Run the installer with an account that has local admin rights; the AlteryxService runs under a dedicated service account.

The service account needs read/write on the file store, log directories, and the Alteryx install directory, plus Log on as a service.

System Settings (Alteryx System Settings) is the central console for Controller, Worker, Engine, and Gallery configuration.

Changing the Controller hostname after install requires updating System Settings and MongoDB connection strings on every node.

Engine configuration sets default temp directory and worker concurrency; the temp path must have free space for spill files.

Gallery configuration sets the base URL, SMTP for notifications, and the SSL certificate binding.

After any System Settings change, restart the AlteryxService on the affected node for the change to take effect.

The embedded MongoDB default port is 27018 to avoid colliding with a standard 27017 instance.

Authentication modes: built-in (Gallery-managed), Integrated Windows (NTLM/Kerberos), and SAML 2.0 identity provider federation.

Authorization uses roles: Curator (admin), Artisan (publish/schedule), and Viewer (run/consume), plus per-user or per-group permissions on assets.

Windows Authentication requires the Gallery service account to be trusted for delegation if it must reach SQL Server on behalf of users.

SAML mapping requires a NameID or attribute that matches the Gallery user; unmatched users can be auto-provisioned or rejected.

Run-as credentials for scheduled workflows are stored encrypted; the user must have 'run as' rights and the credential must be valid at run time.

SSL should terminate at the Gallery with a valid certificate; mixed HTTP/HTTPS causes redirect and mixed-content failures.

API access uses keys generated per user in the user profile; keys inherit that user's permissions.

Disabling a user does not delete their schedules; reassign or disable those schedules separately.

Publishing packages the workflow and its dependencies (macros, inputs) into the Gallery; data connections can be embedded or referenced.

Workflows can run on the Worker as the publishing user or as a designated run-as user; the choice determines data access.

Schedules are created in the Gallery UI or via the API and specify frequency, time zone, and the workflow version to run.

The Scheduler queue is processed by the Controller, which dispatches jobs to available Workers.

Chained workflows use the 'Events' or 'Condition' tool to trigger downstream workflows; the downstream must also be published.

A workflow that exceeds the configured execution timeout is terminated and marked as a failed run.

Version history retains prior published versions; you can revert a workflow to an earlier version from the Gallery.

Data connections and credentials used at run time must be visible to the run-as user or the job fails with an access error.

The Admin panel exposes Users, Workflows, Schedules, Data Connections, and Server logs; the Curator role is required.

AlteryxService and Gallery logs live under ProgramData\Alteryx...\Log; the Service log records job dispatch and errors.

The Gallery 'Activity' view shows run history, status, and duration per workflow for troubleshooting.

MongoDB backups should be taken with mongodump against port 27018; restore with mongorestore before starting the service.

Disk monitoring must cover the file store, MongoDB data path, and engine temp directories; full temp disks cause engine failures.

Purge old run results and logs on a schedule to prevent unbounded growth of MongoDB and the file store.

License usage and Worker counts are visible in Admin; exceeding licensed Workers blocks additional execution.

Health checks: confirm the Gallery responds on 443, the service is running, and MongoDB accepts connections.

Scale out by adding Worker nodes behind the same Controller; each Worker adds engine capacity but shares one MongoDB.

Worker concurrency (simultaneous jobs per Worker) is bounded by CPU cores and memory; oversubscription causes OOM and timeouts.

MongoDB is a single point of failure in a default install; a replica set provides failover for metadata.

The Controller is a single point of failure; a secondary Controller with a shared MongoDB and load balancer provides HA.

Performance tuning: increase Worker count, raise concurrency cautiously, and ensure the file store is on fast shared storage.

Large workflows benefit from more Worker memory rather than more Workers; match node sizing to the workload.

Use a load balancer for multiple Controllers; sticky sessions are required for the Gallery web app.

Monitor queue depth; sustained backlog indicates insufficient Workers or per-job runtime growth.

If a scheduled job fails with an access error, verify the run-as user's credentials and data connection permissions.

If workflows won't publish, check the file store permissions for the service account and that the workflow has no unsupported dependencies.

If the Gallery is unreachable, verify the AlteryxService is running, the certificate is valid, and MongoDB is reachable on 27018.

Upgrades must be applied to Controller and Workers in order; back up MongoDB and the file store before upgrading.

Version compatibility: Workers and Controller should run the same Server version; mixed versions cause dispatch errors.

When migrating to a new host, update the Controller hostname in System Settings and MongoDB connection strings on all nodes.

Restoring from backup requires matching Server and MongoDB versions; restore MongoDB before starting the service.

Collect logs from both Controller and Worker when diagnosing job failures; the error may originate on the Worker.