Health checks
Each system exposes a health endpoint that distinguishes running from merely started. Point your orchestrator or uptime monitor at it rather than at the port.
Self-hosting
Run it on your own infrastructure.
Self-hosting is the default path, not a downgrade. You get the release package, the images, the configuration and the documentation, and Botlane is involved only if you decide it should be.
The package
What arrives with a self-hosted system.
These are the things that separate a release from a repository. Each one corresponds to a release gate you can check on the system's own page.
A pinned, tested release
A specific version built from a recorded upstream commit, not a checkout of whatever main happened to be that day.
Container images
Docker / OCI images for the release, so the artifact you deploy is the artifact that was tested.
Deployment configuration
Compose files and environment templates with every required variable documented and validated at boot.
Operational documentation
Installation, configuration, upgrade, rollback, backup, restore and troubleshooting — written for someone who is not Botlane.
A release feed
Notes for each version, including which upstream version it pins and what changed in the packaging.
Quickstart
The shape of a deployment.
Every Botlane system follows the same four steps. The commands below are illustrative — each system's page carries its own exact release URL and variables.
01
Fetch the release
Pull the pinned release bundle for the version you intend to run. Never track a floating tag in production.
# Illustrative — use the release URL from the system's page
curl -fsSLO https://<release-url>/botlane-<system>-<version>.tar.gz
curl -fsSLO https://<release-url>/botlane-<system>-<version>.tar.gz.sha256
sha256sum -c botlane-<system>-<version>.tar.gz.sha256
tar -xzf botlane-<system>-<version>.tar.gz && cd botlane-<system>02
Configure
Copy the environment template and fill it in. Configuration is validated at startup, so a missing variable fails immediately rather than at the first request.
cp .env.example .env
$EDITOR .env
# Validate before starting anything
./botlane config validate03
Start
Bring the stack up against the pinned images and wait for the health endpoint to report ready — not merely started.
docker compose up -d
docker compose ps
curl -fsS http://localhost:8080/healthz04
Verify and back up
Run the smoke suite, then take a backup and restore it once before you put real work through the system.
./botlane smoke-test
./botlane backup create --out ./backups
# Prove the restore works before you need it
./botlane backup restore ./backups/<snapshot>Requirements
What the host needs.
Baseline requirements apply to every system. Per-system figures are listed where a system has been sized; the rest are sized during productization.
Baseline
- Host OS
- Ubuntu 22.04 LTS or newer, Debian 12 or newer
- Container runtime
- Docker Engine 24+ with Compose v2
- Architecture
- x86-64 (arm64 where a system's page says so)
- Persistent storage
- A volume separate from the container image
- Outbound network
- HTTPS to the model provider and any integrations the system uses
- Inbound network
- TLS termination in front of the application — a reverse proxy or load balancer
- Backups
- Somewhere off the host to write them, and a restore you have actually tested
Per system
| System | CPU | RAM | Disk |
|---|---|---|---|
| AI WhatsApp Sales Desk | 2 vCPU | 4 GB | 40 GB |
| Client Status Report Agent | 1 vCPU | 2 GB | — |
Systems not listed have not been sized yet. A figure will appear here when it has been measured, not estimated.
Verification
Check what you downloaded.
A pinned release is only worth something if you can confirm the artifact you have is the artifact that was tested.
# Checksum published alongside every release
sha256sum -c botlane-<system>-<version>.tar.gz.sha256
# Image pinned by digest, not by tag
docker image inspect \
--format '{{index .RepoDigests 0}}' \
<image>:<version>Every release publishes a checksum, and images are addressable by digest so a deployment can pin what it runs by content rather than by a tag someone could move. Adopting a newer upstream version produces a new Botlane release with its own notes — never a silent rebuild behind the same number.
How provenance is pinnedConfiguration
Secrets stay yours.
Credentials are supplied at runtime. They are never baked into an image, committed to a repository, or written to logs — one of the twelve release gates, so it is checkable per system.
# Supplied at runtime, never committed
DATABASE_URL=postgres://user:pass@db:5432/app
MODEL_API_KEY=
WEBHOOK_SIGNING_SECRET=
# Validated at boot — a missing value fails closed
APP_BASE_URL=https://systems.example.com- Keep .env out of version control; the release ships a template, not a filled file.
- Rotate the signing secret and API keys independently of a release upgrade.
- Run config validation in CI as well as on the host, so a bad value is caught before deploy.
- Terminate TLS in front of the application rather than inside the container.
Operations
Running it after day one.
The parts that matter three months in, when the person who installed it is on holiday.
Backups
Persistent data lives on a volume, separate from the image, so it survives an upgrade. The documented procedure covers what to snapshot and in what order.
Upgrades
Upgrading means pulling the new pinned image and running the release's migration step. Release notes state whether an upgrade is reversible.
Rollback
Every release documents the previous version it can roll back to, and whether that rollback is data-safe. If it is not, the notes say so before you start.
Availability
What you can actually download today.
This page describes the self-hosting model. Here is where each system genuinely stands, generated from the same data as the release badges.
| System | Botlane version | Gates | Downloadable |
|---|---|---|---|
| AI WhatsApp Sales Desk | 0.1.0-rc | 0/12 | Not yet — planned |
| Client Status Report Agent | 0.5.5 | 12/12 | Yes |
| AI Receptionist | — | 0/12 | Not yet — planned |
| AI IT Helpdesk | — | 0/12 | Not yet — planned |
| AI Back Office | — | 0/12 | Not yet — planned |
| AI Legal Practice OS | — | 0/12 | Not yet — planned |
Pre-release versions exist for 2 of 6 systems, but no system has closed all 12 gates yet, so there is nothing on general release to download. Ask about early access if you want to run one before then.
Boundaries
Where self-host ends and Botlane begins.
Stated plainly so nobody discovers the line during an incident.
| Path | Yours | Botlane’s |
|---|---|---|
| Self-host | Infrastructure, installation, configuration, monitoring, backups, upgrades. | The release, the images, the documentation and the release feed. |
| Botlane Deploy | The infrastructure and running it after handover. | Installation, configuration, integration, validation against the release gates, documented handover. |
| Botlane Managed | Deciding what the system should do. | Monitoring, updates, backups, maintenance and operational support. |