Feature idea: "overrides"/theming system

[aendra-rininsland]

At the moment, Docker Compose is probably the most common way of hosting Ozone, as per the Hosting.md instructions.

The downside of that is if I wanted to e.g. redesign the moderation interface to better fit my specific needs as a 3rd party labeller, I have to effectively "hack core" -- fork the repo, build a Docker image from it, update compose.yaml to the new image, run that instead of bluesky-social/ozone:latest. This is fine for development but for production services it's really suboptimal because it breaks the Watchtower integration; you don't get updates to the base image without rebuilding your child image, unless I misunderstand how Watchtower works.

Some system that allows you to sideload in different templates or configs or some such might be one way of getting around this.

[baatl]

Isn't it possible to just use Ozone for the backend and deploy an additional container for the alternative frontend? I'm not sure how much hacking that'd involve in the Caddyfile...

[bnewbold]

I think i'd lean in the direction @baatl mentions: use the existing docker compose setup for the Ozone backend, and leave the unmodified Ozone UI container in there. Then deploy your modified version of the Ozone UI separately (using a docker container or any other solution). The backend would get automatic updates, and you'd have an updated unmodified deployment of the UI (eg, in case needed for some new workflow or feature), plus your modified version of Ozone which can be rebased/updated at your own pace.