Skip to content

Releases: elio-fleet/elio

Elio 0.1.0-beta.2

Elio 0.1.0-beta.2 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 01 Nov 22:05

Fixed

  • The Docker image of 0.1.0-beta.1 did not start: production loads all the code at boot, and a file of lib/ stopped it (uninitialized constant Elio::Version). The CI now checks the code loading (zeitwerk:check) and starts the built image with PostgreSQL before every release (bin/smoke-image).
  • Two runs of the same automation could overlap (the run started by the first inventory and one started by hand): two downloads of the vulnerability feeds then replaced the same entries, and one failed. An automation now never runs twice at the same time, "Run now" opens the task already running, and a feed is updated by one download or import at a time.
  • docker-compose.yml: PostgreSQL is checked over TCP, so that Elio does not start during the first initialization of the database.
  • No more Active Storage warning (image_processing) when running a command in the image: Elio no longer loads the parts of Rails it does not use.
  • A new installation showed no vulnerabilities for a day: the feeds were downloaded at the first start, before any server was added. Now the first inventory of a server on a release that the feeds don't hold yet downloads them at once, and new CVEs get their scores right after, instead of waiting for the next daily (or six-hourly) run.

Install

docker pull ghcr.io/elio-fleet/elio:0.1.0-beta.2

With PostgreSQL: see the quick start of the README.

Elio 0.1.0-beta.1

Elio 0.1.0-beta.1 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 01 Nov 17:09

The first public version of Elio, the self-hosted fleet manager for Linux servers: agentless, read-only, over SSH. Previously an internal tool named SSHM.

Fleet and health

  • Fleet list and grid, filters by group, system, state, address or host name; overview of what needs attention, most serious first.
  • Health of each server: load, memory, swap, disks and inodes, reboot required, failed services, clock sync, pending (security) updates; thresholds in the settings; 30 days of history with 24-hour charts.
  • Reachability and SSH checks, host keys pinned on first connection (a change waits for an administrator).
  • Server groups (with expected public ports), import from CSV or ~/.ssh/config.

Inventory

  • System (distribution, kernel, virtualization, end-of-support date), network addresses (WireGuard and other VPNs), host name.
  • Packages (dpkg with their source package, snap), searchable across the fleet.
  • systemd services; Docker containers grouped by Compose project.
  • Docker: container health, restart loops, long-stopped containers, CPU and memory, images (age, size, unused, latest), new versions published on the registries (Docker Hub, GHCR, Quay, private ones with read-only tokens).
  • Scheduled tasks: crontabs and systemd timers in plain words, failed or late timers.
  • Listening ports with their process, service or container; firewall state (ufw, nftables, iptables); suggested ufw rules to copy (never applied).
  • Every command run on the servers is in config/ssh_commands.yml, read-only except the SSH key ones.

Vulnerabilities

  • CVEs of the packages from the Debian Security Tracker and Ubuntu's OSV data, downloaded every day for the releases of the fleet (or imported by hand on a closed network), matched with the inventory with dpkg's version comparison; the running kernel counts.
  • Grouped by package with the update to make, whether the server's repositories already offer it, and the apt command to copy; or listed by CVE, with search.
  • Scores from NVD, Red Hat, CVE.org and CISA, or custom providers (JSON API or web page); exploitation from EPSS and CISA KEV; coloured scores; the score gives the severity of the CVEs the distribution did not rate.
  • CVE detail: description, score and CVSS vector of each provider, packages and versions, other servers touched.
  • Docker images: Trivy or Grype when installed, else the packages of the image matched by Elio.
  • Fleet page by package or by CVE; alerts from a chosen severity.

SSH keys

  • Shared keyring (people and machines); add or remove a key on a server, for good or for a limited time (expiring on its own, even if Elio is down); unknown keys detected; keys found on servers added to the keyring in one click.
  • Rotation of Elio's own key without downtime.

Alerts, automation, team

  • Activity log; notifications to Slack, Discord, email or signed webhooks, chosen per kind of activity; daily digest.
  • Scheduled collections on the whole fleet or per group; background tasks followed live; Mission Control for administrators.
  • Extensions, read-only: Uptime Kuma (monitors attached to servers) and OVHcloud (IPs, network firewall, DNS records, services).
  • Roles (admin, operator, read-only), invitations, two-factor authentication (mandatory by default for admins and operators), session timeout and lockout, ⌘K search, light and dark themes, French interface.

Installation

  • Docker image ghcr.io/elio-fleet/elio (amd64, arm64) and docker-compose.yml; Kamal configuration.
  • Secrets of an installation from environment variables, generated by bin/elio-keys.

Upgrading from SSHM

  • Rename the databases (sshm_* → elio_*) and the Kamal volume (sshm_storage → elio_storage); keep RAILS_MASTER_KEY if your secrets are in Rails credentials.

Known limits

  • Full inventory for Debian and Ubuntu only; Ubuntu not yet tried on a real server.
  • Uptime Kuma and OVHcloud built on recorded API answers, not yet tried on real accounts.
  • Image CVEs without Trivy or Grype: Debian and Ubuntu based images only.
  • The interface is in French.

Install

docker pull ghcr.io/elio-fleet/elio:0.1.0-beta.1

With PostgreSQL: see the quick start of the README.