On this page

Deprecation Notices

Deprecation notices for Statsig server SDKs, including end-of-life versions, breaking changes, and recommended upgrade paths to Server Core SDKs.

Direct initialization API access for server SDKs, October 31, 2025

What's changing?

Until mid-2024, Statsig's Server SDKs downloaded configuration values directly from Statsig servers on startup. Statsig now hosts these configuration files on a secure CDN (Cloudflare), which reduces initialization time and increases reliability.

Direct API access is deprecated. It is only available in outdated SDK versions. All customers must stop using these SDK versions and upgrade.

Change required

The only change required is a minor SDK version bump. No code changes are needed. Bump your SDK version to at least:

  • go-sdk 1.30.3
  • java-server 1.9.0
  • py-server 0.28.0
  • ruby-server 1.29.0
  • statsig-node 5.25.0
  • .NET 2.4.1
  • Node-lite 0.5.0
  • PHP 3.7.2

Make this change by October 31st, 2025.

CDN access is only available in a more recent version of the PHP and .NET SDKs, so Statsig won't strictly enforce an upgrade for those 2 SDKs. Upgrade as soon as possible.

New method for country resolution

Starting December 9th, 2024, Statsig uses a more accurate method of resolving IP addresses to country codes in client SDKs, which may result in different gate behavior for some users. For country resolution in both Client and Server SDKs, Statsig uses a homegrown package that lacks IPv6 support. To resolve countries without increasing SDK size, Statsig uses the cloud provider's country resolution when serving requests to the /initialize endpoint.

Potential changes in client evaluations

This may result in different evaluations for some client-side checks. The new method is more accurate and complete. You may see more users passing country rules, because the new method resolves countries for IPv6 users, who now represent a large share of many customers' user base.

Conflicts with server-side checks

If you check some configs on both the client and server side, a small number of users may pass targeting on the client but fail on the server, or vice versa. Server-side country resolution continues to use IP3Country when a country isn't explicitly set on the StatsigUser object. To avoid conflicts, use your cloud provider's country resolution (often available in a load balancer) and set the result as the country field on the StatsigUser object. This applies to evaluations for gates, configs, experiments, and layers, and also to getClientInitializeResponse when generating the payload for a client SDK.

Async evaluation functions

Reason

Server SDKs were originally designed for maximum backward compatibility. If a Server SDK didn't support an operator or configuration, it fell back to Statsig servers to ensure a valid result, which required asynchronous top-level evaluation functions.

In practice, this fallback is rarely needed. Newer releases remove the asynchronous functions.

Example

java
var result = await Statsig.checkGate("my_gate"); // Bad
// For node v6.0.0
var result = Statsig.checkGate("my_gate") // Good
// For .Net and Java
var result = Statsig.checkGateSync("my_gate"); // Good

SDKs

.NET Server - v1.20.0NodeJS Server - v5.10.0Java/Kotlin Server - v1.12.0

Was this helpful?