News/ Zulip 12.1
Zulip 12.1

Zulip on AWS: Now Shipping Zulip 12.1 — Data Export Repairs and Stricter E2EE Push Behavior

August 19, 2026

Our AWS Marketplace Zulip pattern moves from 12.0 to 12.1, an explicit bug-fix release. It repairs a crash in the data-export panel for imported organizations, makes the require-E2EE push setting skip legacy notifications entirely, fixes external-auth signup in invite-only organizations, and adds local-network IP options for webhooks.

The Zulip on AWS by FOSSonCloud pattern now ships Zulip 12.1, up from 12.0. This is explicitly a bug-fix release — cherry-picked fixes on top of 12.0, with no new features. Zulip recommends all installations move to it.

What changed

  • Fixed a crash in the data-export panel in organization settings for organizations that had been imported from another Zulip server. The release includes a migration that repairs export records damaged by the earlier bug.
  • Stricter E2EE push behavior. When the “require E2EE push notifications” setting is enabled, legacy (non-encrypted) push notifications are now skipped entirely instead of being sent with redacted content.
  • Fixed sign-up via external auth methods (like SAML) in organizations that require an invitation — pending email invitations are now honored, not just multi-use invite links.
  • Added configuration options letting webhooks access specific local-network IP addresses.
  • The topic-summarization AI feature switched to the OpenAI Python SDK directly, replacing the litellm abstraction layer.

For context, the feature work landed in 12.0 (April 2026): end-to-end encryption support for mobile push notifications, a major Docker upgrade, and configurable image previews.

Why it matters

The E2EE push change is the one with a real behavioral difference. Previously, enabling “require E2EE push notifications” still sent legacy notifications, just with the content redacted. That’s a weaker guarantee than it sounds: a redacted notification still tells an observer that a message arrived, to whom, and when. Skipping them entirely means the setting now does what its name implies. The trade-off is that users on clients that can’t do E2EE push will stop receiving notifications rather than receiving empty ones — which is the correct behavior for an organization that turned the setting on, but it will look like “notifications broke” to the affected users.

The external-auth invitation fix matters if you use SAML with an invite-only organization. Before 12.1, a user invited by email who signed up through SAML would be rejected, because only multi-use invite links were honored. If your onboarding flow is “send an email invitation, user authenticates via SSO,” that flow was broken and is now fixed.

The data-export fix is narrow but important if it applies to you. Organizations migrated from another Zulip server had a broken export panel — and export is exactly the capability you want working before you need it, whether for compliance, backup, or another migration. The included migration repairs the damaged records rather than just preventing new damage.

The webhook local-network IP options are the practical AWS-relevant addition here: if you have internal services in your VPC that Zulip webhooks need to reach, you can now allow those specific addresses instead of choosing between “no access” and a broader workaround.

What you should do

  1. Update — Zulip explicitly recommends all installations move to 12.1. It’s low risk with no new features to plan around.
  2. If you have “require E2EE push notifications” enabled, tell your users about the change first. Anyone on a client that doesn’t support encrypted push will go from redacted notifications to no notifications. That’s the intended behavior, but it needs to be communicated rather than discovered.
  3. Verify your data-export panel works if your organization was imported from another Zulip server. The migration should have repaired it — confirm rather than assume, and take a test export.
  4. Re-test SSO signup with an emailed invitation if you use SAML in an invite-only organization. This is the fix most likely to unblock an onboarding flow you’d worked around.
  5. Configure webhook local-network IP access only as narrowly as you need it. It’s an allowlist — list the specific internal addresses, not a broad range.
  6. Check your topic-summarization configuration if you use that feature. The switch from litellm to the OpenAI SDK directly is an internal change, but it’s worth confirming your provider settings still apply.

Version details in this post come from Zulip’s own release notes. If you hit anything upgrading the pattern, open an issue on GitHub.

— FOSSonCloud

Try Zulip on AWS

Deploy your own self-hosted instance with a 5-day free trial on AWS Marketplace.

View on AWS Marketplace