fix(billing): separate client side and server side envvars for billing

[waleedlatif1]

Summary

separate client side and server side envvars for billing

Type of Change

• Bug fix

Testing

Tested manually.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
sim	🔄 Building	Preview	Comment	Aug 14, 2025 6:29pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
docs	⬜️ Skipped			Aug 14, 2025 6:29pm

[greptile-apps]

Greptile Summary

This PR addresses a fundamental issue with billing environment variable access in the Next.js application by introducing proper separation between client-side and server-side billing configuration. The core change adds a new NEXT_PUBLIC_BILLING_ENABLED environment variable alongside the existing server-only BILLING_ENABLED variable in apps/sim/lib/env.ts. This new client-accessible variable follows Next.js conventions where NEXT_PUBLIC_ prefixed variables can be accessed in browser contexts.

The PR then refactors four React components that previously relied on server-side billing checks to use the new client-side variable via the getEnv('NEXT_PUBLIC_BILLING_ENABLED') utility function. These components include the settings modal, main sidebar, and settings navigation components - all of which need to conditionally render billing-related UI elements like subscription management panels, usage indicators, and navigation items.

This change integrates with the existing environment variable architecture by leveraging the universal getEnv function from @/lib/env, which uses next-runtime-env for client-side runtime variable injection with fallback to process.env for server contexts. This approach supports Docker deployments where environment variables need to be injected at runtime rather than build time, maintaining consistency with the codebase's established patterns for environment configuration.

Confidence score: 5/5

• This PR is safe to merge with minimal risk as it follows established patterns and maintains backward compatibility
• Score reflects straightforward environment variable refactoring with proper Next.js conventions and consistent implementation across all affected files
• No files require special attention as the changes are well-structured and follow the codebase's existing environment variable patterns

_{4 files reviewed, 1 comment}

_{Edit Code Review Bot Settings | Greptile}

[greptile-apps]

style: Consider type safety - getEnv returns string | undefined but you're applying || false. The environment variable should be explicitly parsed as boolean.