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.
Your cloud
Your premises
A clear boundary between coordination and compute.
In the hosted service, Tilebox operates the control plane: the APIs and services that store metadata and coordinate work. Your team supplies the compute. Review each boundary before approving a deployment.
- Control plane and metadata
- Tilebox stores the catalog metadata and file references you ingest, workflow state, task inputs, jobs, logs, and traces. With release runners, Tilebox also stores the workflow artifacts you publish. Direct runners use code deployed through your own CI/CD pipeline, without uploading workflow artifacts.
- Imagery and output files
- Files can remain in your storage or at their provider. Your application or runner reads them using the access you configure. Your code chooses where to write outputs. A catalog reference does not grant storage access or imagery licensing rights.
- Runners and credentials
- You operate runner processes, hardware or cloud capacity, runtime dependencies, and scaling. Supply Tilebox and data-provider credentials through your deployment system or secret manager.
- Network connections
- Runners initiate connections to the Tilebox API to claim tasks and report progress; no inbound network access to your runners is required. Your data can remain accessible only from your own environment. Release runners also download code artifacts. Allow outgoing access to the Tilebox services, package registries, and external APIs your code needs.
Running a runner on premises is not the same as self-hosting the full Tilebox platform. For a restricted network, review endpoint allowlists, data residency, identity, and support access with your security team and Tilebox before rollout.
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.
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 guideInfrastructure questions
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 .
Can I run workflows in my own cloud or on premises?
Yes. Runners execute your code on local machines, cloud VMs, Kubernetes, or on-premises systems you control. Tilebox manages workflow state, releases, jobs, logs, and traces. You provide the compute, runtime dependencies, and data access. The deployment guide includes Docker and Kubernetes examples.
Do I have to move my data into Tilebox?
No. Tilebox can catalog metadata and references to files in your existing storage. Runners read those files from their execution environment using the access you provide. Your workflow code determines what to read, copy, and write. Workflow state, task inputs, logs, and traces still go to Tilebox.
Do I need to rewrite my code or replace my existing systems?
You can keep your processing code, libraries, databases, and APIs. Wrap the work you want Tilebox to coordinate in tasks, define their inputs and dependencies, and run them on compatible runners. Your code still handles database and API calls, credentials, and outputs. Start with one workflow; you do not need to migrate every pipeline at once.
Can runners work without an internet connection?
The cloud-connected runners described here need access to the Tilebox API to claim tasks and report progress. Release runners also download workflow release artifacts. A network without access to those services cannot use this hosted setup. On-premises deployments and a headless daemon are also available. Discuss your deployment with us to choose the setup for your network and security requirements, including where the control plane, metadata, telemetry, and release artifacts run. For sovereign, GovCloud, or in-orbit deployments, we can review the specific environment and support requirements with your team.
Can one workflow use both cloud and on-premises compute, including GPUs?
Yes. A workflow can submit tasks to different clusters with runners near the required data or hardware. For example, one task can prepare data on premises and another can process it on a cloud GPU. You configure the routing, data access, and runtime on each machine. You provide the GPUs and can extend the runner image with the libraries your code needs. For CUDA workloads, use a compatible NVIDIA base image and configure the GPU drivers and container runtime on the host. See the runner container guide.
Who manages credentials, scaling, and compute costs?
Your team operates the runners and pays for the underlying cloud or hardware. Built-in secret management is on the roadmap. For now, provide runner credentials through your deployment system or secret manager. Use your VM or container platform to restart processes and scale the number of runners. New runners can pick up queued tasks while a workflow is running. Tilebox pricing covers Tilebox usage, not your compute costs.
What happens if a task fails or a runner stops?
Tilebox records task failures so you can inspect the error, fix the cause, and retry the job without rerunning all completed work. If a runner stops sending heartbeats, Tilebox can retry its task on a compatible runner, subject to retry limits. A task can run more than once, so make database writes and other side effects safe to repeat. See failure and retry behavior.