Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 22:23:50 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #4462] [FEAT]: Use a enterprise base image like rocky9 or ubi9 for container images #2843

New Issue
Closed
opened 2026-02-22 18:31:30 -05:00 by yindo · 3 comments
yindo commented 2026-02-22 18:31:30 -05:00
Owner
Copy Link
Copy Source

Originally created by @Bodanel on GitHub (Oct 1, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4462

What would you like to see?

Using ubuntu as a base image makes sense as it provides an easy start. However, serious enterprise dont use ubuntu based images (there are few exceptions but even those are using LTS release like AnythingLLM).
Also using Docker as an engine also create roadblocks as enterprises are trying to avoid any kind of vendor lock in and they have a policy to use only OCI compliant images.

This creates all sorts of problems when you are trying to introduce this for an entire team and you need to put in for security exceptions.

Currently AnythingLLM does not provide these images.
If AnythingLLM is willing to consider these I'm more than happy to create the Container files based on UBI9/Rocky9 or something similar and submit the changes for the AnythingLLM team to review

Originally created by @Bodanel on GitHub (Oct 1, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4462 ### What would you like to see? Using ubuntu as a base image makes sense as it provides an easy start. However, serious enterprise dont use ubuntu based images (there are few exceptions but even those are using LTS release like AnythingLLM). Also using Docker as an engine also create roadblocks as enterprises are trying to avoid any kind of vendor lock in and they have a policy to use only OCI compliant images. This creates all sorts of problems when you are trying to introduce this for an entire team and you need to put in for security exceptions. Currently AnythingLLM does not provide these images. If AnythingLLM is willing to consider these I'm more than happy to create the Container files based on UBI9/Rocky9 or something similar and submit the changes for the AnythingLLM team to review
yindo added the enhancementfeature request labels 2026-02-22 18:31:30 -05:00
yindo closed this issue 2026-02-22 18:31:30 -05:00
yindo commented 2026-02-22 18:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Oct 1, 2025):

Hey there,

I totally understand where you are coming from on your points, but ultimately, they come down to opinions and for us - we need to focus on the core development experience of AnythingLLM, so simplification where it is needed is a priority. Let me elaborate on some points you outlined

Using ubuntu as a base image makes sense as it provides an easy start. However, serious enterprise dont use ubuntu based images (there are a few exceptions but even those are using LTS releases like AnythingLLM).

We understand that some enterprises prefer UBI or Rocky, but Ubuntu LTS strikes the best balance for our current community. Using a minimal image only adds more work monkey-patching deps for things to work.

Ubuntu LTS provides the widest community support and easiest path to deployment for the majority of our users (from individual devs to small teams to enterprise) without the extra complexity that comes with highly minimal or vendor-specific bases.

Also using Docker as an engine also create roadblocks as enterprises are trying to avoid any kind of vendor lock in and they have a policy to use only OCI compliant images.

IIRC, while Docker and OCI have a lot of similarities, there are some gotchas specific to Docker. However, I think there is a tool that can export any Docker image into the OCI-spec. I can't say for sure if our image is fully compliant and not using any Docker-specific specs, but the gap should not be much.

I have often taken Docker images and exported and run them in podman without a massive headache, although maybe these images were much simpler.

If AnythingLLM is willing to consider these I'm more than happy to create the Container files based on UBI9/Rocky9 or something similar and submit the changes for the AnythingLLM team to review

We cannot officially support or maintain a secondary set of production-grade images - it just becomes another thing for us to be responsible for.

For organizations with strict, non-negotiable requirements like yours, the most common and accepted approach is to maintain your own fork of AnythingLLM. This allows you to apply your specific hardening rules and base images (like UBI9) without us diverting resources from core development. Since we are mainly talking about the image, one should hope new code has no or little impact on your image; however, it is possible that as we upgrade, add, and remove deps, certain packages in the image for a more lightweight or minimal distro base need more deps installed before starting the container. eg: sharp, chromium etc

When it comes to the application, that is where we are opinionated and have criteria. We provide the most "common" path to support developers deploying AnythingLLM, but intentionally leave infinite room for deployment preferences for how you run AnythingLLM and because this project is OSS, you are free to always make those changes without conferring with us.

You can say that because we use Docker, we are defining a deployment requirement, but in reality, you can rebuild the image in podman or whatever. For us, Docker is a developer convenience, as is using Ubuntu 🤷

@timothycarambat commented on GitHub (Oct 1, 2025): Hey there, I totally understand where you are coming from on your points, but ultimately, they come down to opinions and for us - we need to focus on the core development experience of AnythingLLM, so simplification where it is needed is a priority. Let me elaborate on some points you outlined > Using ubuntu as a base image makes sense as it provides an easy start. However, serious enterprise dont use ubuntu based images (there are a few exceptions but even those are using LTS releases like AnythingLLM). We understand that some enterprises prefer UBI or Rocky, but **Ubuntu LTS** strikes the best balance for our current community. Using a minimal image only adds more work monkey-patching deps for things to work. Ubuntu LTS provides the widest community support and easiest path to deployment for the majority of our users (from individual devs to small teams to enterprise) without the extra complexity that comes with highly minimal or vendor-specific bases. > Also using Docker as an engine also create roadblocks as enterprises are trying to avoid any kind of vendor lock in and they have a policy to use only OCI compliant images. IIRC, while Docker and OCI have a lot of similarities, there are some gotchas specific to Docker. However, I think there is a tool that can export any Docker image into the OCI-spec. I can't say for sure if our image is fully compliant and not using any Docker-specific specs, but the gap should not be much. I have often taken Docker images and exported and run them in podman without a massive headache, although maybe these images were much simpler. > If AnythingLLM is willing to consider these I'm more than happy to create the Container files based on UBI9/Rocky9 or something similar and submit the changes for the AnythingLLM team to review We cannot officially support or maintain a secondary set of production-grade images - it just becomes another thing for us to be responsible for. For organizations with strict, non-negotiable requirements like yours, the most common and accepted approach is to maintain your own fork of AnythingLLM. This allows you to apply your specific hardening rules and base images (like UBI9) without us diverting resources from core development. Since we are mainly talking about the image, one should hope new code has no or little impact on your image; however, it is possible that as we upgrade, add, and remove deps, certain packages in the image for a more lightweight or minimal distro base need more deps installed before starting the container. eg: `sharp`, `chromium` etc When it comes to the application, that is where we are opinionated and have criteria. We provide the most "common" path to support developers deploying AnythingLLM, but intentionally leave infinite room for deployment preferences for _how you run AnythingLLM_ and because this project is OSS, you are free to always make those changes without conferring with us. You can say that because we use Docker, we are defining a deployment requirement, but in reality, you can rebuild the image in podman or whatever. For us, Docker is a developer convenience, as is using Ubuntu 🤷
yindo commented 2026-02-22 18:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@Bodanel commented on GitHub (Oct 1, 2025):

I appreciate your answer. We definitely have within our team the expertise and the resource to build our own images. This was just me trying to give something back :)

@Bodanel commented on GitHub (Oct 1, 2025): I appreciate your answer. We definitely have within our team the expertise and the resource to build our own images. This was just me trying to give something back :)
yindo commented 2026-02-22 18:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Oct 1, 2025):

Of course, thanks for understanding at least our position and how we balance things - its the most I can ask for tbh 🙏

@timothycarambat commented on GitHub (Oct 1, 2025): Of course, thanks for understanding at least our position and how we balance things - its the most I can ask for tbh 🙏
yindo changed title from [FEAT]: Use a enterprise base image like rocky9 or ubi9 for container images to [GH-ISSUE #4462] [FEAT]: Use a enterprise base image like rocky9 or ubi9 for container images 2026-06-05 14:48:51 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#2843
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?