Tilebox Videos

Build a Geospatial Catalog That Stays Up to Date

Wed, 09 Sep 2026 00:00:00 GMT

Watch: Build a geospatial catalog that stays up to date | Tilebox

Turn a bucket of geospatial products into a searchable catalog. This demo defines a metadata schema, backfills 5,000 products in parallel, and queries them by area. A storage event automation then adds new products using the same ingestion code.

Explore the ingestion demo code.

Transcript

Define the catalog schema

0:00 Hey everyone, today I want to show you how to take a bucket full of files and catalog it and make it searchable. So here’s our bucket. We’ve got 5,000 products in here, and each one has two cloud-optimized GeoTIFFs, a preview, and a metadata file. The metadata tells us what the product is, where it’s located, when it was captured, and some extra metadata. That’s what we’ll put in the catalog along with the links to the files.

0:33 First we need to tell Tilebox what fields we want in the catalog. Here that’s the product ID. That’s going to be searchable or queryable, and it’s going to be what we see in the console. And then we have the orbit direction, searchable as well, polarizations, again searchable. This is an array, so it’s repeated. And then a processing version as well as our assets. Time and footprint are already built in. Here we’re adding non-standard or custom things.

1:02 This is all defined in a JSON file. You can give an agent a few sample metadata files to generate it or create the schema by hand in the console. I’ll use this command to create it.

1:17 There it is. In the console we can see the fields that we just defined, but there’s no data in here yet. So let’s bring that data in.

Backfill and query the products

1:26 Here’s the backfill code. It looks for the metadata files in the bucket and then splits them into batches of 500 and starts an ingestion task for each batch. So let’s run this job.

1:44 You can see the ten batches running in parallel here. Each one reads the metadata and adds those products to the catalog. And now we’ve got all 5,000 products in here. Let’s take a look at Italy. We draw a polygon over the area, and we see immediately all the products that cover it.

Ingest new arrivals automatically

2:20 Now I want new products to show up as they arrive, so we register a storage event automation. We tell the automation which files to watch for and what workflow to start when a new file arrives. So we’re watching for new metadata files that arrive in our product folder. Now let me run that script to generate this automation. I’m registering this now, and then we’ll add a product and watch as it gets ingested.

2:54 So let’s try this. If I want to look at anything beyond the data we—we have in our catalog, there’s nothing here yet. So I’ll run a little job to create a new data product in the bucket. You can see how it wrote the two TIFFs and the metadata file. We write the metadata last because that’s what triggers the ingestion. By then all the other files are in place.

3:22 And if we take a look here, this has an automation sign. So this is the job that got automatically triggered. Here’s the job that the automation started. It takes—it takes the path to that new metadata file and passes it to the same ingestion task that we used for the backfill. This time there’s only one product to add.

3:45 So let’s go back to the catalog and reload the same, reload the time range, and we see that on the 28th, after the 25th that we had previously as the end date, we have this one new product that we just ingested. There it is. We added the files to the bucket, and the automation picked them up.

4:09 So we can now search these products by time and area and all the other metadata fields that we made queryable, and new products get added automatically. If you want to try this with your own data, the code is linked below.

Zero to Deployed in 2 Minutes

Fri, 24 Jul 2026 00:00:00 GMT

Watch: Zero to Deployed in 2 minutes | Tilebox Workflows

Go from an empty folder to a deployed Python workflow. This speed run starts a Docker runner, initializes a project, publishes and deploys a release, then submits a Hello World job and checks its logs and execution trace.

The runner and workflow releases are separate, so you can deploy new workflow versions without rebuilding the infrastructure.

Explore Tilebox Workflows.

Transcript

Start a runner

0:00 Hello! Today I want to give you a speed run of Tilebox Workflows Hello World. Typically data pipeline development for geospatial data is quite the beast. It’s hard to parallelize, extremely hard to deploy and iterate, and so I want to show you how lightweight and quick it is in Tilebox.

0:20 The reason I’m doing this now is that we have a new Docker container out which contains the current version of the Tilebox CLI, and that’s enough for you to deploy runners to all kinds of infrastructure, and everyone and their agent knows how to deploy a Docker container co-located with your data.

