Automate the upgrade process

[jamesefhawkins]

Could we get self-deployed users to upgrade automatically?

Why?

• This would need to be a setting, but defaulting it to on could really help with retention as we iron out bugs and make the product more useful over time.
• Means if we ever have a vulnerability or large bug, we could quickly get patches out into production

I suspect this may be technically very hard to do. There would be some risk that it could break plugins. Wordpress I know does this if we want to get ideas for how it could work.

[mariusandra]

I've been thinking about this as well. This is hard to do, but not impossible. Hard because 1) there are many ways people can install posthog (heroku, source, docker, etc), 2) we can't modify what's inside a docker container in a way that persists over restarts, 3) sometimes a new version requires more than just an updated image, e.g. the addition of a plugin server that must be launched separately.

The best idea for making this work that I've found so far is basically "docker in a docker". The posthog image would be a container that would contain another image which can be swapped out on the fly. I couldn't find any ready made images for such an usecase though.

It would be really cool to have an "evergreen" posthog instance though.

Plugins shouldn't be affected by this. They are run in a different service and we'll try to not do any breaking changes here.

[macobo]

The tricky part here is indeed the different deployment options.

I think if we know which ones we want to focus on (most frequent ones) providing this isn't hard for them individually. For example, in cloudformation it would mean creating a new 'ecs' task on demand. We can inject secrets needed to do that as the deployment gets created.

One thing that needs to be addressed first though is https://github.com/PostHog/deployment/issues/39

[mariusandra]

Should we move on with this in any capacity?

We release quite frequently and I don't blame the users for having other things to do, but having an easier and more automatic way to upgrade posthog will surely help adoption.

I discussed this with Karl and there are basically two things we can try:

1. Improve documentation for upgrades. For example if you have the Heroku app, clicking "new version available" will give you a command to run to upgrade the app... for ECS it'll give you a link to click to open the right page and will tell you to click "refresh" there. Same for other deployments. This is a quick win that might lessen the pain enough.

2. Create some kind of "installer" or "container" system. So the posthog image itself will be a container that contains another container plus a method to update the inner container with some API call. I haven't seen anything like this in the wild and perhaps for a good reason, but there's nothing that's preventing us from building something like that.

Thoughts? Does any server-hosted software come to mind that does this well?

[paolodamico]

For what is worth, I've generally gotten positive comments on the upgrade process from customer calls, particularly in AWS (users say it's quite straightforward). On the other hand we do have a significant amount of installations not in the latest version.

[posthog-bot]

This issue hasn't seen activity in 6 months. Is it still relevant?

[lowe0292]

Chiming in here. We started using PostHog on Heroku about 9 months ago, starting with the Heroku 1 click install.

Today I'm trying to install the GeoIP plugin and I'm getting this error:

Error: This PostHog version does not have GeoIP capabilities! Upgrade to PostHog 1.24.0 or later

I've done some Googling and searched your docs and still don't quite understand how to upgrade my PostHog version. I first checked the in-app settings, hoping there was an upgrade button. If you guys could point me in the right direction here, I'd appreciate it. 🙏

[tiina303]

@lowe0292 hi this is a bit of a different issue, but for a manual upgrade on Heroku see https://github.com/PostHog/posthog.com/blob/ee01390744dffdb32f2f78b49572c606becb03b9/contents/docs/self-host/deploy/heroku.md#upgrading-posthog-on-heroku
Which can be found following a link to "In case you are running PostHog backed by Postgres you can find the upgrade instructions here." on https://posthog.com/docs/self-host/configure/upgrading-posthog

[guidoiaquinti]

@jamesefhawkins is this issue still relevant or do you think we can close it?

[mariusandra]

I think an easy or automatic upgrade is essential if we want self-hosting to succeed.

I also believe there's one way we can "relatively easily" (all things considered) support automatic or semi-automatic self-hosted upgrades: cloud-specific "PostHog Upgrader" apps.

For example a "PostHog DigitalOcean Upgrader" app. This is just a page in PostHog itself (in the sidebar or not, doesn't matter). This app would, depending on the complexities involved with each cloud, guide you in upgrading your posthog instance, in one of these levels:

• Level 0: you get a page with links to documentation on how to upgrade your app on this specific cloud provider
• Level 1: specific commands you must copy/paste to get the upgrade done
• Level 2: connect your DO credentials, and have a live view of what pods are running in your k8s, and see their logs
• Level 3: that, but also manage local chart values, and run helm upgrade through the DO API directly

We'll eventually get some small cloud providers who will provide their own level 3 upgrader apps.

[posthog-bot]

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

[Twixes]

Closing, as we no longer support production-level self-hosted deployment of PostHog (Sunsetting Kubernetes support for PostHog)