Yes, I think that is the part that is puzzling me.
Since this is program code, there are infinite ways you can change it to acheive what you want.
The build from source approach
The way I would recommend going about it is to replicate the way it is done with the open source version. Simply clone the repo, make the changes, and build as normal, using
This way you can always just pull in the changes from the main Duplicati repo, and re-build to get a new version. The only required part is setting up your own private key (done with
AutoUpdateBuilder.exe). To have updates working as well, you just need a server that you can upload to, and then serve the files over standard HTTP(S). If you prefer not to fiddle with it, just use S3.
If you look in
build-release.sh, you can see a number of environment variables that are used to configure the build:
As you can see, some stuff is stored in
UPDATER_KEYFILE is mandatory, but the rest is optional (uncomment the lines, or make them blank).
Near the end of the script it uploads the files:
You can create an AWS CLI profile with the name
duplicati-upload to avoid changing the script. If you use another method for uploading the files (dropbox, webdav, ssh, etc) you can change the lines in your repo.
The last step is building the installers, which is done mostly with Docker, but requires a VM for building MSI and a MacOS host for building the dmg/pkg files:
You can look in the
build-installers.sh file to see how that is performed, but it is always done by extracting the zip file contents, and then making an installer around that.
The OEM build approach
The documentation in the wiki page is meant for people who want to make a single installer package (say an MSI) based on the open source build.
The intended use case for this is internal company distribution or for use by a school. In this case the IT department wants to spend very little effort (i.e. no manual builds, no update servers, etc), but wants a preconfigured Duplicati instance on multiple machines.
To do this, you can download the release .zip file, place a number of “OEM” files outside the build directory, and then invoke one of the installer scripts.
The installer will then include these “OEM” files, but otherwise run the normal Duplicati, piggy-backing on the updater infrastructure, getting new releases etc.
Since these OEM files need to be future-compatible, it is possible that things change in the future and breaks these add-ons. Simple changes like setting a custom name, or a “powered by” line are unlikely to break stuff, so that could be one possible use.
The OEM approach also allows you to provide a custom URL for providing updates, and possibly re-signing the updates with your own key. This gives you full control over when users see an update, but has the added hassle of having to maintain that part as well.
This will allow you to inject/change things prior to giving the user the update. If you go through all this, you might as well build everyting from source, but if you only have frontend developers, you can use this method to avoid having to build the Duplicati binaries.