I know nothing about the actual rebranding process so forgive this if it’s a silly question, but is it “segmented” enough to lend itself to a #howto?
I’m picturing different blocks for things like “how to add your own logo”, “how to limit destination types”, and “how to control updates”.
I think so.
It’s not really “segmented”, it’s more a lack of specific details/steps in order to achieve those different approaches (own logos, custom name for binaries, updates server…). The only documentation we really have ATM is this page.
Yes, it kinda is.
From the top of my head you can do the following independently:
Custom name for binaries is in another level because Duplicati looks for a updated .exe file of the same name when launching the most recently updated version. So if you download an updated version with a modified binary name, it will not be found by the base install.
I can try to help but I don’t think this would be the best use of my time at work, so any contribution would probably be at home and unfortunately not a priority for now. It is not hard though, if you have any of the items in that list as a goal and mess around you’ll eventually find out how it is done.
I’m thinking that’s probably correct, but thanks for the input so far! 
Thanks - I keep forgetting about that page! Rather than make another document talking about the same thing, maybe it would make more sense to find out from people who’ve actually customized Duplicati what sorts of information was missing from that page.
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 build-release.sh.
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 ${HOME}/.config/signkeys. The 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.
This explains thoroughly exactly what I did in order to push updates.
I forgot to mention: pull requests for improving the build script for other uses than the current build process are also encouraged.
For instance, we could single out the upload to make it simpler for others to upload packages to their servers.
The build script grew out of a need to do a “fire-and-forget” type release, such that I could do multiple releases in a day, with the least potential for human error in that process.