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

> Easily set up multiple notification providers like Prowl Pushover and Discord simultaneously for docker-icloudpd Learn how to overcome single provider limits with this guide

- Repository: [boredazfcuk/docker-icloudpd](https://github.com/boredazfcuk/docker-icloudpd)
- Tags: how-to-guide
- Published: 2026-02-26

---

**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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/sync-icloud.sh) calls `configure_notifications()` which reads the `notification_type` variable from [`/config/icloudpd.conf`](https://github.com/boredazfcuk/docker-icloudpd/blob/main//config/icloudpd.conf) (or the equivalent environment variable) and selects exactly one provider block.

In [`sync-icloud.sh`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/init_config.sh) script normalizes `notification_type` to lowercase on startup, and [`CONFIGURATION.md`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/docker-compose.yml) that defines one service per provider:

```yaml
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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main//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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/sync-icloud.sh) and [`sendmessage.sh`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/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:

```ini
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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/sync-icloud.sh) around line 250 to recognize the new `custom` type and populate an array:

```bash
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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/sendmessage.sh) to loop through the array instead of calling a single URL:

```bash
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:

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

```

In [`sync-icloud.sh`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/sync-icloud.sh) and dispatch handled by [`sendmessage.sh`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/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`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/sync-icloud.sh) and [`sendmessage.sh`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/sendmessage.sh) as volume overrides in your [`docker-compose.yml`](https://github.com/boredazfcuk/docker-icloudpd/blob/main/docker-compose.yml) instead of editing them inside the running container. This ensures your patches persist across image pulls:

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

```