BIASHARA is built on free and open-source software and published as open source itself. You can read it, run it, audit it and extend it. Nothing about your client estate depends on a contract with us staying in force.
A managed service provider is in the business of being trusted with other people's infrastructure. It is an odd position to be in when the tools that hold that trust are closed, priced per seat, and able to change their terms at the end of any contract year.
Building BIASHARA on open-source software removes the renewal from the equation. The cost of delivering service becomes the infrastructure you run and the people you employ, both of which you can plan. Growth stops being a line item that rises automatically with every endpoint you win.
Publishing the platform as open source removes the second problem, which is visibility. You can read how an agent decides what to do, see exactly what the endpoint agent collects, hand an auditor the source rather than a datasheet, and keep running a version that works while you evaluate the next one.
The platform is the same in all three. What changes is where it runs, who operates it and which constraints you are solving for. Most providers start in one model and move once they know their own load.
| Cloud | On-premises | Hybrid | |
|---|---|---|---|
| Where it runs | On infrastructure you rent from a provider of your choosing, in the region you choose. | In your own racks or a colocation facility you already use. | Core services in your facility, client-facing components closer to the clients. |
| Who operates it | Your team, or ours under an agreement if you would rather not carry it at first. | Your team, with the same tooling you use for client infrastructure. | Shared, with the split written down and monitored like any other service. |
| Where client data sits | In your cloud account, under your keys and your retention policy. | Inside your network boundary, which is often the point. | Sensitive records held on-premises while scalable components sit in the cloud. |
| Scaling approach | Add capacity on demand, which suits providers growing quickly or unevenly. | Planned capacity, which suits a stable estate and predictable cost. | Elastic where load varies, fixed where the data is sensitive. |
| Upgrade control | You choose when to take a release, the same as any other model. | Full control, including holding a version through a client audit. | Component by component, with compatibility notes per release. |
| Usually chosen when | You want to be running this quarter without buying hardware. | Client contracts, sector rules or your own policy require it. | Some clients require local data and the rest do not. |
The platform is deployed as a set of containerised services with a published configuration, so a deployment looks like the infrastructure work your engineers already do: a few hosts, a database, object storage, a certificate and a backup schedule.
There is no hidden component that only we can operate, and no license server to phone home to. The installation documentation, the upgrade notes and the reference topologies are public, and the community has field notes from providers who have stood it up in both small and large configurations.
If you would rather not run it yourself on day one, we can operate it for you under an agreement and hand it over later. The platform does not change when ownership of the operations does.
Some problems in this stack were solved years ago by projects with long track records. Rather than rewrite them, BIASHARA integrates them, configures them for multi-tenant managed services, and presents them through one console and one permission model.
Encrypted connectivity between technicians, client sites and the platform, brokered against the platform identity layer rather than a separate list of users.
Used by remote access control and the client portal.Collection, parsing and storage for endpoint, server, network and identity logs, feeding correlation with an open query language you can read.
Used by the unified SIEM.Metrics, availability and performance collection for servers, network devices and services, with per client thresholds and alert correlation on top.
Used by the monitoring module.A directory for technicians, client contacts and automation accounts, with group and role structures that the whole platform reads from.
Used by identity and access control.Second-factor enrollment and verification for technicians, client portal users and privileged session approval, applied by policy instead of by habit.
Used by sign-in and remote session policy.Event-driven workflows that join modules together: a monitor becomes a ticket, an approval becomes an execution, a result becomes a notification.
Used by orchestration and the agents.Declared desired state for managed devices, so a standard build is enforced and drift is reported rather than discovered during an incident.
Used by scripting and inventory drift detection.Shared credential and secret storage for technicians and automation, with access governed by the same roles that govern everything else.
Used by remote access, scripting and onboarding.The relational store, object storage and message queue underneath the platform, all standard components your team can back up, tune and monitor.
Used by every module.Ingress, certificate issuance and renewal for the console, the client portal and the agent endpoint, so a deployment is secure before it is public.
Used by every public endpoint.Nobody rips out a working service desk on a Friday. Providers move in stages, usually over a quarter or two, keeping the old stack in place until each client has been cut over and the renewal can be allowed to lapse.
List every product, its renewal date, its per seat or per endpoint price and what it genuinely does for you. The exercise alone usually finds licenses nobody can account for.
Stand up the platform, enroll your own machines and one friendly client, and operate both stacks at once. Monitoring and inventory are the safest places to start.
Move tickets, assets and automation per client, with the old tool still available. Each cutover teaches you something that makes the next one shorter.
Retire products as they fall out of use rather than at a single cliff edge, and keep the saving rather than spending it on the next subscription.
The work that takes time is not the software. It is agreeing your standard build, writing down the runbooks your technicians keep in their heads, and deciding which automation you are willing to trust. That work pays off whichever platform you end up running, and the community has field notes from members who have already done it.
From the work around the software rather than from access to it. Providers pay us when they want deployment and migration help, a platform operated on their behalf, training for their technicians, or a support agreement with a response commitment. All of that is optional, and a provider who prefers to self-host, read the documentation and ask the community pays nothing. Talk to us and we will quote the current terms for whichever of those you actually need.
No. The nine modules and both agents are in the open-source platform. We are not keeping multi-tenancy, audit logging or the automation behind a commercial tier, because those are exactly the things a managed service provider needs on day one and exactly the pattern that makes open-source tooling frustrating to adopt.
It keeps running. You hold the source, the deployment, the database and the storage, and the foundations underneath are long-lived open-source projects rather than our own inventions. That is a weaker position for us than a subscription would be, and it is the correct one for a tool you are betting client contracts on.
Yes. Most providers never need to, because modules, scripts, detections and workflows are the supported extension points, but the code is there if your operation needs something unusual. Contributions back are welcome and reviewed in the open. Nothing obliges you to publish the automation that makes your service desk distinctive.
A provider with no appetite for operating infrastructure and no interest in anyone operating it for them will be happier with a hosted subscription product. The same goes for a team that needs a specific compliance certification from the tool vendor today. We would rather say that plainly than sell a deployment that disappoints in month three.
Ask us for the repository and the deployment documentation. If the platform suits your operation you will know quickly, and if it does not we will tell you where the gaps are.