Flag keys, types, and defaults ship in the same pull request as the code they gate.
PostHog alternative
Feature flags without the analytics suite.
Use shipd when you want flags in git. Keep PostHog if the product is funnels, replay, and events.
PostHog bundles feature flags with product analytics, session replay, and surveys.
Git source of truth
0 extra hops
PR environment plan
$0 to start
Where the products differ
PostHog is a product analytics suite that also ships flags. shipd is only release control: keys in the repo, evaluation on the request path.
| Topic | shipd | PostHog |
|---|---|---|
| Job to be done | Release control. Flag keys in git, local evaluation. | Product analytics first. Flags are one feature among many. |
| Flag keys | Defined in shipd.config.ts and reviewed in git. | Flags are created in the PostHog UI and referenced from SDKs. |
| Targeting | Dashboard today. Targeting rules in code is on the roadmap. | Cohorts and person properties from the analytics product drive targeting. |
| Evaluation | SDK loads a signed snapshot and resolves in-process. Postgres is not on the request path. | PostHog SDKs can evaluate locally after loading payloads. The control plane is still PostHog. |
| Experiments | Variants exist. There is no stats engine. | Experimentation sits next to analytics, replay, and event capture. |
| Pricing | Free tier, then seat-based Pro from $15 per member / month. | Usage-based analytics pricing. Confirm current rates on posthog.com. |
Choose shipd when
- You want flags as a dedicated system, not a sidebar in an analytics product.
- Flag keys should be reviewed in git with the code they gate.
- Evaluation must stay in-process with a full decision trace.
- You do not want to send product analytics through your flag vendor.
Stay on PostHog when
- You already live in PostHog for events, funnels, and session replay.
- Flags should target the same persons and cohorts as your analytics.
- You want one vendor for product analytics and feature flags.
Be precise
What shipd does not claim
Targeting still lives in the dashboard
Flag keys are config as code today. Targeting rules in the repository are coming. Until then, rollouts and audiences are edited in shipd, not in git. Evaluation is still local: see local evaluation.
Not an experimentation suite
shipd evaluates variants. It is not a stats engine, and it is not trying to replace LaunchDarkly experiments, Statsig pulse, or PostHog analytics.
Not a PostHog replacement
shipd does not do session replay, funnels, or event pipelines. Comparison pages against PostHog are about flags, not analytics.
Questions
- Is shipd a PostHog alternative?
- For feature flags, yes, if you want keys in git and local evaluation. It is not an alternative to PostHog analytics, replay, or CDP-style event capture.
- Can I use shipd with PostHog analytics?
- Yes. Keep PostHog for product analytics and use shipd for flag definitions and in-process evaluation.
- Does shipd evaluate flags locally?
- Yes. The SDK downloads a snapshot and checks flags in memory. Your app does not call shipd on every request.
- Is there a free plan?
- shipd has a free plan: 5 projects, 100 flags, 5 members. Pro is $15 per member / month.
Define once. Evaluate everywhere.