Skip to content

Conversation

@athul-rs
Copy link
Contributor

What

  • Added build argument to control PostHog analytics at build time
  • Added REACT_APP_ENABLE_POSTHOG build argument to frontend Dockerfile with default value of true
  • Updated sample.env with PostHog configuration documentation, defaulting to false for local development

Why

  • To disable PostHog analytics for on-prem deployments while keeping it enabled for cloud deployments
  • To prevent on-prem customers from sending analytics data to external services
  • To provide privacy-first defaults for local development environments
  • To maintain clean separation between cloud (analytics enabled) and on-prem (analytics disabled) builds

How

  • Modified docker/dockerfiles/frontend.Dockerfile to add build argument:
    • Added ARG REACT_APP_ENABLE_POSTHOG=true (defaults to enabled for cloud)
    • Added ENV REACT_APP_ENABLE_POSTHOG=${REACT_APP_ENABLE_POSTHOG} to pass value to React build
  • Updated frontend/sample.env with documentation and default value for local development:
    • Added REACT_APP_ENABLE_POSTHOG=false (privacy-first for local dev)
    • Added comments explaining the purpose

The build argument will be set in the CI/CD workflows (unstract-cloud repo):

  • Cloud builds: Pass REACT_APP_ENABLE_POSTHOG=true
  • On-prem builds: Pass REACT_APP_ENABLE_POSTHOG=false

During React build, process.env.REACT_APP_ENABLE_POSTHOG gets replaced with the literal value, making it a build-time decision (no runtime complexity).

Can this PR break any existing features? If yes, please list possible items. If no, please explain why.

No, this PR will not break any existing features:

  • The Dockerfile default is true, maintaining current cloud behavior
  • Existing index.js logic (if (enablePosthog !== "false")) remains unchanged
  • Local development gets privacy-first default but developers can override in their .env
  • Build-time substitution means no runtime performance impact
  • Changes are purely additive - no deletions or modifications to existing logic

Relevant Docs

Related Issues or PRs

  • Jira ticket: UN-2236
  • Related PR in unstract-cloud repo (workflows): TBD

Dependencies Versions / Env Variables

  • REACT_APP_ENABLE_POSTHOG: New build argument (defaults to true in Dockerfile, false in sample.env for local dev)

Notes on Testing

  • Cloud build: Verify PostHog initializes and tracks events (check browser DevTools for PostHog API calls)
  • On-prem build: Verify PostHog is disabled (no PostHog network calls in browser DevTools)
  • Local dev: Verify default behavior with .env file (should be disabled)
  • Test that setting REACT_APP_ENABLE_POSTHOG=true in local .env enables PostHog
  • Confirm no breaking changes to existing functionality

Screenshots

N/A

Checklist

I have read and understood the Contribution Guidelines.

🤖 Generated with Claude Code

Added build argument to control PostHog analytics at build time,
enabling cloud deployments while disabling for on-prem installations.

Changes:
- Added REACT_APP_ENABLE_POSTHOG build argument to frontend Dockerfile
- Defaults to true to maintain cloud behavior
- Updated sample.env with PostHog configuration documentation
- Default set to false for local development (privacy-first)

This provides clean separation between cloud (analytics enabled)
and on-prem (analytics disabled) builds without runtime complexity.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 28, 2025

Summary by CodeRabbit

  • Chores
    • Added environment configuration option for analytics tracking in development environments.

Walkthrough

The pull request adds PostHog analytics configuration to the frontend application. An environment variable REACT_APP_ENABLE_POSTHOG is introduced with a default value of true in the Docker build configuration and set to false in the sample environment file for local development.

Changes

Cohort / File(s) Summary
PostHog environment configuration
docker/dockerfiles/frontend.Dockerfile, frontend/sample.env
Added REACT_APP_ENABLE_POSTHOG environment variable to frontend setup: ARG and ENV declaration in Dockerfile with default true, and sample .env entry with value false and explanatory comments for local development.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

  • Straightforward environment variable additions with no logic changes
  • Simple configuration updates that follow existing patterns
  • Minimal risk of unintended side effects

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title Check ✅ Passed The PR title "UN-2236 [FEAT] Add build-time PostHog control for on-prem deployments" directly and clearly summarizes the main change in the pull request. The title accurately reflects the addition of build-time controls for PostHog analytics configuration across the frontend Dockerfile and sample environment file to support different deployment scenarios. The phrasing is concise, specific, and avoids vague terminology, making it immediately understandable for someone reviewing the project history.
Description Check ✅ Passed The PR description is comprehensive and well-structured, covering nearly all template sections with substantive content. The "What" section clearly describes the changes, "Why" explains the rationale for cloud vs. on-prem separation, and "How" provides detailed implementation guidance including CI/CD behavior. The author addresses whether existing features could break with a thorough explanation, documents the new environment variable, provides relevant documentation links, references the Jira ticket, and includes detailed testing notes. The only template section not filled is "Database Migrations," which is appropriately omitted since this change doesn't involve database modifications.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch UN-2236-disable-posthog-onprem

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
frontend/sample.env (1)

