Having your team's core communication tool go down and be hard to bring back up can be quite painful. So as a project, we put a lot of effort into release management to minimize the risk of that happening. I personally postmortem every report of an error when upgrading.

As a result, for most folks, installing a security/bugfix release Just Works with a few seconds of downtime. For a release like this one with 3000+ commits, dozens of database migrations, and tons of new features, our largest sites found it Just Worked with about a minute of downtime while the database migrations were running.

If you really care about availability like we do with zulipchat.com, it's possible to have downtime be seconds even with the database migrations, but that requires a bit more expertise on how Zulip works than we think it's fair to expect server administrators to learn, so we don't recommend that to most folks.

So the main downside in this space of self-hosting is that zulipchat.com runs very close to master, which in practice means you'll get new features on zulipchat.com first (though folks running their own server can always upgrade; you just end up on the hook for the work). On the flipside, self-hosting is better for i18n (since our volunteer translators generally make sure languages get to 100% around a release, but new strings may not get translated for weeks after the code gets into production on zulipchat.com).