Immich: the product plan

A product plan on ProductBrain: 5 goals, 25 needs, 45 approaches, 33 jobs. Goals hold the why, needs the user problems, approaches the bets, jobs the checkpoints. This is a live, read-only ProductBrain plan; the interactive tree and matrix load when scripts run.

how this plan was built (the full agent transcript) · all public plans · ProductBrain

Goal: Never lose a photo — automatic backup from every device

Every photo and video from every phone and camera lands safely in one owned library, deduplicated and complete. The foundation of trust.

  • need: Get every photo off the phone automatically

    Backup should be invisible: assets sync without the user having to remember.

    • approach: Mobile automatic background backup (resolved)
    • approach: Selective per-album backup control (resolved)
    • approach: Manual upload & upload-straight-to-album from mobile (validation)
  • need: Never store the same photo twice

    A growing library must not silently accumulate duplicates.

    • approach: Checksum deduplication on upload (resolved)
    • approach: Duplicate-detection & bulk resolution utility (resolved)
  • need: Bring in photos that already live elsewhere

    Existing collections on disk or other tools must be adoptable without re-copying.

    • approach: External libraries (read-only, watched) (resolved)
    • approach: Bulk import & migration via CLI (resolved)
  • need: Handle any file a real camera produces

    Prosumer formats and camera metadata must be first-class.

    • approach: Broad format support (RAW, HEIC, Live/Motion, 360, video) (resolved)
    • approach: Metadata & XMP sidecar extraction (resolved)

Goal: Rediscover any moment in a lifetime library

Turn a massive archive into something instantly navigable and searchable — browse decades, find by face/text/content/place, resurface memories.

  • need: Edit and adjust photos without leaving Immich or losing the original

    In-app, non-destructive editing so users never round-trip through another tool or fork their originals.

    • approach: Non-destructive photo editor (web + mobile) (validation)
      • job: Crop and rotate a photo on the web with the original preserved (done, phase: In-place photo editing)
      • job: Adjust exposure/contrast/etc. non-destructively on the web (done, phase: In-place photo editing)
      • job: The mobile editor offers the same crop/rotate/adjust as the web (done, phase: In-place photo editing)
      • job: An edit made on mobile can be re-adjusted later on the web (done, phase: In-place photo editing)
      • job: Re-color / filter effects return to the editor (phase: In-place photo editing)
      • job: Editing a Live Photo applies to the still without breaking the pair (phase: In-place photo editing)
  • need: Keep a growing library organized without manual toil

    As the library scales, organization has to be partly automatable — and extensible.

    • approach: Manual organization primitives (tags, stacks, favorites, archive) (resolved)
    • approach: Workflow automation (preview) (development)
      • job: AssetCreate and AssetMetadataExtraction triggers run steps on new uploads (done, phase: Workflow automation)
      • job: Built-in actions add-to-album (auto-create), favorite, and archive apply to matches (done, phase: Workflow automation)
      • job: HTTP-request action posts matching assets to an external webhook (done, phase: Workflow automation)
      • job: Date filter narrows which assets a workflow acts on (done, phase: Workflow automation)
      • job: Share a workflow as JSON and import someone else's (done, phase: Workflow automation)
      • job: PersonRecognized trigger runs steps when a named person is detected (phase: Workflow automation)
      • job: Run a workflow retroactively across existing assets (phase: Workflow automation)
      • job: Additional actions: tag, move-to-folder, and delete as workflow steps (phase: Workflow automation)
      • job: Per-run history and error surface for debugging a workflow (phase: Workflow automation)
      • job: Utilities → Workflows page lists workflows with a first-run empty state (done, phase: Workflow automation)
      • job: Create a blank workflow or start from a premade template (done, phase: Workflow automation)
      • job: Visual and JSON editors build a trigger plus ordered steps (done, phase: Workflow automation)
    • approach: Plugin platform & SDK (preview) (development)
      • job: Plugins execute sandboxed as WebAssembly via Extism (done, phase: Plugin platform & extensibility)
      • job: The core plugin ships the built-in workflow methods (done, phase: Plugin platform & extensibility)
      • job: A plugin manifest declares its methods, triggers, and host-function needs (done, phase: Plugin platform & extensibility)
      • job: Method↔trigger compatibility is validated when building a workflow (done, phase: Plugin platform & extensibility)
      • job: Third-party developers can publish and install external plugins (phase: Plugin platform & extensibility)
      • job: A published, versioned plugin SDK for external authors (phase: Plugin platform & extensibility)
      • job: Admin reviews a plugin's requested permissions before enabling it (phase: Plugin platform & extensibility)
  • need: Browse decades without it grinding to a halt

    Scrolling a huge library must stay fast and let you jump anywhere.

    • approach: Virtualized timeline with scrubbable scrollbar (resolved)
    • approach: Folder view of the original structure (resolved)
    • approach: Fast delta sync to keep clients current (validation)
  • need: Find any photo by what's in it, not just its name

    Search must reach the content of photos, not only their filenames.

    • approach: Contextual CLIP semantic search (resolved)
    • approach: OCR text-in-image search (validation)
    • approach: Advanced metadata search filters (resolved)
  • need: Find and organize people by face

    Faces are how people actually look for photos of loved ones.

    • approach: Facial recognition & people clustering (resolved)
  • need: See photos by place

    Location turns a pile of photos into a travelogue.

    • approach: Reverse geocoding & interactive global map (resolved)
  • need: Resurface photos you'd forgotten

    The library should proactively bring back good moments.

    • approach: Memories (on-this-day / x years ago) (resolved)

