Supervisely SDK for Python: what the Apache-2.0 client actually gives you
Supervisely SDK for Python - convenient way to automate, customize and extend Supervisely Platform for your computer vision task
At a glance
- What is it?
- The supervisely package is a Python client and app framework for the Supervisely computer vision platform. It is worth adopting if you already run that platform and need scripted data access or custom apps; it is the wrong choice if you want a standalone, self-contained labeling or training library.
- Who is it for?
- Adopt the supervisely SDK if your data and labeling work already live on a Supervisely instance and you need scripted access, custom apps, or UI extensions inside it. Do not adopt it if you want a standalone library that labels, trains, and stores data without a platform behind it, because the README frames the SDK as the Python layer of that platform rather than a self-contained tool.
- 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
The problem: platform features stop where your requirements start
The README states the motivation directly: most tools in this space are built as products, and once your requirements go past the basic feature set, you have no way to change them. Supervisely's answer is to call itself a platform rather than a product, with an ecosystem of apps and a Python SDK as the extension layer. The audience follows from that. This is for teams already inside the Supervisely ecosystem who need to script data operations, add a custom step to a labeling workflow, or ship an app that other people can run. It is not pitched at someone who wants a library to drop into an existing PyTorch pipeline. The README lists the platform's scope as labeling for images, videos, 3D point clouds and volumetric DICOM data, visualization and quality control, model training and analysis, AI-assisted labeling, and synthetic data generation. The SDK is the programmatic entry point to that scope, not a replacement for it.
Five levels of extension, from REST calls to embedded labeling UI
The README lays out a ladder of integration depth, and the ladder is the most useful part of the document. Level 1 is the HTTP REST API. Level 2 is Python scripts for automation and integration. Level 3 is headless apps with no UI. Level 4 is apps with interactive UIs. Level 5 is apps whose UI is integrated into the labeling tools themselves. That progression matters when you plan work: a script that bulk-renames classes is a different commitment from an app that draws overlays inside the annotation editor. The README also states a design principle worth noting, that an app is just a web server, so you are not restricted to a Supervisely-specific framework on the server side. Combined with the statement that apps can be private or public, the model is closer to a plugin marketplace than to a library API. The SDK provides the client objects and, for UI apps, ready-made widgets, but the deployment unit is the app, not the import.
Install and first contact
Installation is a single pip package: the README links to pypi.org/project/supervisely, so the command is pip install supervisely. The README does not show a connection snippet, an authentication call, or an environment variable for the server address in the excerpt available here, so treat those as things to confirm in the developer documentation before you write code. What the README does confirm is the release cadence and its shape. Recent releases are numbered v6.74.34, v6.74.35 and v6.74.36, pushed within about a week of each other, and their titles are narrow: a tag-based train/val split fix, customData round-tripping on tags, and audio references on images with image meta round-trip. That is the profile of a client that tracks a moving server API. Pin the version in requirements.txt and read the release notes before upgrading, because a patch-level bump can change how a field is serialized.
Where the SDK is the wrong tool
The clearest limitation is structural: the SDK automates a platform, so without a Supervisely instance there is nothing to automate. If your labeling data lives in S3 and your annotations in COCO JSON, this package does not help you until that data is imported. The second limitation is the release cadence itself. Three releases in six days, each fixing a specific serialization or split behaviour, tells you the client surface is coupled to server-side changes. A team that upgrades casually will eventually hit a version where a field they depend on behaves differently. The README also mentions a built-in cloud development environment as coming soon, which means the current workflow assumes you develop locally and deploy as an app. Finally, the README's claims about scale, including the Fortune 500 and user-count lines, are marketing copy; nothing in the material lets you verify them, and they should not factor into an adoption decision.
The alternative: a standalone library instead of a platform client
The real alternative is not another SDK for the same platform, it is a self-contained toolchain such as Label Studio for annotation plus your own training code, or a framework like FiftyOne for dataset curation. The difference in approach is where the state lives. With Supervisely, datasets, annotations, models and apps live on the platform, and the SDK is a thin client over that state; you get collaboration, labeling UI, and an app ecosystem, but you inherit the platform as a dependency. With a standalone library, the dataset is a file on your disk and the library never phones home, which is simpler to reason about, easier to run in an air-gapped environment, and free of server-version drift. You give up the integrated labeling UI and the one-click app deployment that the README describes. The choice is between owning the pipeline and owning the client of someone else's pipeline.
Maintenance cost and licence
Maintenance has two components here. The first is version tracking: with releases landing every few days, someone on the team has to read the notes and decide when to move, because the changes are behavioural rather than cosmetic. The second is app lifecycle. The README describes reliable versioning through releases and branches, and support for both GitHub and GitLab, with single-click deployment. That implies each app you publish carries its own release history and its own Docker image, so the operational surface grows with the number of apps you ship. On licensing, the repository is Apache-2.0. That is a permissive licence, which generally means you can use and modify the SDK in commercial work, but the SDK is a client for a hosted platform whose own terms are separate and are not covered by the repository licence. Read the platform terms alongside the Apache-2.0 text; this is not legal advice.
Who should adopt it, and what to check first
Adopt it if you are already on Supervisely and your bottleneck is manual work inside the platform: bulk imports, custom quality checks, a labeling aid that needs to sit next to the annotation tool, or an internal app your annotators run with one click. The five-level ladder in the README gives you a way to scope that work honestly before you start. Do not adopt it if your goal is a portable dataset pipeline that survives a change of vendor, or if you cannot run a Supervisely instance in your environment. Before writing code, verify three things in the developer documentation: the authentication and server-address mechanism, which API version your instance exposes, and whether your team is prepared to track a client that ships several times a week. If those three check out, the SDK is a reasonable extension layer. If the third one fails, the REST API may be the cheaper commitment.
Editorial conclusion
Adopt the supervisely SDK if your data and labeling work already live on a Supervisely instance and you need scripted access, custom apps, or UI extensions inside it. Do not adopt it if you want a standalone library that labels, trains, and stores data without a platform behind it, because the README frames the SDK as the Python layer of that platform rather than a self-contained tool. Before committing, verify two things against the developer documentation rather than the README: which API version your target instance runs, and whether the app deployment model (Docker image plus release or branch) matches how your team ships code. The repository layout, the PyPI package name, and the Apache-2.0 licence are all you can confirm from the material here.
Community notes