Machines & Fleet

Documentation Index

Fetch the complete documentation index at: https://trickest.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Overview

On this page you will learn what machines and fleets are in Trickest, how they are used to run workflows, and how they relate to the rest of the platform.

​

What are Machines and Fleets

Machines are the compute resources that execute your workflows. Each run needs one or more machines to run the workflow’s nodes. Trickest provides managed machines (virtual machines run by Trickest). You can also attach self-hosted machines: your own devices or servers that you register with the platform so they can be used for execution. A fleet is a group of machines used together for workflow execution. There are two fleet types: Managed fleet (Trickest-managed machines; you use them without extra setup) and Self-hosted fleet (machines you attached to your account; you run workflows on your own infrastructure). When you run a workflow, you choose which fleet to use; the execution engine then assigns machines from that fleet to the run.

​

Why Machines and Fleets Exist

Workflows need somewhere to run. Machines and fleets give you that: either Trickest’s managed capacity so you can run without provisioning hardware, or your own machines for data locality, compliance, or custom environments. Fleets group machines so you can say “run this on managed” or “run this on my self-hosted set.” The number of managed machines available to you is defined by your subscription; self-hosted machines are limited only by what you attach.

​

How It Works

Managed machines: Trickest allocates a fixed number of virtual machines to your account. They have defined CPU and memory (e.g. Community and Enterprise tiers). Machines can be in different states: idle (available), up (activated and ready), running (executing a workflow), or in error. You do not configure or maintain them; you run workflows and the engine assigns machines from the managed fleet. Self-hosted machines: You install and register an agent (or equivalent) on your own hardware. Once attached, those machines appear in your self-hosted fleet. They can be any device or OS that the platform supports. You choose the self-hosted fleet when executing a workflow when you want the run to use your infrastructure.

Note Self-hosted machines that have been inactive for 30 days are automatically removed from your fleet. To keep a machine registered, run the agent at least once within that window; if a machine was removed, re-register it from Settings > Fleet > Self-Hosted.

Distribution: You can run a workflow on a single machine or spread it across multiple machines. The execution engine, together with workflow structure (e.g. parallel nodes, distributed node outputs), can distribute execution so that different parts of the workflow run on different machines. That lets you scale heavy or parallel workloads.

​

Resource Allocation on Managed Fleets

When a workflow runs on a Managed fleet, the platform decides how many machines to use and adjusts that number while the run is active. You do not size the run yourself.

​

Starting a Run

Before the run begins, the backend looks at the workflow and counts the starting nodes (the nodes that can execute immediately). It submits the run to the execution engine with that many machines. A run cannot start without at least one available machine in the fleet. If the fleet is full at submission time, the run waits until a machine becomes available.

​

Scaling Up and Down

While the run is active, the backend monitors the job queue and adjusts the number of machines:

• Scale up: if jobs are pending and the fleet has capacity, the backend adds machines to the run, up to the number of pending jobs.
• Scale down: when a machine finishes its current job and has nothing else to do, the backend turns the machine off so the slot can go to another run.

Both directions apply a short time threshold rather than reacting instantly. This avoids wasteful churn:

• For scale-up, very short jobs (a few seconds) often complete before a new machine can be provisioned and joined to the run. By the time the new machine is ready, the existing machines have already drained the queue, and the new machine would be turned off immediately.
• For scale-down, a machine that just went idle is the cheapest place to run the next job. Keeping it alive briefly avoids a fresh provisioning cycle if more work arrives.

The thresholds are tuned so that scaling reflects sustained demand, not momentary spikes or lulls.

​

Fleet Limits and Sharing

Each fleet has a hard machine cap. A single run can never exceed it: thousands of jobs can sit in the queue while the run uses only the fleet’s available machines. Multiple runs can be active on the same Managed fleet at the same time. They compete for the fleet’s pool, and machines are reassigned to whichever run needs them as soon as they become free. There is no manual reservation; the backend continuously rebalances based on each run’s pending queue.

​

How It Relates

• Workflows: Workflows are executed on machines. When you run a workflow, you select a fleet (managed or self-hosted); the engine runs the workflow’s nodes on machines from that fleet. See Workflows.
• Runs: Each run is executed on one or more machines. Run status and node status reflect whether machines are assigned, running, or finished.
• Solutions: Solution workflows run on the same machine and fleet model; you choose the fleet when running the Solution. See Solutions & Database.

​

Common Patterns

• Running most workflows on the managed fleet for simplicity and no infrastructure setup
• Attaching self-hosted machines when you need execution on your own network, data to stay on-premises, or specific hardware or OS
• Choosing the self-hosted fleet at run time for sensitive or regulated workloads
• Distributing execution across multiple machines for large or parallel workflows to reduce total run time

​

Next Steps