Self-hosted IT documentation and service desk for MSPs.

Keep customer documentation, assets, credentials and support workflows on your own infrastructure — one place for the runbook, the device it describes, the credential it needs, and the ticket it came from.

Quick Start · Screenshots · Walkthrough · Documentation · Releases · Report a bug · MSP Reboot

---

Watch it work

▶ Watch the full 3½-minute walkthrough (MP4, 5.2 MB) — or the 72-second highlight. The animation above is a 45-second excerpt, played at 1.6× speed.

It runs through four end-to-end workflows — a ticket from queue to runbook, the physical network from switch port to desk and patch-panel mapping, the week scheduled on the dispatch board and a project plan, and quote to invoice to profitability — with a deliberate light-to-dark transition partway. It is caption-led; there is no narration track. Transcript · captions · regenerate it, or the screenshots, with scripts/demo/.

Why MSPs run it

Documentation that sits next to the work. A ticket opens with the client's active contract, the asset it concerns, the runbook that covers it and the vault entries the technician will need — without leaving the ticket or opening a second product. Secrets are never rendered into the ticket page; opening one goes through the vault's own permissions and is logged. Documentation readiness standards score every client against what should be documented, explain each gap and queue the fixes; documents have owners, review dates, drafts, version compare and restore.

A service desk you own, not one you rent. Queues, SLA timers with pause logic, time entries, quotes, invoices, contracts, projects, approvals and workflow rules are built in and run on your server. Each technician starts from My Work — their tickets in SLA order, running timers, customer replies and approvals — and customers request services through guided portal forms that route, ask for approval and track progress in plain language. Your ticket history and your client data stay in your database, on your hardware, under your backup policy.

The physical network, drawn. Pick a model from a catalog of about 16,500 device, module and rack types, and each client device gets its front and rear panel as artwork. Click a port to record its VLANs, PoE and cable, trace a path through patch panels and wall jacks, and print true-size labels with QR codes. Racks and diagrams are drawn only from what has been documented, and every layout says whether it was checked against the manufacturer's documentation.

One tenant per client, from day one. Every asset, document, credential, location and ticket belongs to an organization. Technicians switch client context in one click; role-based membership decides who sees what. Multi-site clients, parent/child organizations and per-client PSA settings are first-class, not bolted on.

See it in action

A ticket that reads as a conversation — the customer on one side, technicians on the other, internal notes in amber and marked staff only — beside the contract, SLA countdown and the credentials the job needs, listed but never revealed.

One queue, every client · Dark Filter by status, priority, queue or technician; see who acted last.	Dispatch the week · Dark Drag a ticket onto a technician; breaches surface up top.
What is actually in the rack · Dark Drawn from each model's artwork across its real U span; click a device for its ports.	Projects with dependencies · Light Drag a bar to reschedule; blocked work is flagged.
Every port, on the panel · Light Click a port to document its VLANs, PoE and cable.	Trace the cable · Light Switch port to desk, through panel and wall jack.
Document a port in place · Dark Mode, VLANs, PoE and the cable, from the artwork.	Front-to-rear port mapping · Light Every panel port: what it is patched from and where it goes.
Credentials, never on screen · Dark AES-GCM at rest; every reveal audited.	What the month earned · Light Revenue against cost of delivery, from logged time.
Work the device from the ticket · Dark Hand off, run a read-only check or refer a fix to a paired RMM.	Who may do what, per customer · Light L1/L2/L3 presets; widening needs a second administrator.

See all screenshots → — 83 views, light and dark, across documentation, the service desk, the paired RMM, dispatch, projects, reporting, security and administration.

Quick Start

Docker (recommended)

Requires Docker Engine 24.0+ with the Compose v2 plugin, about 2 GB of disk for the image and 1 GB for the database volume.

git clone https://github.com/agit8or1/clientst0r.git
cd clientst0r
cp .env.example .env
# edit .env — at minimum: SECRET_KEY, DB_PASSWORD, DB_ROOT_PASSWORD, APP_MASTER_KEY
docker compose up -d

Open http://localhost:8000. The entrypoint runs migrations and collects static files on first boot; set DJANGO_SUPERUSER_* in .env and it creates the admin account too. Pre-built images are published to ghcr.io/agit8or1/clientst0r.

Optional services are behind compose profiles:

docker compose --profile proxy up -d   # Nginx + TLS on 80/443
docker compose --profile cache up -d   # Redis (only if you switch CACHES to Redis)

