SynologyDDNSCloudflareMultidomain: Cloudflare DDNS on a Synology NAS

A Cloudflare provider inside the Synology DDNS screen

Synology DSM and SRM ship a Dynamic DNS panel that talks to a list of known providers, and Cloudflare is not on it. This project fills that gap. It adds Cloudflare support to the Network Center or External Access Dynamic DNS section, so you pick Cloudflare as the service provider in a dropdown that previously had no such option, and the NAS then updates the DNS record itself when the WAN address changes.

That framing matters because it explains the whole design. The script is not a daemon that polls your IP address and calls the Cloudflare API on its own schedule. It is a provider implementation that the Synology DDNS mechanism drives, which means the update happens when Synology decides it should, on the Synology schedule, with the Synology logic deciding what counts as a change.

The feature list names the capabilities that make it more than a straight port of an existing provider. The domain support is the headline: single domains, multidomains, subdomains, and regional domains such as dev.my.domain.com.au. The DDNS username field on the Synology side takes a pipe separated list of hostnames for the multiple domain case, and the hostname field itself is no longer used and can hold any value.

The rest of the list is smaller but real. Dual stack is handled, with both IPv4 and IPv6 addresses autodetected and updated, and the documentation points at api6.ipify.org for checking whether IPv6 is available. Installation is automated through an install script run over SSH or from the Task Scheduler, and the Cloudflare integration is based on API v4. There is also an extended capability, up to 256 characters for hostnames, which is what makes the multidomain case practical at all.

The Cloudflare token and the DNS record that must exist first

The prerequisites are specific and the project is unusually explicit about them, which is a good sign for something that handles credentials.

The documentation says you need your Cloudflare account username, and that you need your API key with a clear instruction: no need to use your Global API key. The linked explanation is about managing API tokens and keys, and the recommended scope is listed precisely as three permissions, Zone Settings read, Zone read, and DNS edit. The affected zone resources have to include all zones from an account for the domain in question.

That is a meaningful difference from the Global API key, which is account-wide, and the distinction is worth internalising before you paste anything into a NAS.

The second prerequisite is about DNS, not credentials. The A records for the domains or zones you intend to update have to be created already, and if IPv6 is available you can create an AAAA record as well. The documentation also notes that having Proxied turned on for the A records is not necessary, but that it does prevent those snooping around from easily finding your current IP address.

The third prerequisite is SSH access to the device, with a link to the Synology Knowledge Base article on signing in with root privilege over SSH. The fourth is specific to SRM users, since vi is the only text editor available in the Busybox environment on the SSH command line there, with a link to a vi command reference.

So there are four things to have ready: a scoped API token, existing DNS records, root SSH access, and for SRM, some tolerance for editing files in vi.

Installing with one wget and bash line

Two installation paths are documented, and the recommended one avoids SSH entirely.

The first is via Task Scheduler. You open Control Panel, then Task Scheduler, then Create, then Scheduled Task, then User-defined script. In the General tab you name the task, set the User to root, which the documentation marks as important, and uncheck Enabled, since the task only needs to run once. In the Task Settings tab the Run command is:

        wget https://raw.githubusercontent.com/mrikirill/SynologyDDNSCloudflareMultidomain/master/install.sh -O /tmp/install.sh && bash /tmp/install.sh

You click OK, select the new task, click Run, and once it has finished you check the result under Action and can delete the task. Running it from the Task Scheduler means the install script never needs a shell session, and the running root task is visible in the interface as it executes.

The second method is over SSH, and the command is the same script with a different destination path and sudo:

  wget https://raw.githubusercontent.com/mrikirill/SynologyDDNSCloudflareMultidomain/master/install.sh -O install.sh && sudo bash install.sh

For DSM users the SSH service is enabled under Control Panel, Terminal & SNMP, Enable SSH service, and for SRM users under Control Panel, Services, System Services, Terminal, Enable SSH service. For SRM you must be connected as root, since no other username will allow the commands to run. The documentation also tells you to deactivate SSH afterwards if you do not need it, because leaving it active is a security risk.

