Run the work where your data is.

Keep the compute close to your data. Tilebox coordinates workflows across runners in your cloud, Kubernetes, and on-premises systems. You choose where each part runs.

Read the deployment guide Talk to us

TileboxWorkflow state · releases · jobs · telemetry

Tasks · State · Telemetry

Your cloud

RunnerCluster: cloud-prod

Cloud data

Your premises

RunnerCluster: on-prem-prod

Local data

Example topology. Each runner claims compatible tasks from its own Tilebox cluster and accesses data from its execution environment.

A clear boundary between coordination and compute.

Keep workflow state in Tilebox and place runner processes where the work belongs. You choose the infrastructure; Tilebox does not provision it for you.

Tilebox manages

Workflow state, published releases, cluster deployments, jobs, logs, and traces.

You operate

Runner processes, compute capacity, runtime dependencies, credentials, network access, and access to your data.

Running a runner on premises is not the same as self-hosting the full Tilebox platform. The runner still connects to Tilebox for coordination.

Send each task to the compute it needs.

Put data-intensive work near its source files and GPU tasks on machines with the right hardware. Use clusters to route work to runners that can execute it.

A runner must match the task’s cluster and implementation. You control that placement, along with capacity and network access. Separate clusters also keep development work off production runners.

Read about runners or explore workflow execution .

Example: production cluster

JobProcessScene · v1

Deployed releaseIncludes ProcessScene · v1

Connected runnerCan execute ProcessScene · v1

Same cluster + compatible task

If work stays queued, check the job’s cluster, the deployed release, and the connected runner.

Fit the runner into your environment.

Start on a local machine. Move to the process manager or container platform your team already operates.

Across environments: Connect runners in different locations to Tilebox. Route tasks to the clusters with the data access and compute they need, while keeping one view of the workflow’s execution.
Local machine or VM: Run the CLI directly on a machine with the required data access and dependencies. Use your process manager to keep the runner running.
Containers and Kubernetes: Use the official runner image or extend it for your dependencies. Your platform restarts processes and scales the number of runners.
On-premises compute: Place runners on systems you control, with access to local data and a connection to Tilebox. Check network and security requirements before rollout.

Release runners pick up cluster deployment changes without rebuilding the runner image. For custom process control or Go workflows, use a direct SDK runner and manage its rollout yourself.

Compare deployment options in the guide

Start with the constraints that matter.

Before choosing an environment, map the data, access, and runtime requirements of one representative workflow.

Connect that plan to your data layer and the agents developing the workflow .

Where is the data, and which systems can read it?
Can runners reach Tilebox and download release artifacts?
What CPU, memory, GPU, and runtime dependencies does the code need?
Who owns credentials, restarts, and scaling?
Which clusters should separate development from production?