--- title: Connect PostHog to your Expo app in one command authors: Gabe Debes published: September 9, 2026 --- Adding PostHog to a React Native app used to mean creating an org, creating a project, installing three or four packages depending on the features you wanted, wiring up a config plugin, copying keys between browser tabs, and setting up all the local and remote environments so not only you but your whole team and CI could leverage it. Now it's one command: ```console $ $ eas integrations:posthog:connect ``` It creates your PostHog org and project, installs the SDK, adds the config plugin, and writes your keys into `.env.local` and your EAS environment variables for Production, Preview, and Development. You choose the data region and the features you want. If you are already on PostHog, it opens your browser once to link your existing org and project, then runs the same setup. ## What you can learn from it Product analytics tells you what your users did. This integration tells you which release they were on when it happened, with almost no setup. Today, a few lines in your app register `eas/update_id`, `eas/channel`, and `eas/runtime_version` as super properties. From then on, every `capture()` call carries them. Your EAS Workflows speak the same language: pass the same `eas/` names to `posthog_capture_event`, filled from contexts like `${{ app.id }}` or job outputs like `build_id`, and an event from your CI looks exactly like one from a phone. PostHog knows these names. It shows the Expo logo next to each one and turns the identifiers into links back to expo.dev. Click an `eas/update_id` in PostHog and you land on that update in your Expo dashboard. That changes how you debug. With a funnel dropped on Tuesday, you can now break it down by update ID, find the update it started on, and open it. A crash spike, a slow screen, a retention dip after a channel rollout: same move every time. No timestamp matching, no tab juggling. It also changes what your pipeline can do on its own. EAS Workflows can capture events, mark deploys on your PostHog charts, roll a feature flag forward or back, and hold a job until a live metric clears. Publish an update to 25 percent of users, watch the exception count for 30 minutes, and let the workflow decide whether it goes to everyone or gets pulled. ## Rollouts that watch themselves That last part deserves a closer look, because it changes what release day feels like. Every EAS Workflow is a chain of jobs, and PostHog now has steps in that chain with native workflow functions! `posthog_flag_rollout` sets a feature flag to a percentage. `posthog_wait_for_metric` runs a HogQL query on an interval and holds the job until the result clears your threshold, or the timeout fails it. `posthog_wait_for_query` is the yes-or-no version: it clears as soon as the query returns true. Put them next to your update or build job and the workflow stops being a fire-and-forget script. It waits, it looks at production, and it picks the next job based on what it sees. Feature flags aren't the only lever. The same pattern works with EAS Update channel rollouts. Send 10 percent of a channel to the new update, watch the error rate, then widen to everyone or revert. The recipe also records how close each rollout came to its threshold as a PostHog event, so after a few weeks you have a chart of your own release health. From those pieces we built a few more. A kill switch that turns a flag off the moment errors spike, on a schedule, with nobody on call. A nightly error budget check that only speaks up once you've spent the budget. A store submission job that adds an annotation to your PostHog timeline, so every deploy shows on the charts your team already looks at. And `posthog_upload_sourcemaps` in the build job, so stack traces in PostHog error tracking point at your TypeScript instead of a minified bundle. ## Get started today! Run `eas integrations:posthog:connect` in a project linked to EAS. Pick a region, pick your features, and let it finish. Then wrap your app in ``, add the release properties, and make a development build. Fire one test event and open PostHog with `eas integrations:posthog:dashboard` to watch it land. A note on Expo Go: product analytics works there. Session replay and crash symbolication need a development build, and release tracking only kicks in once your app is running a real update. [Using PostHog](https://docs.expo.dev/guides/using-posthog/) walks through the full setup, and we have over 10 EAS Workflows [recipes](https://docs.expo.dev/guides/using-posthog/recipes/) ready to drop into your `.eas/workflows/` or [native functions](https://docs.expo.dev/eas/workflows/syntax/#easposthog_capture_event) ready to be used within your existing workflow. We are excited to unleash the power of observability combined with automation and what you all will build with it!