GrowthBook is also open source. How is Apertio different?

Both are open source, and both aim to keep experiment data in your own infrastructure. GrowthBook queries your warehouse today; Apertio emits a clean exposure event to a pluggable sink, with a warehouse-native default on the roadmap. The difference is the unit of change. GrowthBook’s no-code visual editor mutates the DOM underneath, the same client-side pattern that risks flicker and adds a third-party-script surface. Apertio has no DOM-mutation path. Variants are data rendered by your own components, and the deployed code is the authority on what can render.

What does "the deployed code is the authority" mean in practice?

The slot schema compiled into your running app is the security boundary. The platform stores variant values, but the SDK re-validates every value against the embedded schema at resolution time and clamps or falls back to the default if it is out of bounds. A compromised platform or a stolen API token cannot make the app render something the deployed schema does not allow.

Does Apertio have feature flags and multi-language SDKs like GrowthBook?

Not at GrowthBook’s breadth. Apertio is React-first and Next.js-first, and its current SDK is the layered @apertio/core, @apertio/react, and @apertio/next. If multi-language flag delivery is a hard requirement today, GrowthBook covers more ground.

Compare

The GrowthBook alternative where your deployed code is the authority on what can render

GrowthBook is the closest open-source reference for Apertio, but its visual-editor path still mutates the DOM. Apertio has no DOM-mutation path: variants are bounded content, and the schema in your deployed code is the authority on what can render.

GrowthBook is the closest open-source reference for Apertio, and a fair starting point if you are evaluating Apertio. Both are open source, and both aim to keep experiment data in your own infrastructure. GrowthBook queries your warehouse today; Apertio emits a clean exposure event to a pluggable sink, with a warehouse-native default on the roadmap. The difference is the unit of change. GrowthBook’s flag SDK runs your own code, but its no-code visual-editor path is DOM mutation underneath, the same client-side pattern that produces flicker and a third-party-script surface. Apertio has no DOM-mutation path at all. A variant is bounded structured content rendered natively by your app’s own components, and the schema compiled into your deployed app is the authority on what can render.

Apertio vs GrowthBook
Dimension	Apertio	GrowthBook
Rendering model	Resolved data rendered by the app's own components; Apertio never touches the DOM	Feature flags plus a visual editor; the no-code path mutates the DOM underneath
Injected third-party JS	None. The SDK is the app's own version-pinned, auditable code	Yes on the visual-editor path; the SDK/flag path runs your own code
CSP impact	Strict nonce-based CSP with no unsafe-inline and no unsafe-eval stays intact; nothing to whitelist	The flag SDK is CSP-friendly; the visual editor follows the client-side-editor pattern that typically needs CSP allowances
Type safety	Slot definitions are TypeScript; types flow to the app and the editor, validated end to end	Generated SDK types for flags
Where experiment data lives	Warehouse-native: exposure and metric data land in the customer's own warehouse, no egress (planned per current docs; see flag)	Warehouse-native: queries run against the customer's warehouse
Open source + license	Yes, MIT	Yes, open-source core with a commercial cloud

Slots as the contract, not generated flag types

In Apertio the slot definition is the source of truth. It lives in code, owned by engineering, and from it Apertio derives runtime validators, the TypeScript type map your app consumes, and the editor UI marketing uses. The code line and the eng-to-marketing line are the same line: schema in code, values on the platform. Every value is validated against the embedded schema again at resolution time, so even a compromised control plane or a stolen token cannot make the app render out of bounds. The deployed code clamps or falls back to the slot’s mandatory default.

Security-first posture

No DOM mutation

Apertio supplies resolved values; your components render them. There is no path where the platform mutates the live page.

Embedded schema is the authority

The schema in the running app is the security boundary. The platform is an editing mirror that cannot exceed it.

Bounded and enumerable

Every possible rendered output is known in advance, which makes a pre-launch audit real and is verifiable in CI by diffing live config against the deployed schema.

The honest tradeoff

GrowthBook is mature where Apertio is early. It has a large community and public GitHub traction, a broad feature set across feature flags, experimentation, and product analytics, SDKs across many languages, and SOC 2 plus GDPR posture. Apertio has none of that breadth yet. Phase 0 is built and verified, the SaaS control plane and publish CLI exist, but Apertio is an early framework, not a drop-in for everything GrowthBook does. Apertio also carries its own honest limitation: only modeled slots are testable, so a novel surface still needs a small engineering change. If you want a battle-tested platform with feature flags, multi-language SDKs, and an existing compliance story today, GrowthBook is the safer choice. Apertio’s bet is narrower and sharper: bounded content rendered natively, with a security-first posture, for teams who will not accept any DOM-mutation path.

Security-first experimentation, open source

Apertio is open source and MIT licensed. Read the docs to instrument your first slot, or star the repo on GitHub.

Read the docs Start free

Frequently asked questions

Is Apertio a drop-in replacement for GrowthBook?: No. GrowthBook is a mature platform with feature flags, multi-language SDKs, product analytics, and an existing SOC 2 and GDPR posture. Apertio is an early, TypeScript-first, React-first framework focused on one thing: bounded content rendered natively with a security-first posture. It does not match GrowthBook’s breadth, and migrating means modeling the surfaces you want to test as typed slots. Choose Apertio for the bounded-content and no-DOM-mutation guarantees, not for feature parity.
GrowthBook is also open source. How is Apertio different?: Both are open source, and both aim to keep experiment data in your own infrastructure. GrowthBook queries your warehouse today; Apertio emits a clean exposure event to a pluggable sink, with a warehouse-native default on the roadmap. The difference is the unit of change. GrowthBook’s no-code visual editor mutates the DOM underneath, the same client-side pattern that risks flicker and adds a third-party-script surface. Apertio has no DOM-mutation path. Variants are data rendered by your own components, and the deployed code is the authority on what can render.
What does "the deployed code is the authority" mean in practice?: The slot schema compiled into your running app is the security boundary. The platform stores variant values, but the SDK re-validates every value against the embedded schema at resolution time and clamps or falls back to the default if it is out of bounds. A compromised platform or a stolen API token cannot make the app render something the deployed schema does not allow.
Does Apertio have feature flags and multi-language SDKs like GrowthBook?: Not at GrowthBook’s breadth. Apertio is React-first and Next.js-first, and its current SDK is the layered @apertio/core, @apertio/react, and @apertio/next. If multi-language flag delivery is a hard requirement today, GrowthBook covers more ground.