IDEA Organizations & Tenancy

Andi Lamprecht ·2026-05-11· 10 min read· Draft

Decision Log

On 2025-09-24, the Change Control Board voted 4–0–1 (yay–nay–absent) to approve the concept.

Problem Statement

Our products are not ready for adoption and use by external users. This is because some of the functions of our products, such as applying an airspace authorization or preventing flight over uncharted ground risks, are centrally executed by DroneUp (i.e. any change performed by the function applies to ALL Uncrew users). External users, however, require products that reflect their specific privileges, limitations, and operational contexts, while also ensuring the security and privacy of their data. Additionally, they need access to authoritative information about their service areas to maintain safe and compliant operations.

Importance of Solving the Problem Now

The business has set a target of onboarding 5+ organizations onto Uncrew for Operators over the next 6 months.

Why Should the Business Pursue This?

“Tenancy” or “Multi-Tenancy” is the means by which simultaneous users/organizations can use the same instance of a software product without awareness or impact on each other. This concept is table stakes for external use of Uncrew for Operators.

How Does This Align with DroneUp’s Business Goals?

As of 2025-09-15 (meeting: Priorities & Updates), our priorities are:

1. Winch
2. 44807 for Blueflite
3. Multi-Tenancy
4. Eliminate AMC
5. Other Mission Types (Delivery, Inspection, ISR)
6. Logging/Observability/Assurance

Concept Overview

Organizations as Tenants

Organizations can take up residency in our Uncrew for Operators product as tenants. They will have a variety of pathways to establish themselves on the platform, whether they are invited by our enablement team or opt for a self-service option. Large organizations with operations that span teams, departments, or countries will be able to establish tenant hierarchies that reflect their organizational structure. Each organization’s view of our product will be limited to their own users, missions, and data by default, but we may introduce tools that allow for sharing and collaboration between tenants.

Shared Services and Tenants

Uncrew for Operators will need to combine tenant-based capabilities with shared services that support all organizations on the platform. As we build new capabilities into our product, we’ll proactively identify which capabilities are best suited to be a shared service or a tenant-based service. For example, given the regulatory conditions placed upon each UAS Service Supplier (known as an Automated Data Service Supplier under the proposed Part 108 ruleset), DroneUp may desire to be the UTM provider for all tenants on the platform. This will limit the tooling, training, and certification burden that would otherwise be placed upon our tenants. Similarly, DroneUp may find that some form of a blended service is necessary to enable fleet management for organizations, especially if a component of fleet management is aircraft registration and identification.

Operational Control and Regulatory Compliance

The certificate holder, known as the Operator, must maintain operational control over its Agents. Operators must control the configurations in use by each of the Agents. Operators must also be able to control updates to configurations to ensure regulatory compliance. Uncrew for Operators will need to provide infrastructure that supports multiple versions of our services in simultaneous use by Agents.

Operational control extends beyond just configuration control. For example, an operator must be able to approve “flight releases” for any flight performed under their certification. Uncrew for Operators will require infrastructure that supports the exchange of information between Operators and Agents.

Concept whiteboard for Operators, Agents, and Configurations Relationships

Configurations and Versioning

For organizations that must operate with a frozen configuration due to certification requirements, our product must offer a versioning system. Organizations, including OEMs, can decide which version of our product to use and may even run multiple versions simultaneously to meet the demands of their certifications or aircraft exemptions. Our product will provide clear ways to determine supported versions, their lifespans, and compatibility. DroneUp must also be able to set deprecation dates for versions based on an organization’s certification lifecycle, with the option for select organizations to get extended support of a deprecated version.

Data

Our product will offer a library of datasets, ranging from geospatial navigation data to operational procedures. Tenants can also supply their own data, including authoritative (e.g., Switzerland’s Federal Office of Civil Aviation) or third-party datasets (e.g., Airspace Link), and can modify the DroneUp-supplied data to fit their specific needs. Organizations can apply temporary exceptions to datasets, even authoritative ones, and will have a clear means to escalate data issues to the data owner. To ensure the integrity of our product, we will measure the frequency, recency, and quantity of these exceptions. This allows us to help correct misuse of the tool without limiting its usability. We will also provide tools that continuously encourage tenants to resolve exceptions, helping them inherently resolve any data drift. We may also use tenant-supplied data to validate and expand DroneUp’s own datasets.

Concept Illustration

Target Audience

Users

• I can be a part of multiple organizations with a single account.
• I can have multiple accounts provided I’m using different credentials.
• Any data I create or an organization creates will not be shared outside of my organization by default.
• I want to tap into shared, authoritative data provided by DroneUp.
• I am blind to the data and users of the other child organizations unless that information is shared with me.
• I can move aircraft and assets between tenants.

Operators

• I maintain operational control over my Agents.

Agents

• I have a product that I trust will keep me compliant with my Operator’s certification.

Certified Uncrew Technicians

• I can select the version of the software each operator/agent uses.
• If necessary, there are settings/parameters that only I am able to use to ensure the product is compliant, safe, and usable.

Uncrew Admins

• I manage deployment and deprecation of software versions.
• I manage the shared services and shared infrastructure the tenants rely on.
• I can discover the number of organizations and users, including contact information.
• I can be declarative about supported versions of the product, and create deprecation exceptions for select organizations.

OEMs

• I can choose the version, or versions, of the product my aircraft use based on our certification lifecycle.

Why Wouldn’t This Succeed?

Complexity. At the time of writing, DroneUp is not in a position to onboard an external operator onto the platform. While the use cases for those operators may be diverse and will certainly require development of new capabilities, none of that matters if we are not able to successfully onboard multiple organizations onto the product. It is in our best interest to limit the scope of the initial milestones for this concept as much as is reasonable. Identify our core value proposition, remove the immediate barriers to giving external organizations access to that value proposition, and then build from there.

Alternatives Considered

Engineering has been investigating several alternative paths to deliver this concept. Proposals include themes such as “multi-tenancy and multi-instance” or “dependency helm-charts”. For the purpose of this concept, we have identified the target audiences, their respective needs, and aligned these with DroneUp’s goals. Below are examples of the ideas engineering is putting forward for potential implementation paths. These images are provided for reference only.

Helm-charts example

EXAMPLE: Using helm-charts to provide multiple versions to tenants

Multi-instance example

EXAMPLE: Using multiple isolated instances with tenant-aware shared services

Appendix A: Key Terms

Appendix B: Gap Analysis