Table of Contents
Automation Services VM (ARR Suite)
This virtual machine is the engine room of the Trash Panda ecosystem. It is responsible for media discovery, indexing, acquisition, and post-processing automation. While none of these services are internet-facing directly, they are active, chatty, and I/O intensive — which makes proper VM design critical to long-term stability.
This page covers only the VM setup and deployment. Installation and configuration of Prowlarr, Sonarr, Radarr, the torrent client, and other applications are covered in their own guides.
Role of This VM in the Ecosystem
The Automation Services VM:
- Centralizes all acquisition and automation tooling
- Communicates with indexers and trackers
- Interfaces with the NAS for file access
- Communicates with Plex and Unmanic indirectly
- Remains non-internet-exposed by design
By isolating these services into a dedicated VM, we:
- Reduce blast radius if something misbehaves
- Simplify troubleshooting
- Avoid polluting Plex or reverse proxy environments
- Gain predictable performance characteristics
This VM lives quietly in the background — and when configured correctly, you should rarely need to touch it.
Base Operating System
- Ubuntu Server 24.04 LTS
- Minimal installation (no desktop environment)
- Automatic security updates enabled
Ubuntu LTS provides:
- Long-term security support
- Strong community documentation
- Stability over bleeding-edge features
This VM should run headless and be administered via SSH.
Virtual Hardware Allocation
Memory (RAM)
- 8 GB RAM (fixed allocation)
Why 8 GB?
- ARR applications are memory-light individually
- Combined workloads (indexing, parsing, API polling) benefit from headroom
- Prevents swap pressure during burst activity
Avoid memory overcommit. Stable automation depends on consistent memory availability.
CPU Allocation
- 2 vCPUs
Automation services are:
- Bursty rather than sustained
- Light on raw compute
- More sensitive to latency than throughput
Two vCPUs provide sufficient parallelism without wasting host resources.
Storage Allocation
- 50 GB virtual disk
- Thin provisioned (recommended)
This storage is used for:
- OS and system packages
- Application installation (native to OS)
- Application configuration and metadata
- Logs and temporary files
No media is stored here. All downloads, staging, and final media storage should occur on the NAS via the NFS VLAN. NFS mount configuration is assumed to be handled by the builder.
Network Configuration
This VM requires two network interfaces, each with a very specific purpose.
NIC 1 — LAN VLAN
Purpose:
- Administrative access (SSH)
- API communication with Overseerr, Plex, and other internal services
- General outbound internet access (via firewall rules)
- VPN client for secure indexer and tracker access (to be installed and configured by the builder)
Characteristics:
- Standard MTU (1500)
- Routed
- Allowed to initiate outbound connections
This is the VM’s control plane.
NIC 2 — NFS VLAN
Purpose:
- High-speed file access to the NAS
- Media staging, imports, and file operations
Characteristics:
- Layer 2 only
- Jumbo Frames enabled (9000 MTU)
- No routing to LAN or internet
Segregating file I/O from control traffic ensures:
- Predictable performance
- Reduced latency
- Strong isolation from higher-risk services
VMware Workstation Pro Configuration Notes
Assuming VMware Workstation Pro 17:
- Attach two virtual network adapters
- Bind each adapter to its corresponding physical NIC
- Disable unnecessary virtual hardware (sound, USB, etc.)
- Use VMXNET3 adapters for best performance
Do not bridge both NICs to the same network.
Why This VM Is Not in the DMZ
Automation services:
- Do not need inbound internet access
- Communicate outward only
- Interact with internal services via APIs
Placing this VM outside the DMZ:
- Reduces attack surface
- Simplifies firewall rules
- Keeps noisy automation traffic away from exposed services
If indexers or trackers are unreachable without a VPN, that concern should be addressed at the network or firewall layer, not by exposing this VM.
Design Philosophy Recap
This VM is designed to be:
- Quiet
- Predictable
- Disposable if needed
- Easy to rebuild
If it ever breaks, you should be able to:
1. Recreate the VM
2. Restore configuration
3. Resume automation
No irreplaceable data should live here.
What Comes Next
Once the VM is deployed and reachable:
- Application installation (native to the OS)
- Configure NFS mounts to the NAS
- Configure VPN on NIC1 (LAN VLAN) to enable secure indexer/tracker access
- Configure and start automation applications
Each of these topics is covered in their respective guides.
If this VM feels boring once it’s running — that means it’s doing its job.
