Skip to content

Ratings

Docker App Rating consist of a table that look at the docker app and evaluate its configurations, deployment and usage against some quality of life features such as easy backup/restore, migration, user mapping, time zone logs, single-sign on with multi-user support etc. These ratings will change as more testing are done.

Docker Apps Rating
U/GID TZ SSO/Users Existing FS Portable Subfolder
❎ ✅* ❌🤵 ✅ ❌ ❌

UGID

The Docker container/application or stack supports user ID and group ID mapping and respect the ID matching the host system. For example, Linuxserver.io and jlesage containers are gold standard.

  • All Linuxserver and jlesage containers and projects that build with their baseimages, uses environment variables PUID/PGID for mapping
  • Fully respect UID and GID mappings on the host, will be able to all bind mounted files on the host with the respective permission without permission error and app issues
  • All the files the app need to write to the bind mount are written with the ID set in environment variable and are accessible via anything such as VSCode and other containers
  • For apps that don’t have environment variables as above, but still following host user ID and permissions when modifying files will also have this rating eg. Audiobookshelf, Navidrome
  • If the app require multiple containers deployed as a stack and if the main app or the app that stores configuration/appdata fully support it but other part of the app do not, it will have ✅* rating eg. Bookstack
  • The container do not have these environment variables and by default when it needs to create files on the host, it creates them with root:root permission but functions correctly
  • The container permission can be fixed simply with user: 1000:1001 in compose
  • After this fix, these should not be any permission issues and the container functions without issues and create files that are accessible via anything eg. Authelia, Jellystat
  • The container do not support environment variables and by using user:, the functionality of the container is broken and have permission issues or still writes files as root
  • However, the container do not write configuration data or there is no need to have shared access of data
  • eg. a database application, app that is entirely configured via environment/labels
  • The container exhibit symptoms of Usable rating but user: either breaks the containers or still won’t fix permission
  • The container bind mounts to configuration or shared data that needs to be accessible by other tools, it would need constant chown -R to ensure access by others are possible
  • By setting user: or chown to make files accessible to the host and other tools, the container cease to function
  • Only named volumes can be used not bind mounts

TZ

The container support standard timezone variable. All logs generated by the container follows the timezone specified by TZ or other supported environment variables. This is either ✅ or ❌.

SSO

Users

  • 🤵: Only a single user/session is supported at a time
  • 👪: Multiple users are supported via SSO or internally

Authelia
Authelia is the SSO provider that is used for the setup. Only support and compatibility for this will be documented. Only the main app via an exposed web interface need to support it, otherwise it’s not applicable. If there are zero reasons to expose this app to the internet and have multiple local users, this is n/a.

  • App has OIDC support that works with third-party provider eg. Audiobookshelf, Portainer
  • App without advanced OIDC but have documented other ways to integrate SSO for users eg. Filebrowser, Navidrome
  • The user via SSO can be mapped to existing users with same name or creates the user if not exist
  • App is able to fully integrate with ALL third party service or mobile/desktop apps flawlessly even after installing SSO/2FA
  • Authelia whitelist rules can be easily created to restore full functionality of the app (eg. API, public portion) without compromising security where Authelia is needed
  • App do not provide native integration for third party sign-in providers; but has an option to fully disable internal authentication in favor of Authelia eg. Radarr, Nzbget
  • App do not have internal authentication eg. Memos, jlesage VNC
  • By adding Authelia to add authentication or to replace internal authentication, the app is able to fully integrate with ALL third party service or mobile/desktop apps flawlessly even after installing SSO/2FA
  • Authelia whitelist rules can be easily created to restore full functionality of the app (eg. API, public portion) without compromising security where Authelia is needed
  • The above only apply with single-user apps, if a multi-user app do not natively support 3p SSO provider, Authelia is unable to passthrough the correct user
  • Apps that have removable authentication or no authentication which Authelia can be added
  • The only logical way to access the app is via a web browser where Authelia is fully supported
  • Accessing the app via third-party services is restricted to LAN only or behind a VPN where Authelia is not relevant eg. Nginx Proxy Manager, Teslamate
  • The app has internal authentication that cannot be disabled or integrate with Authelia
  • After installing Authelia, only way to use the app is via web browser; third party integration and mobile/desktop apps no longer function even with whitelisting rules eg. Jellyfin, Home Assistant
  • Using whitelist rules to restore functionality with third party apps would compromise security where Authelia is needed
  • No workarounds are possible to have both SSO and 3p integrations

Existing-FS

Existing filesystem structures, the app do not require a folder structure that only the app can use and is able to use it as is and allow user to not change workflow when switching to this app. (This section is incomplete, more updates needed)

  • config: type of files that governs how an app behaves eg. configuration.yaml, app.conf
  • media: files includes videos, photos, documents or other files the user want the app to manage
  • App work with a bind mount to a host path where other process can also access it and the app do not have conflict with other processes
  • App do not modify existing file structures and permissions
  • User is able to import/export/edit data stored in the app (both configs and media) freely with or without the app eg. Jellyfin, Filebrowser
  • User is able to move relatively freely to a similar app
  • (To be updated)
  • App store its data (both config and media) in encrypted blob, proprietary format, specific database only the app can read
  • App modify existing file structure for it to work and the permissions it need are incompatible with other workflows, refer to U/GID
  • The only way to import/export/edit data is via the app, it’s difficult to use another workflow

Portable

The portability of the app refers to how easy is it to migrate, backup/restore an app’s config. If the frequency of backup/restore is irrelevant or no persistence data is needed such the app runs entirely via docker-compose, it’d be n/a.

  • The app will work on another machine simply by copying the bind mount to the new machine
  • If U/GID are not supported and a named volume is used, copying the volume with various tools will transfer the app to the new machine
  • If an app uses a database, it will still work after either copying the bind path or volume to the new machine; if not, a repeatable and documented way to dump and import the database is provide so the app will transfer smoothly
  • After the app is migrated, zero user intervention is needed and the app to function exactly the same
  • App does not work by simply copying over the persistent data, but only a quick user intervention is needed eg. backup/restore file in WebUI
  • App data migration will work, but might require complex scripts or other dependencies that makes scripting harder
  • App cannot be migrated or restored by simply copying the files, the app stop workings
  • The backup process is difficult and often fails
  • Even with a migration, heavy user intervention is needed for the app to function exactly the same if it’s possible

Subfolder

  • Subfolder refers to the ability to reverse proxy on a subdirectory like domain.tld/app instead of app.domain.tld
  • apps that support subfolder usually have configuration for a baseURL or have explicit documentation on how to proxy over subfolder in major reverse proxies
  • App can only be reverse proxied as app.domain.tld

Mobile

The mobile refers to mobiles apps section, this rating determines the quality of mobile integration (only Android tested) since an app on mobiles offers more function than a website.

  • The app has a mobile app on app store or APK either from the developer itself or has viable well-maintained third-party apps
  • The mobile app enhance the experience of the app and offers better usability compared to a web browser
  • Mobile app offers deep integration with Android OS or other apps with widgets, controls, intents where nessecary (eg. Audiobookshelf, Home Assistant, Jellyfin, share icon to and from app)
  • The app website has a mobile-friendly layout which a progressive-web app can be used and the webapp offers equivalent functionality to desktop counterpart
  • The app in question is basic and all its functions are supported via a website without deep system integration (eg. Dashboard app for display only)
  • App will be given * rating if the app does not have a mobile app or support PWA but it’s mobile friendly when opened in a traditional mobile browser
  • The app either do not have a mobile friendly website/app or it’s mobile counterpart is not useable that a lot of desktop functionality is lost (eg. Grafana, webtop)

Comments