BotLane Original
Software designed and written by BotLane.
BotLane wrote the software and licenses it directly. One licence, one author, no upstream terms to reconcile.
Trust
What Botlane will actually stand behind.
Selling packaged open source only works if the packaging is inspectable. This page sets out how releases are gated, how upstream provenance is pinned, how licensing works across the three product classifications — and, at the end, the things Botlane does not claim.
Live status
Every system, and how far through it really is.
This table is generated from the same data as the badges on the product pages. There is no separate marketing copy that could say something kinder.
| System | Classification | Gates | Status |
|---|---|---|---|
| Client Status Report AgentProfessional Services | BotLane Original | Production ready | |
| AI WhatsApp Sales DeskSales & CRM | BotLane Distribution | Planned | |
| AI ReceptionistCustomer Support | BotLane Original | Planned | |
| AI IT HelpdeskIT & Service Management | BotLane Original | Planned | |
| AI Back OfficeOperations | BotLane Original | Planned | |
| AI Legal Practice OSLegal | BotLane Original | Planned |
Release gates
The twelve gates, and what closing one means.
A gate that cannot be checked is not a gate. Each of these is a thing someone did, not an adjective someone chose.
- 01
Pinned provenance
The exact upstream commit or tag the release is built from is recorded and published. No moving targets, no “latest”.
- 02
Installation tooling
A repeatable installation path exists and has been run end to end on a clean machine, not just on the maintainer's laptop.
- 03
Docker images
Container images are built for the release and published, so the deployed artifact is the tested artifact.
- 04
OCI release artifacts
Release artifacts are published to an OCI registry with digests, so a deployment can pin an image by content rather than by tag.
- 05
Configuration validation
Configuration is validated at startup. A misconfigured deployment fails immediately and loudly instead of serving traffic in a broken state.
- 06
Secrets handling
Credentials are supplied at runtime and never baked into an image, committed to a repository, or written to logs.
- 07
Health checks
The system exposes health endpoints an orchestrator or monitor can read to tell running from merely started.
- 08
Backup & restore
A documented backup procedure exists and a restore has been performed from those backups into a working system.
- 09
Upgrade & rollback
Upgrading to the next release and rolling back to the previous one have both been executed against real data.
- 10
Security hardening
The deployment defaults have been reviewed: unprivileged runtime user, no unnecessary exposed ports, no default credentials.
- 11
Acceptance tests
An automated smoke suite covering the system's primary workflows passes against a freshly deployed instance.
- 12
Documentation & runbooks
Installation, configuration, operations, troubleshooting and architecture are written down well enough for someone who is not BotLane to run it.
A system is badged production ready when all 12 are closed, and not before. The badge is computed from the gates rather than written by hand, so the site cannot describe a system as finished while its checklist says otherwise.
Classifications
Three kinds of product, labelled as such.
What Botlane built, what Botlane packaged, and what Botlane merely operates are different things, and a buyer is entitled to know which one they are looking at.
BotLane Distribution
Open-source software packaged, tested, hardened and supported by BotLane.
Two licences apply. The upstream project's licence governs the upstream code and is unchanged by BotLane — we do not relicense work we did not write. BotLane's package licence covers the packaging, tooling, tested release and support around it.
BotLane Integration
A supported deployment of third-party software, configured and operated by BotLane.
The third-party vendor's terms apply directly between you and them. BotLane's agreement covers deployment and operation only, which is why these systems are not redistributed or rebranded.
Provenance
You can tell exactly what you are running.
The value of a distribution is that somebody pinned it, tested that pin, and told you which one it was.
- 01
Every distribution names its upstream
The upstream project and the exact tag or commit a release is built from are recorded and published on the product page — not kept internally and summarised as “latest stable”.
- 02
Pins are explicit and visible
The AI WhatsApp Sales Desk is pinned to DeskcommCRM v1.12.0. That version appears on the product page, in the catalogue card and in the page metadata, so it cannot quietly drift.
- 03
Moving a pin is a release event
Adopting a newer upstream version produces a new BotLane release with its own notes and its own gate run. It is never a silent rebuild behind the same version number.
- 04
Artifacts are addressable by content
Release images are published with digests so a deployment can pin what it runs by content rather than by a tag someone could move.
Licensing
Botlane does not relicense work it did not write.
Where a system is built on an open-source project, that project keeps its own licence and its own authors. Botlane licenses the packaging around it.
- BotLane Original
- BotLane wrote the software and licenses it directly. One licence, one author, no upstream terms to reconcile.
- BotLane Distribution
- Two licences apply. The upstream project's licence governs the upstream code and is unchanged by BotLane — we do not relicense work we did not write. BotLane's package licence covers the packaging, tooling, tested release and support around it.
- BotLane Integration
- The third-party vendor's terms apply directly between you and them. BotLane's agreement covers deployment and operation only, which is why these systems are not redistributed or rebranded.
Security
Properties, not adjectives.
Everything below is either a release gate you can check per system, or a statement about how Botlane operates. None of it is a certification.
Where your data sits
Self-hosted systems run on infrastructure you control, and business data does not pass through BotLane. Under BotLane Managed, operational access is scoped to what running the system requires and the hosting arrangement is set out in the agreement.
How secrets are handled
Credentials are supplied at runtime through environment configuration. They are not baked into images, committed to repositories, or written to logs. This is one of the twelve gates, so it is verifiable per system rather than a general assurance.
How a bad deployment fails
Configuration is validated at startup so a misconfigured system fails immediately rather than serving traffic in a broken state — again, a gate rather than a promise.
Reporting a vulnerability
Security reports reach BotLane through the contact route on this site and are acknowledged before any public disclosure timeline is agreed.
Limits
What Botlane does not claim.
A trust page that only lists strengths is marketing. These are the limits, stated so you do not have to discover them later.
We do not hold SOC 2, ISO 27001, or any other security certification, and nothing on this site implies that we do.
We do not publish uptime figures or performance benchmarks. We do not yet have a body of production data honest enough to draw them from.
We do not display customer logos, customer counts or testimonials. When we have customers willing to be named, they will appear here and not before.
We do not call a system production ready before its twelve release gates are closed. The badge is computed from the gates, so we could not do this even if we wanted to.
We do not claim authorship of upstream open-source projects. Where a system is built on one, the project is named and its version pinned.
We do not describe a system as tested against a workload we have not actually run.