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!
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.
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.
@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)
I don’t know why I did all that, but do with it what you will lol
.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.