The repository layout backs the implementation up. There is cloudflare.php, which is the provider itself, an install.sh at the root, composer.json for the PHP dependencies, a run_tests.sh and a tests/ directory, an mkdocs.yml with a docs/ directory for the documentation website, and a SECURITY.md alongside the MIT LICENSE and CONTRIBUTING.md.

Configuring the DDNS entry and the pipe separated hostname list

Whichever install method you used, there is a required configuration step in the Synology interface, and this is where the multidomain behaviour is actually expressed.

DSM users go to Control Panel, External Access, DDNS, then add a new DDNS entry. SRM users go to Network Centre, Internet, QuickConnect and DDNS, DDNS, and press the Add button.

The fields are where the details live. The Service provider dropdown gets Cloudflare, which is the entry this project adds to the list. The Hostname field is no longer used, and the documentation says you can put any value there. The Username field is where the domain goes, and this is the field that changed meaning relative to the standard Cloudflare provider. For a single domain it is the domain itself, and for multiple domains it is a pipe separated list, for example subdomain.mydomain.com|vpn.mydomain.com, with the documentation noting that each domain has to be separated by the pipe character. The Password field takes the Cloudflare API key you created.

There is a 256 character limit on the hostname input, which is the constraint that makes the extended capability meaningful, since it is the limit the Synology form imposes.

One behaviour worth knowing about is the interaction with the DSM version. The documentation's table of contents includes a troubleshooting entry for the case where Cloudflare is no longer listed as a DDNS provider after a DSM or SRM update, and a separate entry on the Cloudflare API free domains limitation, along with one for a connection test that fails or returns an error. Those entries are the place to look when the provider dropdown does not show your entry, which is a real risk given that a DSM update can change the provider list the script registers into. The documentation also has a section on default Cloudflare ports and one on a debug script, which is the diagnostic path for a provider that registers but does not update.

A native rewrite sits beside the PHP agent

The most important line in the readme is the announcement at the top: check out the new native version of this agent, written in Kotlin, in a separate repository named KTSynologyDDNSCloudflareMultidomain.

That changes how you should read the maintenance status of what is in front of you. This PHP project is not the author's preferred implementation any more. The Kotlin repository is the version the author is pointing people towards, and it exists because a native agent can integrate with the Synology platform in ways a PHP script dropped into a directory cannot.

The version history here is v2.4 released on 2026-04-06, v2.3 on 2025-12-13 and 2.2 on 2024-09-19, and the last push to this repository was on 2026-04-06. So the PHP agent is still being maintained in the sense that it is not abandoned, but the cadence has been roughly a release every several months, and the newest release is the same day as the last commit.

For an evaluator this is the deciding fact. If you are starting fresh, the native Kotlin agent is the version to evaluate, and the PHP one is worth reading as the reference implementation of the same idea, including how the Cloudflare token and the hostname list are handled. If you already have this installed, the migration question becomes whether the native version reads your existing configuration or whether you re-enter the hostname list and the API key.

The date also tells you what to expect from this repository going forward. With the last push on 2026-04-06, the PHP agent is a snapshot rather than a moving target, so you should plan around the Kotlin version for anything new.

Editorial conclusion

Adopt SynologyDDNSCloudflareMultidomain if you run a Synology NAS on a residential connection with a dynamic address, you already have a Cloudflare zone, and you want the built-in DDNS screen to update multiple hostnames. Do not adopt it if you need a maintained upstream, since the last push was on 2026-04-06 and the author has published a separate native Kotlin rewrite, or if your names are served by something other than Cloudflare. Verify first that the A record already exists for each hostname you list, that your API token has Zone DNS edit and Zone read for the zones involved, and that the pipe separated hostname list you type into the DSM field is what the script expects.

Frequently asked questions

Official sources

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