Alphie — System Requirements

1. Supported operating systems

Alphie is intended to run on 64-bit Linux distributions commonly used for servers:

• Red Hat Enterprise Linux 9
• Rocky Linux 9
• AlmaLinux 9

A minimal, server-style install (no desktop environment) is recommended. SELinux can be enforced or permissive as long as Alphie's policies are applied correctly.

Planned Platform Support

• Enterprise Linux 10 (Planned)
  • Red Hat Enterprise Linux 10
  • Rocky Linux 10
  • AlmaLinux 10
• Docker Image (Planned)
  • Container-based deployment of Alphie Core
  • Simplified installation and configuration

These deployment options are planned for future Alphie releases. They are not currently supported by the available installer.

2. Components on the Alphie controller

An Alphie controller typically runs:

• The Alphie API + UI service (FastAPI backend + compiled binary frontend).
• A reverse proxy (usually nginx).
• A PostgreSQL database (for small and trial setups) or connects to an external PostgreSQL cluster.
• Local log storage under /opt/alphie/logs.

For production Pro environments, we strongly recommend using an external PostgreSQL server or cluster instead of running the DB on the controller.

3. Sizing by edition

The tables below assume a “typical” environment with average-sized playbooks and reasonable logging. Heavy workloads (lots of forks, large inventories, or noisy debug logging) should lean toward the higher end or next tier up.

3.1 Alphie Trial (small lab / PoC)

The trial edition is capped in features (limited runbooks, pipelines, automation sets, runners, etc.), so it does not need a big server. A single VM can run the controller, local PostgreSQL, and a small amount of local logging.

Good use cases: single admin or small team, lab environments, demos, or quick evaluations.

3.2 Alphie Pro (single-controller production)

Pro is aimed at “real” production use for a team or department: more users, more targets, more automation sets, and higher log volume. Here the controller should be treated more like an Ansible Tower/AAP controller in terms of resources, with Alphie still being somewhat lighter.

4. Runner host requirements

Alphie runners execute Ansible, Terraform, and other workload containers. Their sizing depends mostly on what your jobs do, not on Alphie itself.

4.1 Baseline runner (light to moderate workloads)

4.2 Heavy runner (large inventories or big playbooks)

• 4–8 vCPUs
• 16–32 GB RAM
• 100+ GB disk on SSD if:
  • You use large container images or many execution environments.
  • You keep logs and artifacts locally for a long time.

Instead of one giant runner, it’s often better to run multiple mid-sized runners and let Alphie distribute work across them.

5. Disk and log retention planning

Alphie writes job and pipeline logs, per-step artifacts, and optional backups. To avoid surprises:

• Keep at least 40 GB available under /opt/alphie on Pro controllers.
• Use a separate filesystem or volume for /opt if possible.

6. Network & connectivity

• The controller must reach all runners over SSH (or your configured runner transport) on the configured port.
• Runners must reach their targets just like a normal Ansible control node would (SSH/WinRM, HTTPS APIs, etc.).
• Users access the Alphie UI over HTTPS (typically port 443) through a reverse proxy such as nginx.
• If using external PostgreSQL:
  • Open TCP 5432 (or your DB port) between controller and DB nodes.
  • Use TLS + strong authentication for the DB connection where possible.

7. Quick sizing cheat sheet

• Trial: 2 vCPU, 4–8 GB RAM, 40–60 GB disk, all-in-one VM.
• Pro: 4+ vCPU, 16–32 GB RAM, 80–160 GB disk, external PostgreSQL recommended.
• Runner: 2–4 vCPU and 4–8 GB RAM for normal work; scale up or add more runners for heavy jobs.

Start with these baselines, monitor CPU, RAM, disk, and job runtimes, and then scale your controller, database, and runners to match your actual workload.