0:35 So the first step is to start the runner, to deploy the runner. I could use the CLI like this, but I will use the Docker container instead this time. And I don’t know if you noticed, but I’m starting this before I actually have the workflow defined. So this could be on GCP, AWS, Azure, a workstation, laptop, Open Telekom Cloud, on-premise. It doesn’t matter.

Initialize and deploy the workflow

1:03 Then I’ll initialize a new workflow. Take a look at what this generates: a clean Python project with a Python runner. The task in this workflow has an identifier and an execute method, which will log hello and whatever parameter we pass here in the input task. And it registers this task as the capability this runner can execute.

1:29 Next we’ll publish a release. This creates an artifact, and then we deploy that release to the cluster that we assigned that runner to that we started before.

1:41 That runner now automatically fetches the artifact and starts serving it. Then we’ll submit a job.

1:51 We use the same task identifier that we have here, and we’ll send the job to the same cluster that we used here in the deployment. We’ll make it Hello World, of course.

Inspect the job

2:06 And then finally, we can take a look back here at the console, and we see the job completed. When we go to traces, we see it took 245 nanoseconds, and indeed the logs printed Hello World. That’s it.

2:24 About two minutes from an empty folder to a deployed workflow. That’s how fast it is to iterate. Now that you have the runner active, you can just deploy new versions of the workflow, submit jobs to those versions, roll back and so on. Everything accessible through the console or the CLI, and obviously to agents as well. Happy hacking!

Build Geospatial Products, Not Workflow Plumbing

Mon, 15 Jun 2026 00:00:00 GMT

Watch: Build geospatial products, not workflow plumbing | Tilebox overview

Tilebox gives geospatial teams one operating loop for discovering typed datasets, running workflows where the data lives, and inspecting the resulting logs and traces. This overview shows how humans and agents can use that loop without rebuilding the underlying workflow infrastructure.

Explore Tilebox Workflows.

Transcript

Build the product, not the plumbing

0:01 Build the product, not the plumbing. That’s probably the simplest way to explain why we built Tilebox. Earth observation teams typically don’t lack ambition. They want to build monitoring products, models, mission capabilities. They have to build customer-facing analyses. But before they get there, they often spend months rebuilding the same operating layer. Catalogs, queues, retries, credentials. They have to organize runners, set up logs. So in this overview, I want to show you the practical loop that Tilebox gives you to find the data, run the workflow where the data already lives, see what happened, fix what needs change, run it again. That loop is the product.

0:44 Here’s the trade-off we see a lot. A team has a real product to build, but first they need all this infrastructure we just mentioned. So the first year quietly turns into plumbing. And that painful part doesn’t go away either. If the workflow logic and the infra are all tangled together, every experiment gets slower and every product development gets slower.

1:06 Tilebox separates those concerns. Your workflow code can stay focused on tasks, inputs, outputs, and the operating layer handles orchestration, retries, observability, and all these plumbing tasks. And then the runners can live where the work needs to happen. It could be on the cloud, on-premise, or at the edge. You can change the workflow, run it again, see what happened, and improve it without dragging plumbing through every experiment.

1:34 The important thing here, as you might have noticed already, is the loop. In a real workflow or in a real data pipeline, you have to first find the right data, define the work or the workflow, run it somewhere useful, or run it co-located with the data, look at what happened, and then improve it. And the operator of this loop might be a person in the console, or it might be an agent using MCP or the CLI, and the environment might be in the cloud, on-premise, on an agency system, or at the edge. So the operator can change, the environment can change, but the workflow loop should not have to be rebuilt and changed every time. It should remain one loop to discover, define, run, observe, debug, and rerun.

Discover data from a typed catalog

2:24 So in order to achieve that, the first practical move is to centralize metadata, not necessarily the pixels, because the actual pixels are heavy. They may be in different clouds, different data spaces, partner systems, or controlled environments, and moving them can actually be expensive. It’s always, really always slow, or might not be allowed. So instead of copying raw products around, actually what you want to ask or have answered is the simpler question of what data actually exists for a certain time period, for a certain area of interest or place, and a certain workflow.

3:04 And Tilebox datasets or catalogs gives you that as a typed, searchable product. That helps engineers, and it helps agents even more. And agents should not have to invent field names or guess what a dataset contains. It should be able to inspect the real catalog first.

