# FarmVibes.AI fuses satellite, drone and weather data into farm models > FarmVibes.AI is a Microsoft research framework for geospatial machine learning over agriculture, with dataset downloaders, a workflow graph, a notebook library and a local cluster that runs everything on your own machine. It suits a data scientist with labelled field data, and it is not a turnkey product for a grower. **microsoft/farmvibes-ai** — FarmVibes.AI: Multi-Modal GeoSpatial ML Models for Agriculture and Sustainability - Repository: https://github.com/microsoft/farmvibes-ai - Website: https://microsoft.github.io/farmvibes-ai/ - Stars: 904 · Forks: 184 - Language: Jupyter Notebook - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-farmvibes-ai ## The idea is the fusion, not the model FarmVibes.AI is described as a framework for developing rich geospatial insights for agriculture and sustainability, and its central argument is about combining data rather than using it well in isolation. The README makes the case explicitly: models that fuse multiple geospatial and spatiotemporal datasets produce insights such as estimating carbon footprint, understanding growth rate or detecting practices followed, which would be hard to obtain when those datasets are used on their own. Satellite imagery in RGB, SAR and multispectral form, drone imagery, weather data and more can be fused together. The key technique the project describes is about what goes into a model, not which model is used. The idea is to use as input for machine learning data that goes much beyond the types, space and time where the labels are located. The worked example is grain silo detection: the labels exist only in optical imagery, but the model is better served by optical bands together with elevation and radar data, combined with other known agricultural infrastructure, and with images of the same silo across the year. That is a specific and defensible claim about what makes geospatial models brittle. A model that learns from one sensor at one date learns the sensor's quirks at that date, and the claim in the README is that including many data streams along with historical data from nearby or similar locations has been shown to improve stableness, particularly for yield, growth and crop classification problems. The framework is described as generic enough for domains beyond agriculture, while the shipped models are optimized for agriculture and sustainability. ## Three pieces: preparation, notebooks, inference The README organises the system into three parts, and the order is the natural order of a project. The first is data ingestion and pre-processing, so that data can be prepared for fusion models. The second is a library of model training notebook examples, which allow the configuration of pre-processing and the tuning of existing models. The third is a compute engine that supports data ingestion and lets you adjust existing workflows or create new ones around a tuned model. The preparation step is where the configurable workflow lives. Tuning is done through a workflow specified as a directed acyclic graph of data downloading workflows and data preparation workflows, and the preparation operators create the inputs, such as fused pandas arrays or tensors containing the raw data, that the training and inference modules then consume. The notebook library covers four example problems. Detecting practices, with harvest date detection as the case, estimating climate impact through both seasonal carbon footprint and long term sustainability, micro climate prediction, and crop identification. The workflow around a notebook is that you tune a model to a desired performance for the region or season you care about, publish it back into FarmVibes.AI, and the published model becomes available to the inference engine for other areas and other dates. That publish-then-reuse step is the part that makes the framework more than a collection of notebooks. A tuned model is an artefact that outlives the session that produced it. ## Dataset downloaders decide what you can fuse The set of built-in downloaders is fixed and known, and it is worth checking against your own sources before anything else. The README lists satellite imagery from Sentinel 1 and Sentinel 2, US Cropland Data, USGS elevation maps, NAIP imagery, NOAA weather data and private weather data from Ambient Weather. Beyond that list, the framework will take any rasterized dataset you want to make fusion-ready, and the README names drone imagery and other satellite imagery as examples, with custom sensor data such as weather sensors described as a future direction. That is the escape hatch: the downloaders cover the common public sources, and your own raster goes through the same preparation operators. The output of preparation is what a model actually consumes, and the README is explicit that it is a fused array rather than a set of separate layers. A training set for a silo detector is not one optical image, it is optical plus elevation plus radar across several dates for one field. Building that by hand is the tedious part of geospatial machine learning, and it is what the preparation operators are for. The practical consequence is that the downloader list defines the shape of the problem you can solve. A region covered by Sentinel 2 and nothing else will give you optical and multispectral. Elevation and radar need their own sources, and the NAIP and USGS entries cover the United States. Any domain outside agriculture has to source its own data. ## The local cluster, and what runs where The operation mode is the part with real operational weight. The README says the open-sourced part is the local FarmVibes.AI cluster, which uses pre-built operators and workflows and runs them locally on your data science machine, and that any data generated is persisted locally. Underneath that is Kubernetes. The repository's Makefile names the deployments: a cache deployment, an orchestrator deployment, a REST API deployment, a data ops deployment and a worker deployment, each with a matching container repository under the farmai organisation on what the Makefile calls the container registry base, mcr.microsoft.com. The build line is a single command that sets an image prefix and registry base and invokes the farmvibes-ai local setup script. There are also debug ports assigned per service, 5678 for the container and the REST API, 5679 for the orchestrator, 5680 for the cache, 5681 for the worker and 5682 for data ops, and the Makefile has targets to read the current replica count of each deployment from kubectl. So the deployment shape is a five-service Kubernetes cluster with images pulled from a public registry, and the local machine is a client of that cluster rather than a single process. The Makefile also has a base image helper that greps a Dockerfile for its FROM line, which is the usual way to keep a derived image in step with its parent. The user-facing side is simpler and worth noting. Interaction is through a REST API on localhost, or through a local Python client used inside a Jupyter Notebook, for example. The workflows and their implementations are provided via Docker images, with their descriptions in the workflow list documentation. ## Getting started, and the examples that show the shape The README does not give installation commands, and it says so plainly. It refers to the Quickstart guide for where to get started, and for anyone who would rather set up a dedicated Azure virtual machine, it points to the VM setup documentation. Both live in the project documentation site. The examples in the notebooks folder are the fastest way to see what the framework does, and the README lists them with one-line descriptions. The helloworld notebook is a simple example of using the client to run a workflow and visualize the response, which is the correct starting point because it exercises the whole path without needing a specific dataset. The harvest_period notebook shows how an NDVI time series computed on top of Sentinel 2 data can be obtained for a single field and planting season, and used to estimate emergence and harvest dates. The carbon notebook illustrates how to simulate different soil carbon estimates for different agricultural practices, and it leans on the COMET-Farm API for that. The deepmc notebook builds micro-climate forecasts from weather station data using the DeepMC model. Two of these depend on things outside the repository. The carbon example calls an external API, and the deepmc example uses a published model, so a first run of those depends on third parties being reachable. The helloworld and harvest_period examples are self-contained in the sense that they use the built-in Sentinel 2 downloader. The repository layout supports the same story. There is a src directory for the Python client, an ops directory for the operators, a workflows directory for the workflow definitions, a resources directory, an op_resources directory, a docs directory, a scripts directory, a .devcontainer directory for a development container, and a Makefile, a pytest.ini, a .ruff.toml and a pyrightconfig.json for the tooling. ## MIT licensed, no releases, and a dependency on a container registry The licence field on the repository says MIT, with a LICENSE file at the top level. For a research framework that runs on your own machine and keeps its data local, that is a straightforward arrangement, and the fact that generated data stays on the local machine is worth separating from the licence: it matters more for a farm operator than the terms do. On maintenance, the repository is not archived and the last push was on 2026-09-09. There are no GitHub releases, which for a project whose deliverable is a set of Docker images is understandable but also inconvenient, because there is no tag to point an environment at. The images carry their own version inside the farmai registry, and the Makefile builds with a temporary image tag derived from the current timestamp, so the version story lives in the image tags rather than in the repository's release list. The dependency on the registry is the significant operational fact. The workflows and their implementations are delivered as Docker images from farmai on mcr.microsoft.com, so running the framework means pulling and executing images that the repository does not contain. Anyone with a restricted network, or an air-gapped site, has to mirror those images first, and the Makefile's registry and image prefix variables are the place where that gets configured. The repository also carries a SECURITY.md and a SUPPORT.md, plus a code of conduct, which is the standard set for a project hosted under a large organisation's contribution policy. ## Conclusion FarmVibes.AI suits a data scientist who already has labelled agricultural data and wants to fuse satellite, drone and weather sources without writing the geospatial plumbing, and who can run a local Kubernetes cluster. It is the wrong tool for a grower who wants a decision on one field this season, and for a project with no labelled data, since the framework trains models rather than supplying them. Before you adopt it, work through the helloworld notebook to confirm the local cluster starts on your hardware, read the workflow list documentation to see which pre-built operators match your sources, and note that the workflow implementations arrive as Docker images from the farmai registry, which is the dependency your environment has to be able to reach. ## FAQ ### What is FarmVibes.AI and what problem does it solve? It is a geospatial machine learning framework for agriculture and sustainability. It builds models that fuse multiple datasets, such as satellite imagery in RGB, SAR and multispectral bands, drone imagery and weather data, to obtain insights that are hard to get when those datasets are used in isolation. ### Which data sources can FarmVibes.AI download? The built-in downloaders cover Sentinel 1 and Sentinel 2 satellite imagery, US Cropland Data, USGS elevation maps, NAIP imagery, NOAA weather data and private weather data from Ambient Weather. You can also bring in any rasterized dataset you already have and make it fusion-ready, such as drone imagery. ### Does FarmVibes.AI send my data to a cloud service? The open-sourced part is the local cluster, which uses pre-built operators and workflows and runs them on your own data science machine, and the README states that any data generated is persisted locally. Interaction is through a REST API on localhost or a local Python client inside a notebook. ### How are FarmVibes.AI workflows defined? A configurable workflow is specified as a directed acyclic graph of data downloading workflows and data preparation workflows. The preparation operators create the inputs, such as fused pandas arrays or tensors, that the training and inference modules consume, and the actual workflow implementations are provided as Docker images. ## Sources - [Issues](https://github.com/microsoft/farmvibes-ai/issues) - [License: MIT](https://github.com/microsoft/farmvibes-ai/blob/main/LICENSE) - [microsoft/farmvibes-ai on GitHub](https://github.com/microsoft/farmvibes-ai) - [Project website](https://microsoft.github.io/farmvibes-ai/) - [README](https://github.com/microsoft/farmvibes-ai/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-farmvibes-ai