Full guide: docs/docker.md.

Native install on Ubuntu or Debian

Ubuntu 20.04+ / Debian 11+, 2 GB RAM (4 GB recommended), 10 GB free disk. The installer adds Python 3.12, MariaDB, Gunicorn and the systemd units, generates the encryption keys, runs migrations and starts the service.

git clone https://github.com/agit8or1/clientst0r.git && cd clientst0r && bash install.sh

It detects an existing installation and offers upgrade, system check or clean reinstall. Full guide: INSTALL.md.

First steps after install

1. Sign in and enrol 2FA — it is enforced for every account by default.
2. Create your first client organization under Admin → Organizations.
3. Add your technicians under Admin → Access Management and set their User Type to Staff. Staff users work across every client; everyone else is treated as a customer user and sees only their own organizations, only tickets shared with them, and no internal notes.
4. Turn the service desk on under Admin → System → Settings → Feature Toggles (psa_enabled is off by default, so the PSA menu stays hidden until you switch it on).
5. Check Settings → Scheduler. Recurring invoices, email-to-ticket, SLA checks and the other periodic jobs run from this built-in scheduler; no crontab is needed.

Updating and backups

Update from Admin → System → System Updates in the web UI: Check for Updates, then Apply. The apply step is a graceful reload — no manual service restart.

CLI fallback:

git pull && python manage.py migrate && sudo systemctl restart clientst0r-gunicorn.service

Under Docker, docker compose pull && docker compose up -d. There is no automatic rollback; see AUTO_UPDATE.md for what an update does and the manual update guide for recovery.

Back up before every upgrade. The bundled command writes the database and media to a single archive:

python manage.py backup --output-dir /var/backups/clientst0r --encrypt --retention-days 30

Keep a copy of APP_MASTER_KEY (from .env) somewhere other than the server: without it, the vault entries and stored credentials in a backup cannot be decrypted. Docker users: see Backups for the volume-level equivalent.

Supported versions and limitations

• Security fixes land on the current 3.17.x line. See SECURITY.md.
• Single-server by design. There is no clustered or multi-node deployment story; it targets one VM or one container host per MSP.
• Self-hosted software. You run it on your own server, and there is no public demo instance. Optional managed hosting and support are offered separately by MSP Reboot.
• The service desk is opt-in. psa_enabled is off until an administrator turns it on.
• AI-assisted features are optional. Nothing calls an AI provider until you configure one; the documentation and service desk AI features are also gated behind psa_ai_enabled, which is off by default. Documentation AI can use a local Ollama model.
• Third-party PSA and RMM integrations (ConnectWise, Autotask, HaloPSA, NinjaOne, Datto RMM, Syncro, Atera and others) are supported for teams that already run one — but the service desk here is native, not a front end for someone else's.

How ClientSt0r protects client data

ClientSt0r holds your customers' credentials, tickets and device data. These are the protections that ship today, with their defaults. The full walkthrough, with the evidence behind each one and the known gaps, is docs/CLIENT_DATA_PROTECTION.md. Administrators can check whether each one is in effect at a given customer under Admin → Security → Security Features.

• A customer sees the shared conversation, never your working notes. When Example Dental's office manager opens "Printer offline at front desk", they see the description and public replies, and can reply and attach a photo. The technician's internal note, time entries, expenses, kit list, workflows and the RMM's view of the PC stay with technicians. Posting directly to technician-only URLs returns 403.
• Revealing a credential is its own permission, and every reveal is recorded. Owners, Admins and Editors of a customer may reveal; Read-only members and new custom roles may not. Optional per-entry approval and access rules (country, address range, time) come first; reveals are limited to 30 an hour. Each reveal writes an audit event naming the user, entry, customer and address. The web vault, REST and mobile APIs and the browser extension use the same check.
• Sign-in defaults: two-factor (TOTP) required for everyone, Argon2 password hashes, 12+ character passwords, lockout after 5 failures for 30 minutes, sign-out after 60 minutes idle or 8 hours. Environment variables override the Settings page.
• Encryption: vault passwords, TOTP seeds and stored integration credentials use AES-256-GCM with a separate HKDF-derived key per purpose; tokens are stored as HMAC-SHA256 hashes. Ticket text and attachments are not encrypted by the app.
• MSP staff get broader access than customers, by design. Staff and superusers reach every customer; a staff global role narrows what they can do. The vault is stricter: a technician sees a customer's vault entries, even their titles, only where a membership or a global role grants "view vault". Ticket AI and RMM tools are different: they need an L1/L2/L3 technician assignment at each customer, whatever the user's flags.
• Ticket AI (OPTIONAL AI) is off until a superuser enables it and sets each customer's AI policy. Vault data, attachments and internal notes are never sent; secrets in the ticket text are redacted. Nothing AI produces is sent to a customer until a technician presses Send, and ClientSt0r sends no commands to devices.
• A paired RMM does the device work (from 3.17.658). Any RMM that implements the ticket-rmm-v1 contract can be paired to a single-customer connection; pairing is a protected change a second administrator approves, and it is pinned to one RMM tenant. From a ticket, technicians whose assignment allows it can send a redacted handoff, run a read-only diagnostic the RMM advertises, launch a view or control session, or refer a fix — which the RMM approves and runs, never ClientSt0r.
• Optional Superuser Approval. With two or more administrators, granting superuser can require a second administrator's approval (Admin → Security → Superuser Approval).

Setup checklist and limitations (audit log deletable by superusers, though each deletion is recorded, Azure AD sign-in skips TOTP, mobile tokens last until revoked, CSP report-only by default): docs/CLIENT_DATA_PROTECTION.md. Reporting a vulnerability: SECURITY.md.

Security

• Two-factor (TOTP) sign-in required by default, Argon2 password hashing, brute-force lockout, idle and maximum session length — all set in Settings → Security, with environment variables taking precedence when set.
• AES-256-GCM encryption at rest for vault entries and every other stored secret (integration, SMTP/SMS, directory and webhook credentials); tokens the app only compares are stored as hashes. manage.py rotate_encryption_key rotates the master key and manage.py check_secrets_storage audits storage.
• Per-entry vault access rules, approval and break-glass flows, audited reveals.
• Role permissions for viewing passwords, documents and assets are enforced across the web UI, search, the APIs and the mobile app. Customer users see only their own organizations and only the tickets you share with them.
• Uploaded files are served only after a permission check on the record they belong to.
• Optional Azure AD / Entra ID single sign-on and LDAP / Active Directory sign-in.
• Content-Security-Policy with per-request nonces and no inline event handlers, in report-only mode by default (CSP_REPORT_ONLY=False to enforce).
• CodeQL and dependency scanning run on every push to main and weekly.

Found a vulnerability? Please report it privately via GitHub Security Advisories rather than a public issue. Full policy and response timelines: SECURITY.md.

Documentation

Guide	What it covers
Installation	Native install, upgrade, troubleshooting
Docker	Compose layout, profiles, backups, upgrades
Features	Full capability list by area
Screenshots	Complete visual tour
Hardware inventory	Device catalog, panel artwork, ports, cables, racks, diagrams, labels
Roadmap	Shipped, in progress and planned phases
Changelog	Release history
Integrations	Connecting PSA, RMM, M365, accounting and distributors
API	REST and GraphQL endpoints
Client data protection	Who sees what, vault reveals, secure messages, ticket AI, RMM pairing, limitations
Technician access	Per-customer L1/L2/L3 presets, protected changes, Superuser Approval, RMM tools on a ticket
Security	Policy, supported versions, reporting
FAQ	Common questions
More docs	Everything else

Contributing

Issues and pull requests are welcome.

• Bugs: open a bug report
• Ideas: open a feature request
• Code: fork, branch, add a test in the relevant app's tests.py, run python manage.py test <app>, then open a PR. See CONTRIBUTING.md.

Support

Questions and troubleshooting go in GitHub Issues or Discussions.

License

MIT — see LICENSE. Use it, fork it, run it for your clients.

MSP Reboot

ClientSt0r is built by the people behind MSP Reboot — an MSP consulting practice run by a former 25-year MSP owner, working with owners on pricing, operations, margins, service delivery and technology strategy.

ClientSt0r is self-hosted software. Optional managed hosting and commercial support are offered separately by MSP Reboot for teams that would rather not run it themselves, or want someone on the hook when something breaks. Get in touch for scope and pricing.

None of that is required to use ClientSt0r. The software is MIT-licensed and every first-party feature is free and unrestricted when you self-host it — no paid tiers, no seat or client limits, no licence activation, and no feature that only works with a subscription. Paying for hosting or support buys you our time and infrastructure, not access to the product.

---

If ClientSt0r saves you time, a ⭐ helps other MSPs find it.

_{Built by a small team and one German Shepherd. 🐕 Luna supervises.}