3:23 And this I’m going to demonstrate now. I don’t want the agent to sound confident about satellite data, I want it to check. So I would ask something like, what datasets do I have access to that I could use for oil spill monitoring? And the useful answer should name candidate datasets or collections. That’s the behavior we want. Not magic or guessing, just grounded engineering.

3:55 And what we see here is it already explores the managing Tilebox datasets skill. It lists the datasets, checks the metadata collections for Earth—for data sources and ranks them for usefulness. Maybe it looks at the co-located documentation for each of the relevant datasets. And then it tells us the best primary datasets, which would be Sentinel-1 data, which is a great baseline that has wide coverage.

4:28 We have open data from ICEYE, Umbra, Alaska Satellite Facility. But this is historical data, and it even—and it even tells us that. And then on top of that, it provides us with some good supporting datasets and explanations.

Run workflows where the data lives

4:44 And once you know what data exists, the next question is, where should the computation run? The old pattern is to bring everything to one platform first, to centralize, but that breaks down quickly when data is distributed across clouds or on-premise systems or partner networks or specialized hardware in constrained environments, maybe even in orbit.

5:07 Tilebox Workflows takes a different route. With Tilebox, you define tasks as code, and then runners pick up the work where it should happen. So the workflow logic stays the same, but the execution environment can change. So you can develop locally, run it in the cloud, run it near a certain storage system, or target a controlled environment. But the point is that your workflow does not have to be written around every infrastructure decision. You can co-locate algorithms with the data.

Inspect runs and optimize from evidence

5:40 After the workflow runs, the problem changes. Now the question is, what actually happened? Which tasks ran? Where did they get executed? How long did it take? Which runner picked up what? What did the log say? If the answer is spread across different types of products or cloud consoles, or across notebooks, or logs, or log systems, or certain scripts, then debugging can become trickier or turn into a scavenger hunt.

6:08 And Tilebox keeps that runtime context inside this workflow loop. So all logs and traces are are available both to humans and agents, such that both can work from evidence and—and not don’t have to guess.

6:25 And that’s the second little demo I want to give you. An agent can obviously, like we saw, help before the run when—when they’re finding data or writing code, but they also help after the run. So I could ask in a certain job that I just ran, what was the task class that takes the most time? What has most optimization potential for both wall clock time and compute time? So which task took the longest, and where can we optimize best?

7:01 The useful answer should not be intuition or made up, but it should point to real evidence like spans or the actual task class names and log messages. It should distinguish data loading from compute from output writing, and it should suggest a concrete next experiment. That’s what observability is for in part, to turn the workflow runs into feedback that you can use later on.

7:29 So we see here now that the agent used the managing Tilebox jobs skill, and it started running certain commands. It finds the actual job, it fetches the spans and loads the agent context for that to build an analysis script that it runs ad hoc. And I didn’t have to set up anything for that. It’s paginating through the spans because we have a large number of traces.

8:03 And so let’s take a look at the result. The biggest optimization target is select and cache scene. So this is data loading, and we’re aware of that, but we see the impact, which—which is that 76% of all the time spent here was just loading the data. And within that, because we have support for sub-spans, we see that—we see that downloading the assets versus cropping them or listing them is the biggest contributor. And because on top of observability, it has access to the code, the agent can directly recommend us some changes. For example, to only download the cloud filter band first, the scene classification layer, and only then the other bands.

Put the workflow into production

8:50 So the takeaway or our call to action, if you will, from this presentation is really that if your goal is to spend the next year building geospatial infrastructure, then you might not need us. But if your goal is to get the workflow into production next month or next week, then we should talk.

9:09 You can obviously spend time building that operating layer, or you can use Tilebox and spend those months building the product that customers actually pay for. That’s what we’re trying to make possible, such that physical world data becomes usable software without moving all the data first and without making every team rebuild the same substrate.

From Prompt to Satellite Data Product

Wed, 10 Jun 2026 00:00:00 GMT

Watch: From Prompt to Satellite Data Product: Building a Data Center Growth Tracker with Tilebox

Starting from a prompt, an AI agent writes a workflow, deploys it to cloud compute, and processes satellite imagery to track US data center growth. The first results include false positives, so we inspect the logs and outputs, debug the workflow, and improve it.

The result is a browsable tracker backed by reproducible satellite-data processing.

