[Feature] Better update / migration notes

[mikew]

Trying to just update to the latest Onyx. Had trouble getting docker-compose to even start because:

• a bunch of stuff related to /bin/sh needed to be removed from various services in the yaml
• the web container has been hardened
• now my installation accepts signups from random people on the internet, despite being only OIDC before
• the background container is failing due to what feels like the hundredth change to SANDBOX env vars

I'm begging here, is there any public documentation on what steps need to be performed when updating? Is there any one place someone managing an Onyx install can go to read anything they would need so there's no ugly surprises? Onyx is pretty nice to use but even maintaining an install with docker compose (which is painless for the 15 other services I'm running) is a constant headache when it comes time to update.

[jmelahman]

I hear the frustration. A lot of the hardening work was my doing. The good news is it's a one-time cost and it's mostly done. The intentions are good as we want a very secure application people can trust, but that is not always easy.

A lot of my work recently has been moving these bespoke shell incantations out of the docker-compose.yml files where they don't belong and into application initialization code. In other words, now that the public interface is simple, we are able to change the initialization logic without breaking things going forward.

I can't think of any issues particular to the web image hardening though. If you have something specific, let me know.

It's not a concern you mentioned, but I also think our configuration surface area is enormous and we're trying to move that out of app_config.py environment variables & docker-compose switches, and into a proper configuration file with UI-driven configuration.

I've been toying with the idea of an onyx-installer which also handles upgrades, possibly as part of the `onyx-cli, and I think it is just worth it at this point.

We do maintain https://docs.onyx.app/changelog and try to call out breaking-changes when they occur, but sometimes we miss them -- these upgrade paths are especially easy to miss given how infrequently they're expected to change combined with the fact this isn't typically something covered by CI for projects.

now my installation accepts signups from random people on the internet, despite being only OIDC before

is a likely a proper bug we should fix -- I haven't heard anything about this yet

the background container is failing due to what feels like the hundredth change to SANDBOX env vars

This sounds craft-related(?) which I'm personally not well versed in. My understanding is this is still in pre-release development and subject to large changes, so not sure how much is expected to change here.

[mikew]

Appreciate the human response. Onyx is very useful and sets a pretty high bar, as a user I'm really impressed. It's the ops side that is tough to keep up with. So this reply is coming from the ops perspective.

A lot of my work recently has been moving these bespoke shell incantations out of the docker-compose.yml files where they don't belong and into application initialization code. In other words, now that the public interface is simple, we are able to change the initialization logic without breaking things going forward.

❤️. Those were obviously going to be a pain

I can't think of any issues particular to the web image hardening though. If you have something specific, let me know.

It was most likely my own fix for the HOSTNAME environment variable issue, so maybe a nothingburger there.

It's not a concern you mentioned, but I also think our configuration surface area is enormous and we're trying to move that out of app_config.py environment variables & docker-compose switches, and into a proper configuration file with UI-driven configuration.

I've been toying with the idea of an onyx-installer which also handles upgrades, possibly as part of the `onyx-cli, and I think it is just worth it at this point.

A better config file would be a huge relief. I'm not psyched about OIDC config being limited to the UI. It's good to also have the UI option, but OIDC specifically is really handy at the system config level.

I also wouldn't be a huge fan of requiring a dedicated onyx-installer tool, for installation or updating. Something like GitLab is also a complex beast to run, but keeping up with their updates was a breeze with docker-compose given their blog posts. Tho I have used projects that have codemods for upgrades and yes they are a huge help.

now my installation accepts signups from random people on the internet, despite being only OIDC before

is a likely a proper bug we should fix -- I haven't heard anything about this yet

It looks like at some point during the AUTH_TYPE refactoring the login page started rendering more like the CLOUD variant (which rendered SSO buttons along with a login form) and now all code paths render EmailPasswordForm.

the background container is failing due to what feels like the hundredth change to SANDBOX env vars

This sounds craft-related(?) which I'm personally not well versed in. My understanding is this is still in pre-release development and subject to large changes, so not sure how much is expected to change here.

The most frustrating thing about all the craft-related issues I've ran into is that I'm trying to run without craft enabled 🥹.ENABLE_CRAFT has always been false on my install, but various parts of the stack still complain about docker in docker, kubernetes, proxies...

[discountscott]

I hear the frustration. A lot of the hardening work was my doing. The good news is it's a one-time cost and it's mostly done. The intentions are good as we want a very secure application people can trust, but that is not always easy.

A lot of my work recently has been moving these bespoke shell incantations out of the docker-compose.yml files where they don't belong and into application initialization code. In other words, now that the public interface is simple, we are able to change the initialization logic without breaking things going forward.

I can't think of any issues particular to the web image hardening though. If you have something specific, let me know.

It's not a concern you mentioned, but I also think our configuration surface area is enormous and we're trying to move that out of app_config.py environment variables & docker-compose switches, and into a proper configuration file with UI-driven configuration.

I've been toying with the idea of an onyx-installer which also handles upgrades, possibly as part of the `onyx-cli, and I think it is just worth it at this point.

We do maintain https://docs.onyx.app/changelog and try to call out breaking-changes when they occur, but sometimes we miss them -- these upgrade paths are especially easy to miss given how infrequently they're expected to change combined with the fact this isn't typically something covered by CI for projects.

now my installation accepts signups from random people on the internet, despite being only OIDC before

is a likely a proper bug we should fix -- I haven't heard anything about this yet

the background container is failing due to what feels like the hundredth change to SANDBOX env vars

This sounds craft-related(?) which I'm personally not well versed in. My understanding is this is still in pre-release development and subject to large changes, so not sure how much is expected to change here.

We are seeing the authentication issue now as well after updating. There should be no 'create an account' option, only single sign-on.