Skip to main content
​
Deploying a workflow release to a cluster and rolling the cluster back to an earlier release in the Tilebox Console

​
Workflow Management and Operations

Tilebox now exposes more workflow operations across the Console, SDKs, CLI, MCP server, and runner deployments. You can manage workflow releases and clusters from the Console, filter jobs by compute location, schedule automations in local time, and start release runners from an official Tilebox container image.

​
What changed

  • Workflow management in the Console. Create and edit workflows, inspect release history, tasks, runtime configuration, and artifacts, and deploy or undeploy releases across clusters. You can also delete workflows or unpublish individual releases without deleting existing jobs.
  • Redesigned cluster pages. The Console now provides a clearer cluster overview and dedicated detail pages for deployed workflow releases and tasks. From a cluster page, you can edit the cluster, deploy another workflow or release version, or undeploy a release. Protected default clusters are clearly marked.
  • Job filtering by cluster. Filter jobs by one or more cluster slugs in the Console, Python and Go SDKs, and CLI. This makes it easier to inspect work assigned to specific development, production, or specialized compute infrastructure.
  • Expanded MCP coverage. AI agents using the Tilebox MCP server can manage clusters, workflows, releases, and jobs; inspect logs and spans; view automations; and query decoded dataset datapoints, including spatial queries.
  • Timezone-aware Cron schedules. Cron automations now accept standard five-field expressions with lists, ranges, steps, named weekdays, and named months. Prefix a schedule with CRON_TZ=<timezone> to use an IANA timezone, or use helpers such as @hourly, @daily, @weekly, @monthly, and @yearly. Schedules without a timezone continue to use UTC.
  • Official runner image. The release-runner image is available at ghcr.io/tilebox/runner. It includes the Tilebox CLI, uv, Python 3.12 through 3.14, Git, Git LFS, and common geospatial build dependencies. The image runs tilebox runner start by default and can be configured for a cluster through environment variables.
For example, this schedule runs at 09:00 on weekdays in Vienna and follows daylight saving time automatically:

​
Start here

Manage workflow deployments

Deploy workflow releases to clusters and control what release runners can execute.

Configure Cron triggers

Define recurring jobs with standard Cron expressions, timezone prefixes, and schedule helpers.

Deploy to your compute

Run workflow releases on compute environments you control.
​
Closed workflow iteration loop from deploy to run to observe to fix

​
Agentic Workflows

Tilebox Workflows now supports workflow release publishing and cluster deployments. This adds a new release-based execution path to the workflow orchestrator: package a Python workflow project, publish an immutable release, deploy it to a cluster, run it on release runners, and inspect the resulting job logs and execution traces.The release path is designed for closed-loop workflow iteration by developers and agents. An agent can edit workflow code, publish a release, deploy it to a development cluster, submit a test job, inspect the failed task logs or spans, apply a fix, and retry or submit the next job without leaving the same command-line workflow.A typical iteration looks like this:

​
What changed

  • Release runners. Release runners run in an environment you control, watch a cluster, load the deployed releases for that cluster, and execute compatible tasks without rebuilding the runner process for every workflow code change.
  • Workflow release publishing. A workflow is now a long-lived object with a stable slug, and each release captures a concrete version of the workflow project, runtime entrypoint, selected files, and discovered task identifiers.
  • Project-local workflow configuration. tilebox.workflow.toml binds a repository directory to a workflow slug, build inputs, runtime entrypoint, and optional deployment targets, so commands can use the local project as context.
  • Cluster deployments. Publishing and deploying are separate steps. A release can be deployed to one or more clusters, and different clusters can run different releases of the same workflow.

​
Start here

Iterate on workflow releases with agents

Use an AI coding agent to edit, publish, deploy, run, inspect, and retry workflow releases.

Workflow configuration

Configure tilebox.workflow.toml, release contents, runtime entrypoints, and deployment targets.
​
Job Execution Trace View

​
Workflow Observability

Tilebox Workflows now includes built-in observability for jobs and runners. Tilebox captures workflow logs, traces, task status, and runner context, then correlates them with jobs and tasks.The Console includes a built-in explorer for workflow observability, so you can inspect task logs, trace timing, failures, and runner behavior from the job view.See the Workflow observability documentation for examples and integration options.
​
Optional Tasks

​
Optional Tasks

Subtasks can now be marked as optional when submitting them. If an optional task fails, the job continues instead of being canceled. Failed optional tasks are marked with the state FAILED_OPTIONAL, and any remaining queued sibling tasks in the same optional subtask tree are automatically SKIPPED. Tasks that depend on an optional task still execute even if it failed.This is useful for workflows where certain steps are not critical and their failure should not prevent the rest of the job from completing.See the optional tasks documentation for details and examples.
​
MCP Server

​
MCP Server for Datasets and Workflows

Introducing the Tilebox MCP server, which provides tools for AI agents to access and interact with Tilebox datasets and workflows.
​

​
Job List View: Complete Redesign and Filtering Improvements

Job List View Improvements
The job list view in the Tilebox Console has been completely redesigned:
  • Infinite scrolling for long job lists
  • Improved filtering and search
    • Filter by state
    • Filter by automation
    • Filter by time range
    • Filter by name
    • Or an arbitrary combination of the above
  • Better readability and organization
  • Added progress indicators
  • Added execution stats
  • The same new filter options are also available in our Language SDKs
​

​
Spatio-Temporal Explorer Redesign

Console Improvements
The dataset explorer in the Tilebox Console has received a major upgrade for spatio-temporal datasets:
  • Overhaul of the Explorer view for Spatio-temporal datasets
  • Display datapoint footprints directly on the map
  • Display thumbnails and quicklooks of datapoints directly in the Console
  • Added code snippet for storage access to the Export as Code dialog
​

​
Progress Indicators

Progress Indicators
User defined progress indicators for jobs are now available. See the progress documentation for more details.
​

​
Go Client

Tilebox Go Client
Excited to announce the release of the Tilebox Go client!Features
  • Datasets client
  • Statically typed dataset types
  • CLI to generate dataset types
  • Workflows client
  • Go runners
To get started, check out the Go SDK documentation.
​

​
Spatio-Temporal datasets

Spatio-Temporal Datasets
Spatio-temporal datasets are officially out, fully supported in all languages and available as a category to create in custom datasets!The core problems that spatio-temporal datasets solve are
  • finding relevant data quickly (e.g. all Sentinel 2 granules along the US coastline, last year),
  • storing auxiliary geographically coded data (e.g. weather station data, ground truth data),
  • cataloging higher level data and results
Here’s a short video on performance and core capabilities.We’re excited about this as cataloging has until now been an unsexy but hard problem, and it’s great to finally have a solution out thereMore information
​

​
Custom Datasets

Custom datasets
Create your own custom datasets!
  • statically typed
  • with clients in Python and Go
Use it to organize anything from telemetry, raw payload metadata, auxiliary sensor data, configuration data, or internal data catalogs.Quickstart
  1. Specify the data type in the Console
  2. Create a collection
  3. Use client.ingest() to ingest a xarray.Dataset or pandas.DataFrame
  4. Query away!
For detailed instructions, check out the Build a spatio-temporal catalog how-to guide.