Hey ya all,

Reiverr is a project of mine that I’ve decided to release to the public today. It’s a self-hosted website similar to the content discovery app Overseerr, with the added features of managing and watching your content library through Sonarr, Radarr and Jellyfin integrations. The motivation behind the project was the lack of a unified modern UI that could be used to discover, manage and watch content in a single place.

Currently, the project is in very early stages of development, but it is mostly usable in its current state. If you want to try it out, you can find the installation instructions in the project’s GitHub page:

https://github.com/aleksilassila/reiverr

Also: For the project to reach its fullest potential, it could use contributions! If you’d like to contribute code, designs (I’m not a UI designer, please help me), documentation or anything else, first of all, thank you!, and you can find an extensive list of planned features & fixes at the Reiverr Taskboard. It’s also a great place to just get a sense of what’s being done if you’re curious.

Cheers guys!

  • Hcbille@lemmy.world
    link
    fedilink
    English
    arrow-up
    15
    ·
    1 year ago

    Beautiful project! One feature request/ question: Would it be possible to have a config file/gui with the api keys instead of having them in the compose file?

    • skadden@ctrlaltelite.xyz
      link
      fedilink
      English
      arrow-up
      7
      ·
      1 year ago

      You can already do this. You can specify an env file or use the default .env file.

      The compose file would look like this:

      environment:
            PUBLIC_RADARR_API_KEY: ${PUBLIC_RADARR_API_KEY}
            PUBLIC_RADARR_BASE_URL: ${PUBLIC_RADARR_BASE_URL}
            PUBLIC_SONARR_API_KEY: ${PUBLIC_SONARR_API_KEY}
            PUBLIC_SONARR_BASE_URL: ${PUBLIC_SONARR_BASE_URL}
            PUBLIC_JELLYFIN_API_KEY: ${PUBLIC_JELLYFIN_API_KEY}
            PUBLIC_JELLYFIN_URL: ${PUBLIC_JELLYFIN_URL}
      

      And your .env file would look like this:

      PUBLIC_RADARR_API_KEY=yourapikeyhere
      PUBLIC_RADARR_BASE_URL=http://127.0.0.1:7878
      PUBLIC_SONARR_API_KEY=yourapikeyhere
      PUBLIC_SONARR_BASE_URL=http://127.0.0.1:8989
      PUBLIC_JELLYFIN_API_KEY=yourapikeyhere
      PUBLIC_JELLYFIN_URL=http://127.0.0.1:8096
      

      This is how I do all of my compose files and then I throw .env in .gitignore and throw it into a local forgejo instance.

      • Hcbille@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Yeah, but I’m using a gitops approach with portainer stacks. I’ve not been able to do .env files with that setup thus far.

        • skadden@ctrlaltelite.xyz
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 year ago

          @synae@lemmy.sdf.org is correct, you can pass the values through that part of the UI. I used to do it that way and had Portainer watching my main branch to auto pull/deploy updates but recently moved away from it because I don’t deploy everything to 1 server and linking Portainer instances together was hit or miss for me.

          Edit: I just deployed it like this (I hit deploy after taking the screenshot) and confirmed both inside the container that it sees everything as well as checking where Portainer drops the files on disk (it uses stack.env)

          Stack settings

          Environment vars in container

          Portainer stack on disk

          I don’t know why I did all that, but do with it what you will lol

        • synae[he/him]@lemmy.sdf.org
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          .env file is just a convenient way to store variables on the filesystem. Ultimately they become environment variables which are easily specified in any container management tool. Here’s the portainer docs I think are relevant: https://docs.portainer.io/user/docker/containers/advanced#env (I am not a portainer user). Presumably these can be translated into gitops following practices you are already familiar with in regards to portainer.