Goal: Relive and share photos with the people who matter

Albums, collaboration, partner and public sharing that make the library social without giving up ownership.

  • need: Curate and collaborate in albums

    Albums are the primary unit for grouping and sharing.

    • approach: Albums (create, curate, order, cover) (resolved)
    • approach: Shared albums with contributions & activity (resolved)
  • need: Share your whole timeline with a partner

    Couples and family want an always-on shared view of each other's photos.

    • approach: Partner sharing (resolved)
  • need: Share with people who don't have an account

    Sharing must reach people outside the server.

    • approach: Public shared links (password, expiry, upload) (resolved)
  • need: Watch photos and videos on the big screen

    The living-room screen is a real viewing surface.

    • approach: Casting to Chromecast / external displays (resolved)

Goal: Photos you fully own — private, self-hosted, no lock-in

The reason to self-host at all: your data stays yours, private, portable, multi-user, and recoverable.

  • need: Many people, one server, separate libraries

    A household or team shares hardware but not their libraries.

    • approach: Multi-user accounts with quotas (resolved)
    • approach: Admin console & system settings (resolved)
    • approach: Email & in-app notifications (resolved)
  • need: Sign in securely with existing identity

    Auth must fit into a self-hoster's existing identity setup.

    • approach: OAuth/OIDC SSO, local auth, API keys & sessions (resolved)
  • need: Your data stays yours and portable

    No lock-in: predictable storage and full programmatic access.

    • approach: User-defined storage template (resolved)
    • approach: Full API/SDK access & bulk export (no lock-in) (resolved)
  • need: Recover the whole library from disaster

    Self-hosting is only safe if recovery is real and tested.

    • approach: Built-in database backup & restore (validation)
    • approach: 3-2-1 backup guidance & file-level tooling (resolved)
  • need: Trust the library isn't silently corrupting

    Bit-rot and drift between DB and disk must be detectable.

    • approach: System integrity checks (validation)
  • need: Stay private and in control of what's visible

    Users decide what is hidden, locked, or trashed.

    • approach: Privacy controls (visibility, locked folder, trash retention) (resolved)

Goal: Run great on any hardware, from a Pi to a rack

A self-hosted platform is only viable if it installs easily, performs at scale, and an operator can run it with confidence.

  • need: Play any video smoothly on any device and network

    Video is the hardest media to serve well across devices.

    • approach: Hardware-accelerated transcoding (NVENC/QSV/VAAPI/RKMPP) (resolved)
    • approach: HLS & real-time adaptive streaming (preview) (development)
      • job: Long videos play via HLS instead of a single full-file transcode (done, phase: Adaptive video streaming)
      • job: Admin configures HLS variants (resolutions/bitrates) (done, phase: Adaptive video streaming)
      • job: Real-time transcoding starts playback without waiting for a full transcode (done, phase: Adaptive video streaming)
      • job: Video plays over a public share link with live transcoding (done, phase: Adaptive video streaming)
      • job: The new web video player handles HLS playback (done, phase: Adaptive video streaming)
      • job: Adaptive bitrate switches variants automatically with network conditions (phase: Adaptive video streaming)
      • job: HLS streaming on the mobile app (phase: Adaptive video streaming)
      • job: Broad device/codec compatibility validated with graceful fallback (phase: Adaptive video streaming)
  • need: Run ML without a big GPU — or accelerate it if you have one

    ML must be feasible on a homelab box and scalable on real hardware.

    • approach: ML service with hardware acceleration & remote mode (resolved)
  • need: Install and upgrade without pain

    A newcomer must get running quickly and upgrade safely.

    • approach: Docker Compose & platform packages (unraid/synology/truenas/k8s) (resolved)
    • approach: Config via env, config file & settings UI (resolved)
  • need: Scale and stay healthy under load

    Background processing and observability keep large instances alive.

    • approach: Job queue & dedicated worker architecture (resolved)
    • approach: Observability & monitoring (Prometheus, server stats) (resolved)
    • approach: Maintenance mode & operational safety (validation)

Make yours · Made with ProductBrain