sqi (pronounced "sky") is an open source distributed task and render farm manager built for modern production pipelines. It is designed to run simply on a handful of local workstations and scale to hybrid on-premises and cloud infrastructure without changing how you work.
Status: Pre-release. Active development beginning mid-2026. Contributions, feedback, and discussion welcome.
The render farm management space is in an awkward moment. Legacy on-premises systems are aging out of active development. The primary cloud-native alternative requires deep AWS infrastructure investment, locks you into a single provider, and introduces workflow constraints that don't match production realities. A lot of studios are looking for a third option.
sqi is that option. It draws on years of experience building and operating Smedge (Uberware's long-running render farm product) and applies those lessons to a clean, modern architecture that works wherever your compute lives — local network, cloud, or both.
Simple by default. A single binary gets a working farm. Workers on other machines run a second binary and can find the server automatically. No external database, no message broker configuration, no cloud account required to get started.
Scalable when needed. The same software that runs your five-machine studio farm can be deployed in a distributed, high-availability configuration with a separate database, message broker, and workers across multiple cloud providers. The upgrade path is configuration, not migration.
Not tied to any cloud provider. Workers run on Linux, macOS, and Windows — bare metal, VMs, or containers. Cloud compute locations are supported across AWS, GCP, Azure, and any provider that can run a container or a binary. Your control plane runs where you want it.
OpenJD compatible. sqi adopts the Open Job Description format as its native job execution layer. Jobs authored for OpenJD-compatible tools work with sqi without reformatting. This is a real standard designed for portability, not a proprietary format.
General purpose. Rendering is the primary use case and the domain sqi is designed around, but the job model is general. Any workload expressible as a command with defined inputs, outputs, and environment is a valid sqi job — simulation, transcoding, machine learning pipelines, data processing, software development, or anything else a studio runs at scale.
-
Farms and queues organize work hierarchically. Configuration — scheduling policy, worker affinity, license limits, storage bindings — can be set at the farm level and overridden per queue, so you're not repeating yourself on every job submission.
-
Products and presets are the authoring layer above raw job descriptions. A product defines a class of work (an Arnold render, a Houdini sim, an ffmpeg transcode) in terms of user-friendly parameters and how they map to commands. A preset is a ready-to-use product definition for a specific tool, installable from a community library directly through the web UI.
-
Community preset library is a public repository of product presets covering major DCCs — Arnold, Blender, Houdini, Maya, Nuke, After Effects, Cinema 4D, and more. Browse, install, and customize presets from within the
sqiinterface. Community contributions welcome. -
Named storage locations provide a clean abstraction over where data lives. A location named
nas_showsmight resolve to/mnt/nas/showson a local Linux worker,Z:\showson a Windows worker, ands3://studio-bucket/showson a cloud instance. Jobs reference location names; workers resolve them. Built-in support for S3-compatible object storage (AWS S3, Backblaze B2, Cloudflare R2, MinIO, and others). -
Path translation handles the fact that different applications deal with cross-platform and cross-environment paths differently. Product definitions declare how paths should be resolved — baked into the command line, passed as remapping arguments, set as environment variables, or staged locally before execution.
-
License pool management tracks concurrent license usage across all workers. Tell
sqiyou have 20 Arnold render licenses and it ensures no more than 20 Arnold tasks run at once, globally, across every compute location. Bring-your-own-license —sqienforces your limits, not its own. -
Pull-based workers register with the farm and pull assigned tasks rather than receiving pushed assignments. Workers can be added, removed, and scaled without the scheduler needing to manage their lifecycle. This makes auto-scaling and ephemeral cloud workers straightforward.
-
Layered authentication — from no auth at all (local network trust, appropriate for small private farms) through local accounts, LDAP/Active Directory, and OAuth2/OIDC for SSO. Designed so simple deployments stay simple and enterprise deployments get what they need.
-
Web UI is the primary interface. No required desktop application. Real-time job and worker status, log streaming, preset management, product configuration, and farm administration — all in a browser.
-
DCC submitter widgets in Python/Qt for in-application submission from Maya, Houdini, Nuke, and other tools. A Python client API covers scripted submission and pipeline integration.
-
Optional LLM integration (disabled by default) adds natural-language interfaces for farm management — explain a job failure in plain English, manage workers or job priorities by description, filter and search jobs conversationally. Pluggable provider model: bring your own API key (OpenAI, Anthropic, Azure, or a local Ollama instance).
sqinever requires or bundles an AI service.
All-in-one (simple mode)
sqi-server # runs the scheduler, API, web UI, everything
sqi-worker # run on each render node — finds the server automaticallyOn a local network, workers discover the server via mDNS and connect without any configuration. Open a browser, start submitting. That's it.
Distributed (production mode)
Separate scheduler, API server, and NATS message broker for high availability. PostgreSQL for durable state. Workers connect to the message broker directly. Deployable via Docker Compose or Kubernetes.
Both modes run the same software. The difference is configuration.
sqi is in early development. The immediate focus is the working core: scheduler, pull-based workers, OpenJD job execution, basic web UI, and the product/preset system. Authentication, distributed deployment, cloud worker support, and the community preset library follow.
This is a real project with a concrete development commitment, not a design document waiting for funding. Feedback on priorities is welcome — open an issue or start a discussion.
See ROADMAP.md for more information about the design and implementation plan.
Contributions are welcome at all stages — code, preset definitions, documentation, bug reports, and design discussion.
The community preset library in particular benefits from people who know their tools well. If you have a working submission setup for a DCC or tool and want to share it as a sqi preset, that's a valuable contribution that doesn't require any Go or server-side knowledge.
See CONTRIBUTING.md for guidelines.
sqi is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0). This means you can use, modify, and self-host sqi freely. If you offer sqi (or a modified version) as a network service, the AGPL requires you to make your source available.
A commercial license is available for organizations that require it. Contact robin@uberware.net.
sqi is built by Uberware, the company behind Smedge, a render farm manager with over two decades of production use. sqi is a clean-break successor designed for the infrastructure realities of the next decade.