Skip to content

[FEATURE]: Provide Yum/DNF repo of RPM packages for RedHat distribution #388

Description

@charlesjohnson

Summary

Summary

Publish prebuilt RPMs AURA so users on RH-based Linux distros can install from the native package manager to expected system locations.

Motivation

Release artifacts are currently pre-built binaries downloaded directly, which is a meaningful barrier to getting started, especially if users want to run the web server as a daemon.

Request

Provide downloadable rpm packages for both aura-web-server and aura, covering x86_64 and arm64.

Acceptance criteria

  • RPM packages for aura-web-server and aura-cli are published alongside the existing standalone binary artifacts in releases.
  • Users can subscribe yum/dnf to a repo to pull packages via the native package manager

Additional Context

No response

Upload screenshots

No response

Searched Issues

  • No similar issues found

Code of Conduct

  • I agree to follow this project's Code of Conduct

Activity

  1. jakedipity commented on Jul 30, 2026

    @jakedipity
    Collaborator

    Packaging is partially addressed in #485. This bundles rpm and deb packages and includes it in our release assets, but doesn't actually provide a repository users can download against.

  2. jakedipity commented on Jul 30, 2026

    @jakedipity
    Collaborator

    Following up on the repository side of this.

    The mechanism we use today to distribute logdna-agent and the older logdna CLIs isn't a good fit for AURA:

    1. It relies on an awkward handoff between publishing artifacts to S3 and building a Docker image by hand.
    2. Every release requires that manual build - there's no path to automating it.

    Self-hosted OSS repository managers (Pulp, Artifactory OSS, etc.) would solve this, but they each require standing up and maintaining infrastructure that's hard to justify for a single application at this stage.

    So I'm leaning toward a hosted/paid repository service (evaluating cloudsmith), which fits our current scale without the operational overhead. I'll follow up with a comparison and a recommendation. Open to input if anyone has a strong preference or has used one of these before.

  3. self-assigned this
    on Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions