roboflow-python: the client library for the Roboflow platform, not a standalone toolkit
The official Roboflow Python package. Manage your datasets, models, and deployments. Roboflow has everything you need to build a computer vision application.
At a glance
- What is it?
- roboflow-python is the official Python client for Roboflow's hosted dataset, training and inference services, plus a CLI and a slim install for constrained environments. It is a platform SDK: almost every method is a network call against Roboflow, and that shapes who should adopt it.
- Who is it for?
- Adopt roboflow-python if your datasets and trained models already live on Roboflow and you want scripted uploads, version creation, weight deployment and hosted inference from Python or a shell. Do not adopt it if you need to train and serve models entirely on your own infrastructure, or if you want a library that works without a Roboflow account; the client has no offline mode in the documented surface.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What roboflow-python actually is: a client for a hosted service
The README is explicit that the package exists to interact with models, datasets and projects hosted on Roboflow. That single sentence determines everything else. This is not a training framework you run locally, and it is not an inference runtime you embed. It is a Python surface over Roboflow's platform, and the four capabilities listed in the README all describe remote operations: create and manage projects, upload images and annotations, start training runs on Roboflow, and run inference against hosted models or against Roboflow Inference self-hosted. The intended user is a team that has already decided to keep its dataset and model lifecycle on Roboflow and wants to drive that lifecycle from code rather than from the web application. If your images never leave your own storage, the package has little to offer you beyond the CLI's search-export path, which still runs against a workspace.
The Workspace, Project, Version model and how calls map onto it
The library mirrors the ontology of the Roboflow application, and the README states that the workspace, project and version parameters are the same identifiers you see in app.roboflow.com and universe.roboflow.com URLs. That is a deliberate design choice: the object graph in your script matches the object graph in the browser, so a URL is enough to locate a resource. The nesting is workspace, then project, then version. Workspace-level methods include create_project, upload_dataset, search_export and listing projects; the README also mentions active learning, where predictions from one project's model are used to upload images into another project. Project-level methods cover metadata, listing versions, generating a new dataset version with preprocessing and augmentation settings, training, and uploading images and annotations. Version-level methods cover deploying model weights and running predictions. One detail worth noting: a version can own several trained models, and version.models() returns all of them, which is why the quickstart indexes the result with [0] rather than treating it as a single model handle.
Installation paths: roboflow, roboflow[desktop] and roboflow-slim
The base install is pip install roboflow, and the README requires Python 3.8 or higher. Desktop features come from pip install "roboflow[desktop]". The more interesting option is roboflow-slim, described as a lightweight package for vision events, workspace management and the CLI only, with no image processing, inference or training. The README states it skips OpenCV, NumPy, Matplotlib and Pillow and reduces install size from roughly 400MB to roughly 50MB, and names embedded devices, CI pipelines and serverless environments as the target. Both packages share the same codebase and version, so there is no API fork to track. That size claim is the kind of number you should confirm in your own environment rather than take as universal, since dependency resolution varies with platform and existing packages. Source installs are also documented: clone the repository, create a virtual environment with python3 -m venv env, activate it, and run pip install .
Authentication and the first real commands
Two authentication paths are documented. The interactive one is import roboflow followed by roboflow.login(). The scriptable one constructs the client directly: rf = roboflow.Roboflow(api_key=""), with the README pointing at the Roboflow documentation for retrieving a key. For anything automated, the constructor form is the only sensible choice, since login() implies a browser or prompt step. From there the quickstart shows the shape of a full cycle. workspace.create_project takes project_name, project_type (object-detection, classification, instance-segmentation or semantic-segmentation), project_license (MIT, or private for paid customers) and annotation. workspace.upload_dataset takes dataset_path, num_workers, dataset_format, project_license and project_type; the README lists yolov8, yolov5 and Pascal VOC as supported formats. Weights go up through version.deploy(model_type="yolov10", model_path=..., filename="weights.pt"). Inference is model.predict(img_url, hosted=True).json(). Note that hosted=True is an explicit argument, which tells you the same call can target a self-hosted Roboflow Inference instance instead.
The CLI and search-export as a dataset pipeline shortcut
Installing the package also gives you command-line access to part of its functionality, documented in CLI-COMMANDS.md, so you can avoid writing Python for routine operations. The clearest example in the README is search-export. In Python it is workspace.search_export(query="class:person", format="coco", dataset="my-project", location="./my-export"), and the query language accepts forms like class:person, tag:review or the wildcard *. The CLI equivalent is roboflow search-export "class:person" -f coco -d my-project -l ./my-export. The format argument covers coco, yolov8, yolov5, voc and others according to the README. This is the one part of the package that could plausibly be useful outside a Roboflow-centric workflow: if your images already sit in a workspace, search-export turns a query into a training-ready directory tree in one command, with dataset and location both optional. It is still a server-side operation, so the export depends on what the workspace contains and what the account is permitted to read.
Where the client model becomes a constraint
The main limitation follows from the architecture rather than from any bug. Every meaningful method is a network call against Roboflow, so the package inherits the platform's availability, rate limits, authentication and account tier. The README itself flags one tier boundary: private projects are only available for paid customers, which means project_license="private" is not a free-tier option. Training is started on Roboflow, not locally, so you cannot use this package to train on your own GPUs without the platform in the loop. The slim install is a second constraint disguised as a feature: if you choose roboflow-slim for a small container and later need predict or deploy, you need the full package, and the dependency weight comes back. There is also a documentation gap worth naming. The README covers the happy path well but says nothing about retry behaviour, pagination on large project listings, or what happens when an upload partially fails across num_workers threads. Those are exactly the questions that surface in production pipelines, and the material here does not answer them.
How this differs from running your own stack
The obvious alternative is not another SDK but a self-managed stack: a labeling tool such as CVAT or Label Studio for annotation, an object storage bucket for images, and a training and serving setup built on PyTorch or Ultralytics with your own inference server. The difference in approach is where the state lives. With roboflow-python, the dataset, its versions, the trained weights and the inference endpoint are all owned by Roboflow, and your code holds identifiers. With a self-managed stack, your code holds the artifacts and you own the versioning, the storage layout and the serving layer. The trade is operational burden against control and cost predictability. A second, narrower alternative is Roboflow Inference on your own hardware, which the README references and which the hosted=True flag implies you can target instead of the hosted endpoint; that keeps the model runtime local while the dataset and training history stay on the platform.
Maintenance, versioning and licence
The release cadence visible in the repository is regular: v1.4.0 in July 2026, v1.4.1 in August with the note "Annotation administration SDK & CLI", and v1.4.2 in September, with the last push to main on 2026-09-08. The v1.4.1 label is the useful signal, because it tells you the package tracks platform features rather than only fixing bugs, which means upgrades can add surface area you did not ask for. Pinning a version in requirements.txt is the practical response, and the shared codebase between roboflow and roboflow-slim means a single pinned version covers both installs. The licence is Apache-2.0, which is permissive and generally suitable for commercial use, but the licence covers the client code, not the service it talks to. Using the package still means accepting Roboflow's terms, quotas and pricing for the workspace, training and inference calls your code makes. That distinction is the one to keep straight when reviewing dependencies.
Editorial conclusion
Adopt roboflow-python if your datasets and trained models already live on Roboflow and you want scripted uploads, version creation, weight deployment and hosted inference from Python or a shell. Do not adopt it if you need to train and serve models entirely on your own infrastructure, or if you want a library that works without a Roboflow account; the client has no offline mode in the documented surface. Before committing, verify three things against your own workspace: that workspace.upload_dataset accepts your dataset_format (the README lists yolov8, yolov5 and Pascal VOC), that version.deploy supports your model_type (yolov10 appears in the example), and whether roboflow-slim covers the calls you need, since it deliberately excludes image processing, inference and training dependencies.
Community notes