One package per company

The quiet compromise of many cloud products

Multi-tenant architecture — many customers on the same shared infrastructure, cleanly separated from one another in logical terms — is the standard in the SaaS world for good reason: it is cheaper to run, easier to update, and a single team can serve thousands of customers at once. The compromise involved is rarely stated openly: in the end, all customers share the same attack surface. A weakness in the tenant separation, a misconfigured access right, a compromised administrator account at the vendor — and in the worst case it is not only one customer's data that is affected, but many at once.

For a tool that works with personal data from Jira and Confluence, this compromise would have been made in the wrong place. JiCo therefore does without the concept of a shared tenant system from the ground up — not as a hardening measure applied afterwards, but because the architecture does not provide for it in the first place.

Why there is no "account" in the cloud sense

JiCo runs locally, on the machine of the person using it or on a server the company operates itself — not as a shared service that several customers address over the internet. There is therefore simply no data store in which the data of several companies would sit side by side, however cleanly separated. A security incident at one installation stays technically confined to that one installation, because there is no shared infrastructure through which it could spread.

That is the difference between "we separate the tenants carefully" and "there is physically nothing for an attacker through which a single incident could extend to other customers". The second statement is stronger, because it does not depend on the correctness of a separation logic that would have to prove itself again with every new function.

A package belongs to exactly one sales partner

This stance continues into the delivery itself. A delivered JiCo package always belongs to exactly one sales partner — be that drkv itself or a reseller who distributes JiCo under its own name. Technically, every package accepts only licences that were signed with the keys of that one partner; requests for new or additional licences go to that partner's licence portal, not to a central, shared office for all partners at once.

In practice this means: even within the same sales partner there is no shared store of Jira/Confluence data — the licence portal holds only accounts and licences, plus a shared signing key. Which licensing office is responsible for a given installation can be looked up at any time in the panel under Settings — a deliberately transparent assignment, not a hidden one.

The price of this decision is real

This approach has an obvious disadvantage that should not be talked down: it takes more effort than a central cloud solution. Updates have to be installed on every single installation instead of being rolled out centrally once. A support team cannot see the state of all customers at a glance, as would be possible with a central dashboard. And a customer who quickly wants to work on several machines at once needs just as many individual licences, not a single centrally managed one.

These costs are not an oversight, but the other side of the same decision: whoever runs no shared infrastructure cannot maintain it centrally and efficiently either. JiCo makes this trade-off deliberately in favour of the security architecture, not out of ignorance about the operational effort it causes.

A block is also a matter for one's own partner

This separation runs right into the question of what happens when a licence has to be blocked — after repeatedly missed payment, for instance. The revocation list embedded in every newly built package for this purpose contains licence IDs only, signed with the key of exactly the one sales partner to which the respective package is assigned. A partner can therefore only block licences that it issued itself — there is no shared revocation list across all partners, let alone one controlled centrally by drkv, that could accidentally hit somebody else's customers too.

What this means in practice for the purchasing decision

For companies that want to use JiCo, this means concretely: there is no point at which one would have to ask oneself whether one's own Jira data sits next to that of a competitor somewhere, because that shared place simply does not exist. Nor is there any migration to a shared new version that affects all customers at the same time — every installation updates at its own pace, with its own approvals.

The price for that is a piece of the convenience a central cloud solution would offer. For a tool whose sole reason for existing is the controlled handling of sensitive company data, that is a trade-off JiCo deliberately makes in favour of security rather than in favour of comfort.