[FEATURE] - Branding and customizations.

[bitbound]

Subscribers will have access to customized, branded builds of the server, agents, and desktop clients. They will be able to choose their own product name, icon, color palettes, and server URL. These options will be recompiled in GitHub Actions (in a private repo) and signed using my existing Azure Key Vault flow.

I'm considering two different ways of implementing this. I'd like to hear from the community on which one they'd prefer, or if they'd prefer something different altogether. Since ControlR is now my only source of income, and this is the only monetized aspect of the project, it's important that people are happy with it.

I'll add each implementation as a separate comment to this issue. Please vote (using 👍) for which one you'd prefer. Or if you'd prefer neither, add a comment with a suggested alternative.

[bitbound]

Option 1 (custom image)

Shared steps for both options:

• User logs into a ControlR Subscriber's Portal website, using GitHub auth.
• The backend queries GitHub API to determine if the user is at or above the necessary sponsorship level.
  • It also checks if the user is part of an org that is sponsoring.
  • If this is the case, the user will need the required permissions from the org.

Steps specific to option 1:

• If authorized, the user can update the customizations/branding and run builds.
• Customization sets can be saved in "templates", so you can easily switch between different customizations.
• There will be "slots" for holding customized images.
  • I'm thinking of starting with 2 or 3 slots.
  • This allows users to test out new builds or experiment with branding, and quickly roll back to another image if necessary (without having to rebuild it).
• To update a slot with a new image, you select the customization template and ControlR version, then hit Build.
• When the image is built, it will show the command needed to pull the image.
• The image will be in a private GitHub registry and only accessible by the user/org.

Pros:

• Less things that can go wrong during upgrades.
• Probably less dev time/effort than option 2.

Cons:

• A little more initial setup due to the private Docker registry.

[bitbound]

Option 2 (in-server)

Shared steps for both options:

• User logs into a ControlR Subscriber's Portal website, using GitHub auth.
• The backend queries GitHub API to determine if the user is at or above the necessary sponsorship level.
  • It also checks if the user is part of an org that is sponsoring.
  • If this is the case, the user will need the required permissions from the org to create custom builds.

Steps specific to option 2:

• You'll be able to create/regenerate an API key here to use in your ControlR server.
• In your ControlR instance (using the public Docker Hub image), there will be a new Branding tab for server admins.
• Here, you will save your API key and choose branding options.
• After changing branding options, the ControlR backend will reach out to the my sponsor's portal backend, using the API key for authentiction.
• This will kick off new builds for each platform's agents and desktop clients, targeting the same version as the server that's requesting them.
• Like with option 1, these builds will run in GitHub Actions, and the new binaries will be signed using Azure Key Vault flow.
• Once finished, these will be downloaded by your ControlR backend and saved to a Docker volume.
• These customized versions will then override the default versions that come in the image.
• Icons and color customizations will also apply to the server's UI after reloading.

Pros:

• Avoids need to authenticate with custom Docker registry.
• Most of the user workflow stays inside ControlR.

Cons:

• More moving parts and edge cases that can go wrong.
• Probably more dev time/effort than option 1.