Hello, Torrust community!
+ ++ We're excited to share some news about a new tool we've been developing: the Torrust Tracker Deployer. While it's not quite finished yet (we're close!), we wanted to give you an early + preview of what we're building and why. +
+ ++ A while back, we published a comprehensive tutorial on deploying Torrust to production. The tutorial covered all the necessary steps to get the Torrust Tracker running on a + virtual machine with proper security, SSL certificates, and production-ready + configurations. +
+ ++ While the tutorial is thorough and the process isn't particularly complex, it does involve + many manual steps. You need to configure Docker, set up Nginx, obtain SSL certificates + from Let's Encrypt, configure the tracker itself, and ensure everything is properly + networked. It's the kind of task that becomes tedious when you need to do it multiple + times or want to quickly spin up a new instance for testing. +
+ ++ The Torrust Tracker Deployer is our answer to this problem. The goal is simple: make deploying the Torrust Tracker as easy + as running a single command. +
+ ++ Instead of following a lengthy manual process, you'll be able to deploy a fully + configured, production-ready Torrust Tracker to your virtual machine with minimal + interaction. The tool handles all the heavy lifting—from system dependencies to SSL + certificates to tracker configuration. +
+ ++ When we started this project, we made a conscious decision about scope and focus. Rather + than creating an incredibly flexible deployment tool that can handle every possible + configuration and deployment scenario, we opted for simplicity. +
+ ++ The deployer comes with a pre-configured setup that we believe covers 99% of use cases. + This means: +
+ ++ If you need a highly customized deployment or want to configure every aspect of your + setup, the manual deployment tutorial is still available. But for those who want to get + started quickly with a solid, production-ready configuration, the deployer is the way to + go. +
+ ++ The deployer is designed for a specific use case and audience. Here's how to decide if + it's right for you: +
+ ++ Beyond deployment, the tool serves another purpose: living, working documentation of the tracker's infrastructure requirements. By examining the deployer's configuration and + generated files, you can: +
+ +Think of it as a reference implementation that you can learn from and adapt.
+ ++ It's important to understand what this tool is—and what it isn't. The Torrust Tracker + Deployer is a + single-use deployment tool, not an ongoing infrastructure management + platform. +
+ ++ The deployer's job is to get your Torrust Tracker up and running quickly and correctly. It + handles: +
+ ++ Think of it as an expert installation assistant—it does the heavy lifting of getting your + tracker deployed, but then hands over control to you. +
+ ++ Once your tracker is deployed, ongoing infrastructure management becomes your responsibility + as a system administrator. The deployer does not handle: +
+ ++ This focused approach keeps the tool simple and reliable. Rather than trying to be a + comprehensive infrastructure management platform (which would add enormous complexity), we + concentrate on doing one thing well: getting your tracker deployed correctly. +
+ ++ One aspect that makes this project unique is that it's not a conventional infrastructure + tool. We've applied + Domain-Driven Design (DDD) principles to infrastructure automation—an approach + more commonly seen in business applications than DevOps tooling. +
+ ++ In our architecture, the domain represents the core concepts we care about: +
+ ++ These domain concepts live in the heart of the application, independent of any specific + technology. +
+ ++ Tools like OpenTofu and Ansible are implementation details that live in the + DDD infrastructure layer. This means: +
+ ++ This separation creates a more maintainable codebase where deployment logic is expressed + in terms of domain concepts (what we're deploying and why) rather than tool-specific + commands (how to use OpenTofu or Ansible). +
+ ++ Getting to the current Rust implementation wasn't a straight path. We took a deliberate, + iterative approach, building two proof of concepts (PoCs) before settling on the final + architecture. Each iteration taught us valuable lessons and helped us validate different + approaches. +
+ ++ Repository: + torrust-tracker-deploy-bash-poc +
+ +
+ Technologies: Bash scripts, OpenTofu, cloud-init, Docker Compose
+ Focus: Infrastructure as Code with libvirt/KVM and cloud deployment
+ Status: ✅ Historical reference - Completed its research goals
+
+ This was our first exploration into automated deployment. We wanted to understand the + basics of infrastructure provisioning and validate that we could automate the deployment + workflow. The simplicity of Bash made it easy to prototype quickly, and OpenTofu gave us a + taste of declarative infrastructure management. +
+ ++ Repository: + torrust-tracker-deploy-perl-poc +
+ +
+ Technologies: Perl, OpenTofu, Ansible, libvirt/KVM, cloud-init, Docker
+ Compose
+ Focus: Declarative configuration management with mature automation tools
+ Status: ✅ Historical reference - Completed its research goals
+
+ The second iteration introduced Ansible for configuration management, which gave us better + structure and reusability. We explored how established DevOps tools handle complex + deployments and learned about the trade-offs between declarative and imperative + approaches. Perl served as the orchestration layer, coordinating between different tools. +
+ ++ Repository: + torrust-tracker-deployer +
+ +
+ Technologies: Rust, OpenTofu, Ansible, LXD, cloud-init, Docker Compose
+ Focus: Type-safe, performance-oriented deployment tooling
+ Status: 🚀 Production-ready - Active development
+
+ Armed with insights from both PoCs, we built the production version in Rust. The choice of + Rust wasn't arbitrary—it aligns with the Torrust ecosystem (the tracker itself is written + in Rust) and provides the type safety, performance, and reliability we need for a + production deployment tool. We kept the best parts of our previous iterations (OpenTofu + for infrastructure, Ansible for configuration, Docker Compose for service orchestration) + while wrapping everything in a robust, well-tested Rust application. +
+ ++ This iterative approach allowed us to learn, experiment, and validate our ideas before + committing to the final implementation. While it took more time upfront, it resulted in a + much better end product. +
+ ++ Beyond the architectural innovation of applying DDD to infrastructure, this project + represents another first for the Torrust organization: it's the first project entirely developed using AI agents. +
+ ++ Up until now, all code in the Torrust Tracker has been human-crafted. We've used + traditional development practices with careful, manual code writing. For the deployer, we + took the opposite approach—100% of the code lines have been generated by AI agents. +
+ ++ But let's be clear: this doesn't mean we were just "vibe coding" or blindly accepting + whatever the AI produced. Far from it. +
+ +Using AI agents effectively requires discipline and infrastructure:
+ +Building a reliable test suite for this project was particularly challenging:
+ ++ These testing challenges were especially difficult to solve, but they were crucial. + Without a solid test suite, working with AI agents would have been much riskier. +
+ ++ We'll be honest: this project turned out to be more complex than we initially anticipated. + What started as a straightforward automation tool has grown into a substantial codebase. +
+ ++ To give you an idea of the scope, here's a comparison of the deployer codebase versus the + tracker itself: +
+ ++ Yes, you read that right—the deployer codebase has actually surpassed the tracker itself + in terms of lines of code! This might seem counterintuitive at first, but it reflects the + complexity involved in automating system configuration, handling various edge cases, + managing infrastructure as code, and ensuring reliable deployments across different + environments. +
+ ++ The Torrust Tracker Deployer is currently under active development and nearing completion. We've made significant progress, with the core functionality already in place. +
+ +The foundation is solid. Here's what we've completed:
+ +create - Create deployment environment definitionprovision - Create infrastructure resources (VMs)configure - Install dependencies and configure servicesrelease - Deploy application releasesrun - Start and run deployed servicestest - Verify deploymentdestroy - Clean up resourcesThe deployer currently supports multiple deployment scenarios:
+ +
+ Status: ✅ Fully working and production-ready
+ Our primary target is Hetzner Cloud, a reliable European cloud provider. This is the recommended
+ option for production deployments. For current pricing information, visit
+ hetzner.com/cloud.
+
+ Status: ✅ Fully working, but intended for testing
+ The LXD provider allows you to deploy locally on your development machine or in CI environments.
+ While it works perfectly, it's primarily intended for:
+
+ It's not recommended for production use, but it's great for getting started quickly if you + have the dependencies installed. +
+ +
+ Status: ✅ Supported
+ Already have a VM from another provider? No problem. You can register pre-provisioned instances
+ with the deployer and use it for everything except the initial VM creation (configuration, release,
+ run, etc.). This is perfect if:
+
+ Adding new cloud providers is straightforward—we use OpenTofu, and it only requires adding + two templates for each new provider. If there's demand for specific providers (AWS, + DigitalOcean, Linode, etc.), they can be added relatively easily. +
+ +We're in the final stretch with just a few remaining items:
+ +show - Display deployment statuslist - List all deployments+ We expect to have a stable, production-ready release with these features completed in + approximately one month (around late February 2025). The repository is public, and you're + welcome to follow along with development or even try it out, but please be aware that it's not yet finished and some features are still being polished. +
+ ++ You can track detailed progress on our official roadmap. +
+ ++ One aspect we're particularly proud of is the quality and breadth of documentation. We've + invested heavily in making the deployer easy to understand, use, and contribute to. +
+ +For developers and contributors, we maintain extensive internal documentation:
+ ++ For end users, we provide clear, practical documentation that helps you get started + quickly and understand how to use the deployer effectively. +
+ ++ Following Rust philosophy, the program itself is designed to be helpful and guide you + through the deployment process: +
+ ++ This attention to user experience means you spend less time reading documentation and more + time getting things done. +
+ +When the deployer is ready, you can expect:
+ ++ Compare this to the manual deployment process, which involves following a lengthy tutorial + with many steps and can take several hours to complete. The deployer reduces that to + minutes. +
+ +To use the deployer, you'll need:
+ ++ Don't worry if you don't have these installed—the deployer includes a console command to + help you install them and check if they're available on your system. +
+ ++ Note: A Docker image is also planned, which would eliminate the need to install + dependencies on your machine. However, this feature is not yet implemented. +
+ +Depending on your chosen provider, you'll need provider-specific credentials:
+ ++ Given that the entire deployment process takes less than a minute, we've opted for + simplicity over complex recovery mechanisms. If something goes wrong, the recommended + approach is to destroy the environment and start fresh—it's faster than trying to recover + from a failed state. +
+ +That said, we've built in comprehensive observability:
+ ++ The state machine prevents continuing with normal commands after a failure, but since the + whole process only takes a minute, there's really no need to try to recover—just destroy + and redeploy. +
+ ++ We're always excited to have community involvement in Torrust projects. If you're + interested in the deployer: +
+ ++ The Torrust Tracker Deployer represents our commitment to making the Torrust ecosystem + more accessible and easier to use. While the journey has been more complex than + anticipated, we're nearly at the finish line and believe the result will be worth the + effort. +
+ ++ Deployment shouldn't be a barrier to running your own tracker. With this tool, we're + working to remove that barrier and make it possible for anyone to deploy a + production-quality BitTorrent tracker in minutes rather than hours. +
+ ++ We're in the final stretch of development, and we'll keep you updated as we approach the + stable release. We can't wait to see what you build with it! +
+ +Happy tracking!
+ ++ + Have questions or feedback? Open an issue + or start a + discussion + in the deployer repository, or join the broader conversation in the + tracker discussions. + +
+