3-5: Clear documentation for local development defaults.

The addition is well-documented and appropriately defaults to false for local development, aligning with the privacy-first principle. Consider adding a note to reference the Docker build argument for context when building containers.

Optional: Add a comment referencing the Docker build argument to help developers understand the relationship between local development and container builds:

  # Analytics - PostHog (set to false to disable tracking)
  # Default: false for local development
+ # Note: Docker production builds default to true; override with REACT_APP_ENABLE_POSTHOG=true for local testing
  REACT_APP_ENABLE_POSTHOG=false
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to Reviews > Disable Cache setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 8eb50f7 and bb02f70.

📒 Files selected for processing (2)
  • docker/dockerfiles/frontend.Dockerfile (1 hunks)
  • frontend/sample.env (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: build
🔇 Additional comments (1)
docker/dockerfiles/frontend.Dockerfile (1)

26-28: PostHog integration is complete and correctly implemented.

All verification checks pass:

  1. Frontend code reads REACT_APP_ENABLE_POSTHOG: Confirmed in frontend/src/index.js lines 12-24. Initialization is conditional—PostHog only initializes if the environment variable is not exactly "false".

  2. Network isolation when disabled: Verified. When REACT_APP_ENABLE_POSTHOG=false, the posthog.init() call is skipped entirely, preventing any network requests to PostHog endpoints.

  3. CI/CD configuration: Production builds use the Dockerfile default (true), which is correct for cloud deployments. On-prem deployments can override via --build-arg REACT_APP_ENABLE_POSTHOG=false if needed.

  4. PostHog dependency: Present in package.json (posthog-js ^1.116.5), and the React provider is properly set up with safe null checks in PostHogPageviewTracker.js.

@sonarqubecloud
Copy link

@athul-rs athul-rs merged commit ca78643 into main Oct 28, 2025
6 checks passed
@athul-rs athul-rs deleted the UN-2236-disable-posthog-onprem branch October 28, 2025 12:59

# Analytics - PostHog (set to false to disable tracking)
# Default: false for local development
REACT_APP_ENABLE_POSTHOG=false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
REACT_APP_ENABLE_POSTHOG=false
REACT_APP_ENABLE_POSTHOG=true

@athul-rs the current change would imply that OSS users who are trying the platform will not be tracked in Posthog. Is that fine / expected? We should leave this env as true if we wish to continue to track the OSS user's behaviour
cc: @hari-kuriakose @jaseemjaskp

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chandrasekharan-zipstack I think your analysis might be incorrect. Since OSS users use it through containers and we are adding it as true during build time https://github.com/Zipstack/unstract/pull/1615/files#diff-7273696816af1540ab5f0d5b11c273aa396c0615b1eb25af83199637750baeb1R26 it should work as expcected

muhammad-ali-e pushed a commit that referenced this pull request Oct 30, 2025
…#1615)

Added build argument to control PostHog analytics at build time,
enabling cloud deployments while disabling for on-prem installations.

Changes:
- Added REACT_APP_ENABLE_POSTHOG build argument to frontend Dockerfile
- Defaults to true to maintain cloud behavior
- Updated sample.env with PostHog configuration documentation
- Default set to false for local development (privacy-first)

This provides clean separation between cloud (analytics enabled)
and on-prem (analytics disabled) builds without runtime complexity.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude <[email protected]>
muhammad-ali-e pushed a commit that referenced this pull request Oct 30, 2025
…#1615)

Added build argument to control PostHog analytics at build time,
enabling cloud deployments while disabling for on-prem installations.

Changes:
- Added REACT_APP_ENABLE_POSTHOG build argument to frontend Dockerfile
- Defaults to true to maintain cloud behavior
- Updated sample.env with PostHog configuration documentation
- Default set to false for local development (privacy-first)

This provides clean separation between cloud (analytics enabled)
and on-prem (analytics disabled) builds without runtime complexity.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants