AI Horde Third-Party Deployment Improvements
One of the less visible but meaningful changes we've been working toward is making the AI Horde genuinely deployable by anyone, not just the couple of people who already know how the pieces fit together. That work has now reached a point worth announcing.
The deployments repository has been substantially overhauled. The roles are robustly documented, tested, and serve as an open-source reference for standing up your own AI Horde instance from scratch. Development machines with docker can do this with a single command (local-deploy.sh), and production deployments have clear documentation and automation for all core services, including the monitoring stack. The repository's new CI ensures that the automation remains correct and verifiable as the codebase evolves.
What's in it
The repository now ships Ansible roles for all of the core services: the AI Horde backend (including packaged PostgreSQL and Redis for development scenarios), the AiHordeFrontpage, and the horde-model-reference service (now live at https://models.aihorde.net/api/), along with optional supporting roles for ingress (HAProxy), storage backends, and telemetry collection. Each role documents its own defaults, required variables, deployment modes, and limitations, and there are runnable example playbooks covering all common scenarios.
For operators who want production-grade visibility into what their AI-Horde stack is doing, the horde_monitoring role deploys a complete Grafana observability stack. This includes metrics (Prometheus/Mimir), logs (Loki), traces (Tempo), profiling (Pyroscope), and alerting (Alertmanager) with dashboards auto-provisioned from the horde-exporters repository. This is essentially the same monitoring setup we use in production, now available to anyone.
For developers who want to iterate locally, each service suite ships a local_deploy.sh script that clones sources, builds images, and starts the stack. A full-stack entry point brings up the entire business stack including the AI Horde backend, frontpage, stats exporter, and HAProxy with optional tiers for monitoring and worker support, allowing you to simulate an entire AI-Horde ecosystem. The default uses pinned source SHAs for reproducibility; --latest follows branch heads when you want to test against current code. You can also specify specific forks/local checkouts/branches/SHAs or specific images for any component, making it easy to test changes in the context of a full deployment.
The repository also ships a custom test harness covering render validation, policy-contract checks, idempotency verification, and negative/fail-fast tests, with a CI matrix that runs these automatically on every push.
Why this matters
These changes reflect our on-going commitment to reduce onboarding friction to would-be developers seeking to improve our software. It also helps ensure that, should we be unable to continue operating the horde, someone else could easily take the reins. While we do not see this as likely, we still want to provide the possibility that anyone could start an AI-Horde cluster without a great deal of trial-and-error.
If you want to run your own horde - whether as a development environment, a private instance, or a fully independent deployment - the public repository is now the complete reference. The QUICKSTART.md is the place to start.
