SuggestArr: the automation defaults to sending requests without asking anyone

New jobs inherit a switch that is off

The first thing the project explains is the setting that decides whether a human ever sees a suggestion. New jobs follow the global Approve requests before sending them to Seer setting, disabled by default under Advanced. Each job can inherit that setting or override it to always approve or always send automatically. So out of the box a scheduled job takes someone's watch history, asks TMDb for similar titles, and files download requests in Seer unattended, and the review queue stays empty because nothing was ever held. Turn the setting on and behaviour changes in two places at once: new jobs hold their results, and anything already filed with always send automatically keeps going. Held results surface on the Requests page, where the job owner or an administrator can send them to Seer, reject them, or blacklist them globally.

Two registries publish the same image, both tagged latest

Two different registries are named for the container, and neither is presented as the source of truth. The compose example pulls ciuse99/suggestarr:latest, while the surrounding text says images are also available from GitHub Container Registry as ghcr.io/giuseppe99barchetta/suggestarr:latest. The example also sets restart: always, so an image tag that moves is picked up on the next host restart without anyone deciding to upgrade. The start command is written the old way:

docker-compose up

The top-level tree carries a docker directory and an unraid directory, which suggests separate packaging work for a container registry and an Unraid template, but neither path is described. If you care which build you are running, pin a version tag instead of latest, since the project tags releases regularly and the compose sample does not show how to do that.

The port variable sits on both sides of the colon

The compose sample uses one variable for the host port and the container port at once:

ports:
  - "${SUGGESTARR_PORT:-5000}:${SUGGESTARR_PORT:-5000}"

That makes changing SUGGESTARR_PORT change both ends, so there is no way to keep port 5000 on the host while moving the service elsewhere, which is the usual reason to set the variable at all. The same variable is also passed into the container as an environment value, and the interface is documented at http://localhost:5000 or your custom port. Only one volume is mounted, ./config_files against /app/config/config_files, and LOG_LEVEL is the only other environment entry, marked optional and defaulting to info. SQLite is the default store and external PostgreSQL or MySQL is offered for scalability, but no path is given for the database file, so where it lands inside that single mount is worth confirming before you rely on it. Switching stores is advertised for improved scalability and performance, with PostgreSQL and MySQL both named, yet the sample defines no database service and no connection string, so choosing one means supplying configuration the example never shows.

The setup flow asks for a Seer account password

To make requests under a specific identity rather than the default profile, the web interface walks through four steps: enable user selection, pick the user from a dropdown, enter the password for that selected user, and from then on the system files requests as that person. Those requests will therefore land in that user's Seer history, and the credential itself is typed into a third-party web form and stored wherever SuggestArr keeps its configuration. The same section notes that currently only local Seer users are supported, so an account authenticated through an external provider is not an option. Meanwhile configuration pre-testing validates API keys and URLs during setup, and real-time logs can be filtered by INFO, ERROR and DEBUG with LOG_LEVEL raising the verbosity. Nothing here documents how access to the interface itself is controlled.

Four brakes on the same unattended job

Automation this aggressive comes with several separate brakes, and they trigger on different conditions. The global request workflow settings can pause a job while its suggestions await review and can automatically reject suggestions left pending for a configured number of days, with the pause behaviour overridable per job. Each job separately carries a Pause while Seer requests are pending option in its schedule settings, which stops new work while Seer still holds undecided requests. A third is the unwatched-suggestion pause, which halts scheduled jobs when a user has not watched a SuggestArr request within a configurable number of days while leaving manual runs available. The fourth is not a pause at all but a cleanup automation that prunes old SuggestArr-originated requests and files when nobody ever favourites them. The section explaining the first of these ends partway through its opening sentence.

Two beta toggles decide whether watch history leaves the house

The core path needs no model. Recently watched items come from the media server, similar titles come from TMDb, and requests go to Seer. Two features marked beta sit on top of that. AI-powered recommendations take watch history and send it to any OpenAI-compatible endpoint, with OpenAI, Ollama, Gemini and LiteLLM all named, and return a written reason for each pick. AI search lets someone describe in natural language what they want to watch and have matching titles found against the same viewing history, with a one-click request to Seer. Because the endpoint is operator-chosen, the same two features either send a user's viewing history to a hosted API or keep it on a local Ollama instance, and nothing in the configuration distinguishes the two cases for you.

Trakt is per user, the application credentials are not

Trakt is the optional enrichment layer, and media-server history works without it. What it adds: recent Trakt watches as recommendation seeds, fully watched Trakt items added to the skip-watched set, and a collapsible Recent Trakt Preview panel that shows the latest items fetched when it is opened. The split in responsibilities is the part worth noting. Each SuggestArr user links their own Trakt account from their profile, while admins configure only the shared Trakt application credentials, meaning one Client ID and Client Secret are entered once for the whole instance and every user authorises against it. Linking goes through a device code that SuggestArr displays and the user enters at the Trakt activation URL. Trakt links are tied to the linked Plex, Jellyfin or Emby profile, so the media-server account has to be linked first or the Trakt link has nothing to attach to.

Overseerr and Jellyseer in the pitch, Seer everywhere else

The project's summary describes it as requesting movies, shows and anime to Jellyseer or Overseer, while the body of the documentation, the prerequisites and every configuration path use a single name, Seer, with the prerequisite linking to the seerr-team repository. Related search traffic still arrives under the old names, which is one reason the rename is worth knowing about. Content filtering is the other policy decision to check: it excludes requests for content already available on streaming platforms in your country, so a country setting changes what the automation asks for, and the documentation does not name which service or catalogue that availability is checked against. If your goal is filling gaps in what you cannot already stream, confirm the filter is pointed where you expect before enabling scheduled runs. Per-user request visibility is the other lever here: requests can be filtered by media-server account, and administrators can restrict regular users to requesting only for their own linked Plex, Jellyfin or Emby account.

Editorial conclusion

SuggestArr fits a household that already runs a media server and Seer and wants recommendations gathered on a schedule, and the recommendation seed logic plus per-user Trakt linking are the parts with real value. Two things to settle before enabling it. First, the global approval switch ships disabled, so a fresh job sends download requests with no human in the loop until you turn that on under Advanced or override it per job. Second, the web interface holds TMDb keys, a Trakt client secret and a Seer account password, and can rewrite the cron schedule, yet access control for that interface is not documented here, so do not expose port 5000 beyond your own network without checking that yourself.

Frequently asked questions

Official sources

1. giuseppe99barchetta/SuggestArr on GitHub
2. License: MIT
3. Project website
4. README
5. Releases