Releases

gRPC 1.82.0 is a routine release with incremental Core, PHP, Python, and Ruby fixes and no security issues or breaking changes. Highlights are two xDS protocol additions (A85 ORCA-to-LRS, A114 weighted round robin) alongside a batch of smaller bug fixes.

gRPC v1.81.1 is a patch release fixing memory safety bugs on Windows and ARM, plus Python/Ruby housekeeping. No API-breaking changes.

• breakingPython 3.9 and Ruby 3.1 are no longer supported

  If your services run gRPC Python on 3.9 or Ruby on 3.1, upgrading to v1.81.1 will break your build. Check your runtime versions before upgrading. Python 3.10+ and Ruby 3.2+ are the minimum now.

• enhancementUpgrade Windows/ARM deployments to get memory safety fixes

  Two Windows EventEngine races and an ARM completion queue shutdown race are fixed. If you run gRPC servers on Windows or ARM-based hosts (e.g., Graviton), this patch is worth applying — use-after-free and assertion crashes are hard to reproduce but can cause random service failures.

• enhancementprotobuf 7.x now allowed for gRPC Python

  The grpc-status package previously capped protobuf at <6.x. With the upper bound relaxed to 7.x, you can now unpin protobuf in Python services that use grpc-status alongside other libraries requiring newer protobuf versions.

gRPC v1.81.0 drops Python 3.9 and Ruby 3.1 support, fixes crash-level races on Windows and ARM, and adds AsyncIO observability for Python.

• breakingPython 3.9 support dropped — check your runtime

  gRPC Python 1.81.0 drops Python 3.9 support. If your services still run on Python 3.9, stay on an older gRPC release until you can upgrade your runtime. Plan the Python version bump before pulling this release.

• breakingRuby 3.1 support dropped — upgrade your Ruby runtime

  Ruby 3.1 has reached EOL and gRPC 1.81.0 drops support for it. If you're running Ruby 3.1 in production with gRPC, you'll need to upgrade to Ruby 3.2+ before adopting this release.

• enhancementWindows and ARM stability fixes worth taking

  Two EventEngine fixes address a use-after-free and a race condition causing assertion errors on Windows, plus a completion queue shutdown race on ARM (weak memory model). If you run gRPC on Windows or ARM-based infrastructure, this release directly fixes stability issues that could cause crashes. Upgrade when stable.

gRPC v1.80.0 delivers TLS private key offloading, EventEngine enabled by default in Python, and a raft of Python async/AIO bug fixes that affect production stability.

• securityPrivate key material no longer needs to live in process memory

  The private key offload feature means TLS signing can be delegated externally. For teams running in regulated environments, upgrade to v1.80.0 and migrate to the offload-backed credential provider to eliminate the attack surface of in-process key storage. This applies to both the Python signer implementation and the core C++ offload path.

• breakingEventEngine is now the default I/O backend in Python — test before upgrading

  EventEngine replacing the legacy polling engine by default changes how gRPC Python handles I/O, threading, and fork behavior. A fork-support env var default was reverted (PR #41769) in this same release, signaling the area is still stabilizing. Run your existing Python gRPC workloads in a staging environment before promoting to production, and pay attention to any fork-based server patterns (e.g., gunicorn pre-fork).

• enhancementAdopt Private Key Offload for secrets-safe TLS

  The new TLS Private Key Offload implementation and InMemoryCertificateProvider let you keep private keys in an HSM or KMS and rotate certs at runtime. If you run gRPC servers with compliance or secrets-management requirements, this is the right upgrade path. Wire up the new signer interface and drop file-based credential loading where you can.

gRPC v1.78.1 is a maintenance release addressing critical Python fork handling issues and Ruby 4.0 compatibility, with no breaking changes for most users.

• enhancementUpgrade to resolve Python multithreading issues

  This release fixes a critical bug where Python applications using gRPC in multithreaded environments with fork() would hang with 'Other threads are currently calling into gRPC, skipping fork() handlers' errors. If you're experiencing similar issues, upgrade immediately and test your fork-heavy workloads.

• enhancementPlan Ruby 4.0 migration path

  With Ruby 4.0 support now available, review your Ruby-based gRPC services for compatibility testing. The native gems should provide better performance, but validate your deployment pipeline supports the new Ruby version before upgrading production systems.