How to Set Up Multiple Notification Providers Simultaneously in docker-icloudpd

The stock docker-icloudpd container supports only one notification provider per instance via the notification_type variable, so you must run multiple containers, patch the shell scripts, or use a webhook proxy to broadcast to Prowl, Pushover, and Discord at the same time.

The boredazfcuk/docker-icloudpd image is designed to notify you when iCloud Photo Library downloads complete, but its architecture limits each container to a single notification destination. If you want alerts to hit Prowl, Pushover, Discord, and Telegram simultaneously, you need to work around this constraint using one of three proven methods.

Why Only One Provider Is Supported by Default

The notification system is hard-coded for a single destination. When the container starts, sync-icloud.sh calls configure_notifications() which reads the notification_type variable from /config/icloudpd.conf (or the equivalent environment variable) and selects exactly one provider block.

In sync-icloud.sh (lines 250–380), the function builds a single notification_url based on whether notification_type equals prowl, pushover, discord, telegram, or webhook. The send_message() function in sendmessage.sh (lines 3–12) then POSTs every alert to that solitary ${notification_url}. There is no array, loop, or comma-separated parsing that would allow multiple URLs to be hit in sequence.

The init_config.sh script normalizes notification_type to lowercase on startup, and CONFIGURATION.md documents it as “the method that is used to send notifications,” listing the supported providers without mentioning any combination syntax.

Option 1: Run Multiple Containers (Recommended)

The simplest way to receive parallel notifications is to deploy separate container instances, each configured with a different notification_type and its respective credentials. Both containers monitor the same iCloud account, and each sends alerts to its own provider independently.

Create a docker-compose.yml that defines one service per provider:

services:
  icloudpd-prowl:
    image: boredazfcuk/icloudpd
    environment:
      - notification_type=prowl
      - prowl_api_key=YOUR_PROWL_API_KEY
      - apple_id=your@email.com
      - authentication_type=2FA
    volumes:
      - ./config:/config
      - ./photos:/home/user/iCloud

  icloudpd-discord:
    image: boredazfcuk/icloudpd
    environment:
      - notification_type=discord
      - discord_id=YOUR_DISCORD_WEBHOOK_ID
      - discord_token=YOUR_DISCORD_WEBHOOK_TOKEN
      - apple_id=your@email.com
      - authentication_type=2FA
    volumes:
      - ./config:/config
      - ./photos:/home/user/iCloud

Each container reads its own notification_type from the environment (or from /config/icloudpd.conf if you prefer mounted config files) and invokes configure_notifications() to build its unique notification_url. Because the containers operate independently, a download event triggers two separate HTTP requests—one to Prowl and one to Discord.

Option 2: Patch sync-icloud.sh to Broadcast to Multiple URLs

If you prefer a single container, you can modify sync-icloud.sh and sendmessage.sh to iterate over an array of notification URLs. This requires maintaining a custom fork of the image.

First, add extra credential variables to your configuration:

notification_type=custom
pushover_user=YOUR_PUSHOVER_USER
pushover_token=YOUR_PUSHOVER_TOKEN
discord_id=YOUR_DISCORD_ID
discord_token=YOUR_DISCORD_TOKEN

Next, edit sync-icloud.sh around line 250 to recognize the new custom type and populate an array:

elif [ "${notification_type}" = "custom" ]; then
    log_info " | Custom multi-provider notifications enabled"
    notification_urls=()
    payloads=()
    
    if [ "${pushover_user}" ] && [ "${pushover_token}" ]; then
        notification_urls+=("https://api.pushover.net/1/messages.json")
        payloads+=("token=${pushover_token}&user=${pushover_user}&message=")
    fi
    
    if [ "${discord_id}" ] && [ "${discord_token}" ]; then
        notification_urls+=("https://discord.com/api/webhooks/${discord_id}/${discord_token}")
        payloads+=("content=")
    fi
fi

Finally, update sendmessage.sh to loop through the array instead of calling a single URL:

send_message(){
    local text="${1}"
    local index=0
    for url in "${notification_urls[@]}"; do
        curl --silent --output /dev/null --write-out "%{http_code}" \
            --request POST "${url}" \
            --data "${payloads[$index]}${text}"
        ((index++))
    done
}

Warning: This modification is not part of the official distribution. You must re-apply these changes after every upstream image update.

Option 3: Use a Webhook Fan-Out Service

A maintenance-free alternative is to set notification_type=webhook and point it at an intermediary service that can redistribute the payload to multiple providers. This keeps your container stock while achieving the same broadcast effect.

Configure the container to emit to a generic webhook endpoint:

notification_type=webhook
webhook_server=my.homeassistant.local
webhook_port=8123
webhook_path=/api/webhook/icloudpd

In sync-icloud.sh (lines 350–364), the script constructs the URL as http://${webhook_server}:${webhook_port}${webhook_path}. Your receiving service—whether Home Assistant, Zapier, IFTTT, or a custom Node-RED flow—can then forward the JSON payload to Prowl, Pushover, Discord, and any other service via their respective APIs.

Summary

• The official docker-icloudpd image restricts you to one notification_type per container, with logic hard-coded in sync-icloud.sh and dispatch handled by sendmessage.sh.
• Run multiple containers if you want zero code changes and true parallel delivery.
• Patch the shell scripts if you need a single container and can maintain a custom fork.
• Use a webhook proxy if you want to stay on the stock image while delegating the fan-out to an external automation platform.

Frequently Asked Questions

Can I list multiple providers in the notification_type variable?

No. The notification_type variable accepts a single lowercase string such as prowl, pushover, or discord. The configure_notifications() function in sync-icloud.sh uses an if/elif chain to match this value and exits with an error if it is unrecognized. There is no delimiter or array parsing logic in the stock code.

Will running two containers download my photos twice?

Yes. Each container performs an independent sync. If both instances use the same apple_id and download path, they will each attempt to fetch new photos. To avoid duplication, designate one container as the primary downloader and configure the second container only for notifications by pointing it to an empty download directory or disabling the download cron, though this requires additional scripting outside the scope of the stock image.

Is there a plan to support multiple native providers in future releases?

As of the current source code in boredazfcuk/docker-icloudpd, there is no indication of upcoming multi-provider support. The notification_url remains a scalar variable and send_message() performs a single curl request. Feature requests would need to refactor configure_notifications() to build an associative array and modify sendmessage.sh to iterate, which would change the configuration schema significantly.

How do I preserve my custom patched scripts when updating the image?

Mount your modified sync-icloud.sh and sendmessage.sh as volume overrides in your docker-compose.yml instead of editing them inside the running container. This ensures your patches persist across image pulls:

volumes:
  - ./custom-scripts/sync-icloud.sh:/usr/local/bin/sync-icloud.sh:ro
  - ./custom-scripts/sendmessage.sh:/usr/local/bin/sendmessage.sh:ro

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}