Explore agentic development with Tilebox.

Transcript

The data center tracker

0:01 This is a tracker for data center growth in the US. It looks at known data center sites, compares satellite images over time, and shows where construction actually took place. You can open a site, compare before and after images, and check why it was flagged.

0:22 But the point of the demo isn’t really the website itself, but how we built it. We built the workflow behind it using an agent running on Tilebox. So let’s get into it.

From prompt to workflow

0:36 Satellite data can answer really practical questions, like where a new infrastructure is being built. But getting from that question to something people can use is usually the hard part. You need data, code, compute, models, and a lot of glue to hold it all together. That’s what we want the framework and agents to handle.

0:54 We’re not asking the agent to write an answer. We’re asking it to build the thing that finds the answer. You describe what you want, and then the agent writes the workflow, runs it on real data, and improves it when it gets things wrong.

1:08 Here’s the prompt that we gave it. Find known data center sites, compare them over time, flag the strongest visible changes, and produce outputs we can use on a website. So the output isn’t a report in this case, it’s the raw material for the demo site.

1:25 The agent then turns that prompt into a set of steps: load the sites, draw a search area around each one, find before and after imagery, measure what changed, and then write out the results. Now the question is something that we can actually run.

1:42 On Tilebox, that plan then is turned into workflow code. So that’s code we can read, we can change it, we can run it again, deploy it at scale. And the way it looks like is the work is split into tasks. One task loads the sites, then each location is processed in parallel. It finds imagery, scores the change, writes the output, and then at the end, everything gets combined. That means we can test the workflow on a few sites quickly, and only then run it for the whole dataset.

Deployment and execution

2:19 And this is not running inside a chat window. So the agent deploys the workflow to its compute cluster. So we don’t rewrite it just because we want to scale it up. Tilebox handles that, the execution around the code.

2:35 As it runs, we can watch the job in Tilebox. We can see the progress, the tasks, the logs, the outputs. The agent can see all of that too. So if something breaks, or if the results look wrong, it can inspect the actual run.

Inspecting and improving the results

2:55 Here’s the first test run. Some of the top results are real construction, but some are not. There are things like vegetation changes. That’s okay, because now we can see the mistakes, and the agent can use those mistakes to improve the workflow.

3:11 That’s exactly why we need workflows to be inspectable. So we can see what went wrong. And then humans and agents can use that data to improve the analysis. So we ask it to fix that.

3:26 It updates the workflow, deploys it again, and runs another test. That takes seconds. This time, we add a visual change score. So instead of only looking at satellite bands, we also compare how the images actually look. That helps separate real construction from noise.

3:44 Now the workflow is good enough to run across the whole list. So we submit the full job. Same workflow, just more sites.

The finished tracker

3:52 And this is the final product, a tracker for data center construction. You can sort by the biggest changes, open a site, and compare the images. You can check the scores and see the overall trend.

4:19 The nice part is that nothing’s hidden. The prompt is actually visible here on the website. We have the whole session recorded. The workflow code is available on GitHub. And the logs and outputs can be recreated. So we can inspect it, change it, and keep iterating.

4:42 And data centers really are just one example. You can use the same pattern for ports, farms, mines, disasters, or any place where you can care about change over time. Tilebox gives the agent a real place to work. It gives it the data, the compute, the deployment, and the feedback from each run.

Try it yourself

5:04 We’re open sourcing the code and the prompts behind this demo for your inspiration. You can clone the repo, run a small version locally, or deploy it to autoscaling clusters in the cloud. You can change the idea or use different sites, different imagery, or algorithms.

5:21 To do that, you can use Tilebox Labs, our free tier, and point your agent at tilebox.com/docs to install skills and the CLI. And if you’re not ready to build yet, join the product updates list on Tilebox.com or come talk to us on Discord.

One Workflow, Three Clusters

Fri, 08 May 2026 00:00:00 GMT

Watch: One Workflow, Three Clusters: Stop Moving EO Data

Package one Python workflow and deploy the same release to three clusters. A single job processes Sentinel-2 near the Copernicus archive, processes Landsat near the USGS bucket, and combines the outputs in a separate assembly stage.

The walkthrough also shows the job graph, progress, and traces in the Tilebox console.

