Alphie’s backend is built on modern, async APIs, so clicks in the UI and external integrations both hit the same fast, low-latency engine.
Alphie constantly checks each runner’s CPU, memory, and container load, then routes jobs to the least-busy healthy runner, disabling “sick” ones and alerting you before queues back up.
Alphie pipelines let you stitch multiple runbooks together into a single, repeatable flow.
Each step has its own inputs, logs, and status, and the pipeline can stop on failure or continue based on your rules.
You can cancel a pipeline mid-run, see exactly which step it stopped on, and review a clean, combined pipeline log when it’s done.
Alphie captures full logs for runbooks and pipelines, step by step.
You see live output as jobs run, with clear markers for start, finish, failure, and cancel events.
Pipeline logs summarize each step while still letting you drill down into the exact task output.
Combined with schedule history and server health messages, you get a complete story of what ran, where it ran, and why it behaved the way it did.
Alphie exposes everything through fast, OAuth-style APIs.
Each user or integration gets its own client ID and secret, exchanges them for a bearer token, and then talks to the same backend the UI uses.
That means you can trigger runbooks, pipelines, and queries from your own portals or scripts with proper authentication and auditability built in.
In Alphie, a runbook is your “unit of work” — playbook, target (inventory), variables, access package, and runtime realm all wired together.
Instead of re-typing -e vars or digging for the right credentials, you pick a runbook, click Run, and Alphie builds a clean variable JSON file for that job, injects the right access package, and sends it to a healthy runner.
Every execution keeps its own EV file and log, so you can rerun with confidence or troubleshoot exactly what changed.
Alphie lets you turn any runbook or pipeline into a one-time or recurring schedule in a couple of clicks.
You can run once at a specific date/time or use a cron expression for recurring jobs. For high-risk changes, flip on “Require approval” and Alphie will email approvers with Approve / Deny buttons and track how many approvals you’ve received, who denied, and what’s still pending.
Quorum rules, reminders, and expiry windows are built in, and you can always hit Run Now from the UI when you need to bypass the normal cadence.
Runtime Realms let you pin down exactly what execution environment your automation runs on.
Pick a base Linux image (Rocky, or Alma), check the boxes for tools like Terraform, AWS, GCP, VMware, or PowerShell, and optionally list extra Python packages, ansible galaxy modules and system packages.
Alphie turns that into a container image, builds it, and pushes it out to your runners. Every runbook is attached to a realm, so jobs always run in a consistent, pre-baked environment instead of whatever happens to be installed on the host.
Access Packages bundle all the credentials a runbook or pipeline needs—SSH keys, usernames, passwords, API tokens, cloud keys—into one reusable unit.
Each package is typed (SSH, vSphere, cloud, etc.), has well-defined fields from its Access Type, and is scoped to a specific group so only the right teams can use it.
Sensitive values are encrypted at rest with Fernet, and the UI lets you search, copy, edit, and rotate them without ever exposing secrets in plain text.
Automation Sets bundle your playbooks, SCM source, credentials, and permissions into a single, reusable unit.
Point Alphie at a Git, SVN, or local path, attach an Access Package for auth, and assign one or more groups.
With one click, Alphie fetches the code, installs roles and collections from any requirements.yml, and atomically swaps the updated content into place—streaming live fetch logs to the UI so you can watch what’s happening.
Teams just pick the Automation Set by name; Alphie handles cloning, syncing, and keeping everything up to date.
Alphie splits inventory into three clean pieces: Targets, Hosts, and Sets. A Target is your runnable inventory — it ties together groups, JSON vars, and a list of Hosts that only the right user groups can see or use.
Hosts are the actual machines (name/IP, description, per-host vars) and can belong to multiple Targets without duplicating data.
Sets give you nestable host collections inside a Target, each with its own variables, so you can model things like “web”, “db”, “cluster-1”, or “prod-us-east” as a tree and run against exactly the slice you want.
Alphie prevents duplicate hostnames within a Target, enforces group access, and gives you a full UI to search, copy, and edit Targets, Hosts, and Sets without touching inventory files by hand.
Manage users and groups directly in the UI: create local users yourself, or Alphie will create them automatically when they log in via LDAP or SAML.
Toggle admin and registered status, and edit or delete accounts without touching the database.
Each user automatically gets a client ID and secret for API access, with their password and secrets encrypted at rest.
Groups let you organize users by team or function and then reuse those groups everywhere else in Alphie—targets, access packages, automation sets, schedules, and notifications—so permissions stay consistent across the whole platform.
Use the Inquiry File Builder located at the bottom of your profile page, to design a form for the values you want users to enter. Then download the JSON file.
Add the extra-vars snippet shown on the page { "alphie_( template name )": "yes/no"} to your runbook’s Variables (JSON) field.
When you run that runbook, Alphie will pop up the inquiry form, write the answers into a variables JSON file in the execution directory, and automatically load those values as extra vars so your playbooks can see and use them.
