Supported platforms

Abstrax supports Debian/Ubuntu-based and RHEL-compatible Linux distributions. This page describes what is supported today, how detection works, and important family differences.

Functional parity

Abstrax aims for functional command parity across supported distro families.

The same Abstrax commands should work on supported Debian/Ubuntu and Rocky/Alma systems where technically possible. Under the hood, Abstrax may use different packages, services, paths, and repositories per distro family. Those differences are handled by the platform provider layer — not by leaving commands unsupported.

A command should only remain unsupported on a supported distro family when there is a genuine technical limitation, an unacceptable safety risk, or a deliberate product decision documented here and in the code.

Architecture

Release builds are produced for:

• linux/amd64
• linux/arm64

Check your architecture with uname -m.

Operating systems

Abstrax reads /etc/os-release and builds a platform profile from the distribution ID, ID_LIKE, VERSION_ID, and related fields.

Fully supported

Debian/Ubuntu family

These distributions are officially tested and receive official support level:

• Ubuntu 20.04+
• Debian 11+
• Linux Mint
• Pop!_OS
• Raspbian / Raspberry Pi OS

Recognised ID values include ubuntu, debian, linuxmint, pop, raspbian, and raspberrypi.

RHEL-compatible family

• Rocky Linux 9+
• AlmaLinux 9+

Recognised ID values include rocky and almalinux.

Experimental or compatible

Debian/Ubuntu family

Other Debian/Ubuntu-based distributions may work but are not officially tested. Examples include:

• Ubuntu releases older than 20.04
• Debian releases older than 11
• Debian/Ubuntu derivatives detected via ID_LIKE but with an unlisted ID

These receive compatible support level. Abstrax allows mutating commands on compatible platforms, but behaviour is best-effort.

RHEL-compatible family

These receive compatible support level and are treated as experimental:

• Red Hat Enterprise Linux 9+
• CentOS Stream 9+
• Oracle Linux 9+

Recognised ID values include rhel, centos, ol, and oracle.

Unsupported

Distributions outside the Debian and RHEL families are not supported and receive unsupported support level. Mutating commands exit cleanly before making system changes.

RHEL-family major versions older than 9 (for example Rocky Linux 8) are also unsupported. The supported RHEL-family targets are Rocky Linux 9+ and AlmaLinux 9+.

If the OS cannot be detected at all, Abstrax reports could not detect operating system from /etc/os-release.

Run abstrax doctor to see the detected profile on your server, including:

• distro ID, name, and version
• distro family
• package manager and service manager
• nginx layout and config directory
• web user/group and default project root
• PHP-FPM naming strategy
• firewall strategy
• SELinux status (RHEL-family)
• support level

Platform conventions

Debian family

RHEL-compatible family

Important RHEL-family differences:

• Package commands use dnf rather than apt.
• Nginx site configs are written to /etc/nginx/conf.d/{site}.conf. There is no Debian-style sites-available / sites-enabled symlink layout. Disabling a site renames the file to {site}.conf.disabled.
• The default web user/group is usually nginx, not www-data.
• Multi-version PHP uses Remi SCL packages (for example php83-php-fpm). Services, binaries, sockets, and pool configs are version-specific under Remi paths. Abstrax resolves these through the provider layer.
• Remi (and often EPEL/CRB) must be enabled before PHP install, and before Redis install on EL10+. Use abstrax repo enable remi --enable-required-repos or pass --enable-required-repos. Abstrax will not silently enable Remi.
• On Rocky/Alma 10+, AppStream ships Valkey instead of Redis. abstrax cache install redis installs Redis from Remi’s redis:remi-7.2 module stream (not Valkey) so the redis package and service names stay consistent.
• Firewall commands use firewalld (firewall-cmd) where available, with permanent rules and reload after changes.
• firewalld does not use UFW-style numbered rules. abstrax firewall rule list shows Abstrax-assigned IDs that map to services/ports; abstrax firewall rule remove <id> removes the matching entry. You can also use abstrax firewall remove service http or abstrax firewall remove port 8080/tcp.
• Database install uses MariaDB (mariadb-server) as the MySQL-compatible server. The CLI command remains mysql for compatibility.
• Certbot may install EPEL automatically on Rocky/Alma/CentOS Stream. On RHEL/Oracle Linux, enable EPEL explicitly (abstrax repo enable epel --enable-required-repos or pass --enable-required-repos).
• Supervisor uses the supervisord service and /etc/supervisord.d with .ini program configs.
• Node.js auto-install uses the NodeSource RPM setup script (https://rpm.nodesource.com/setup_XX.x).
• Exact Ruby version pinning is a deliberate product limitation on RHEL-family systems today: Abstrax installs distro ruby + ruby-devel. Cross-distro exact pinning (for example via rbenv/asdf) is not implemented yet. Debian-family continues to use versioned apt packages where available.
• SELinux may require additional manual context rules for web project paths, nginx config, or PHP-FPM. Abstrax detects and warns only; it will not run setenforce 0 or rewrite SELinux policy.

Repositories (RHEL-family)

Some features require extra repositories:

sudo abstrax repo enable epel --enable-required-repos
sudo abstrax repo enable remi --enable-required-repos
sudo abstrax project add app --php --php-version=8.3 --enable-required-repos

Abstrax will not silently enable policy-sensitive third-party repositories on enterprise distributions without explicit user action.

Feature status by family

Remaining non-parity areas

Tools Abstrax manages

Abstrax calls other tools rather than replacing them. The relevant feature only works if the tool is installed. abstrax doctor reports the presence of:

Apache

The project commands accept an --apache flag and the platform detection reports Apache presence, but Apache support is not implemented. Use nginx, which is the default.

Future agent

The core CLI does not ship a built-in agent command. A hosted agent is planned as an optional official plugin (abstrax plugin install agent), installed from the plugin registry rather than the core package. The agent binary would connect outbound to a hosted API, fetch structured jobs keyed by stable action names, run them locally, and report results - without requiring inbound SSH.

Agent systemd installation will be handled by the plugin (for example abstrax agent install-service), not by core CLI packages. Do not expect abstrax agent or an abstrax-agent.service unit from the core install today.

Related

• Installation
• Troubleshooting
• Firewall
• Repositories