Read the accompanying article: How to Simplify Multi-Source EO Data Pipelines.

Transcript

The workflow

0:04 Creating a multi-source satellite mosaic such as this cloud-free NDVI composite usually takes weeks. You have to download massive archives locally, code custom readers and eat massive data egress fees. Today, I will show you how to do it in seconds with a single unified Tilebox workflow.

0:26 We are building an NDVI Greenest Pixel mosaic using Sentinel-2 and Landsat data. Sentinel-2 lives in Open Telekom Cloud. Landsat is in AWS. We want our final fused product in Google Cloud. Two datasets, three clouds, one workflow.

0:45 In Tilebox, we define our logic as a Python project made up of individual tasks, the smallest units of work. The magic here is in-place processing. We configure our Landsat and our Sentinel tasks so that they run at their source clouds.

1:12 We only move the lightweight processed results to Google Cloud for final assembly, bypassing massive data egress entirely.

Deployment and execution

1:24 We deploy this code to our cluster. Then we can submit a Tilebox job for a mosaic of Madrid in March of 2026. This automatically triggers our workflow runners.

1:40 Here in the console, we can watch it happen in real time. Because of how Tilebox handles subtasks, the orchestration engine automatically parallelizes the Sentinel and Landsat processing across AWS and Open Telekom Cloud simultaneously. We get full visibility into logs, traces and progress across all three environments in parallel.

Results

2:11 Let’s check back in on our job, which is already completed. What used to take weeks of data wrangling to build, now just takes minutes to run.

2:20 Tilebox is the data infrastructure layer built for space. Any sensor, any environment, any algorithm. Head on over to console.tilebox.com to try it out for yourself.

Grounding AI Assistants in Live Data

Tue, 13 Jan 2026 00:00:00 GMT

Watch: Grounding AI assistants in Live Data: Tilebox MCP Server Demo

The Tilebox Model Context Protocol server connects AI assistants to live operational data. This demo shows how tools such as Claude Code and Cursor query Tilebox in real time rather than relying on general knowledge alone.

Read the accompanying article: Connecting AI Assistants with Tilebox.

Transcript

0:04 Managing satellite data often requires switching between API documentation, the Tilebox console, and your development environment. The Tilebox MCP server integrates this context directly into your workflow. It allows you to query your data catalog and job states without leaving your editor.

0:34 The server handles authentication, which enables the agent to query your live satellite data catalog securely. By using natural language, you can retrieve your available datasets and their metadata in real time.

0:52 Let’s query what is the schema for Sentinel-2.

1:02 The Tilebox MCP server provides access to both dataset schemas and official documentation. It identifies available bands and indices and retrieves context-aware code snippets. This ensures that the code that’s generated is technically accurate and uses correct parameters.

1:22 For example, data.cloud_cover references the—the cloud cover here that’s part of the schema of the metadata.

1:32 Because the server has direct access to Tilebox technical specifications, it verifies parameters against the live API. This reduces manual lookups in the console and docs and minimizes config errors during pipeline development.

1:49 The Tilebox MCP server is available right now. You can use the link below or the Tilebox MCP documentation to integrate your satellite data into your development environment.

25 Years of Global Vegetation

Fri, 05 Sep 2025 00:00:00 GMT

Watch: 25 years of global Vegetation Condition

These two visualizations use 25 years of MODIS and VIIRS data. The video above shows Vegetation Condition Index (VCI) reprocessing orchestrated by Tilebox, based on Fraction of Absorbed Photosynthetically Active Radiation (FPAR) data.

Our Earth breathing

The second video visualizes FPAR over the same 25-year period.

Watch on YouTube

Both videos are silent visualizations.

Data source

Seguini, L., Klisch, A., Meroni, M., Vrieling, A., Manfron, G., Atzberger, C., and Rembold, F.: Global near real-time 500 m 10-day FPAR dataset from MODIS and VIIRS for operational agricultural monitoring and crop yield forecasting, Earth System Science Data Discussions, preprint, 2025.

Create a Dataset with Tilebox

Thu, 10 Apr 2025 00:00:00 GMT

Watch: Create a dataset with Tilebox

This 30-second walkthrough shows how to create a proprietary dataset in Tilebox. The recording has no narration.

Explore Tilebox Datasets.