User Tools

Site Tools


foundation:automationserver

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.

foundation/automationserver.txt · Last modified: by privacyl0st