# wagle > wagle is a multi-project, multi-environment feature-flag and typed remote-config > service built for very-high-traffic apps. Flags live in memory and are evaluated > locally inside your application by its SDKs, with no per-evaluation > network hop and no database on the hot path. It is deterministic (xxHash64 > bucketing), multi-tenant and multi-environment from day one, evaluates > byte-identically across its Go and TypeScript SDKs and the server, and versions > every config change atomically with an audit history. Note: wagle.sh is used as the canonical base URL below (inferred from the project's own domain); adjust if the deployment host differs. ## Core pages - [Landing](https://wagle.sh/): what wagle is, the six core properties, a nine-slide console tour (real screenshots of the flag desk, targeting graph, history and live SDK), and sync-metered pricing. - [Why & how, no bullshit](https://wagle.sh/why): a candid explanation of what it is, how it works, and (stated plainly) the deliberate trade-offs and where it is a poor fit. - [Docs: API, SDKs, MCP](https://wagle.sh/docs): task-oriented quickstart — authenticate (user JWT or agent refresh-to-access token), install the Go or TypeScript SDK (plus the browser-trust twin and React hooks), stay fresh with a versioned conditional poll (interval per client, default 30s; an unchanged poll is a tiny response), call the same Connect-over-HTTP endpoints with curl (runnable in the browser — set a base URL and bearer token and Run signup → create → evaluate against your own server), and connect an agent over MCP. Every snippet is transcribed from the SDKs and proto, never invented. ## Comparisons Honest comparison pages: real pros and cons in both directions, every competitor claim sourced from third parties (reviews, buyer data, docs, never their marketing), and each page states plainly when NOT to pick wagle. - [All comparisons](https://wagle.sh/vs): the hub, with the honesty policy. - [wagle vs LaunchDarkly](https://wagle.sh/vs/launchdarkly): LaunchDarkly wins SDK breadth (~30 vs 2), bundled experimentation and enterprise governance; wagle differs on a single predictable per-sync pricing meter, free unlimited local evaluations, and vendor independence. - [wagle vs Unleash](https://wagle.sh/vs/unleash): Unleash wins self-host, data residency, governance and SDK breadth (all conceded); wagle wins nothing-to-operate hosting, per-sync pricing vs $75/seat, and a browser SDK that evaluates locally. - [wagle vs Flagsmith](https://wagle.sh/vs/flagsmith): Flagsmith wins self-hosting, an open-source core and SDK breadth; wagle keeps evaluation in-process (no remote-eval default) with nothing to run. Says when to pick Flagsmith instead. - [wagle vs ConfigCat](https://wagle.sh/vs/configcat): wagle's closest cousin (hosted + local-eval SDKs). ConfigCat wins SDK breadth (~21), all-tier SSO/SAML/SCIM incl. free, on-prem, and an 8-year track record; wagle wins a versioned conditional poll (cheap unchanged checks, per-client interval) and native JSON typed config. Neither runs experiments, by design — measuring outcomes is the analytics stack's job, not a flag service's. - [wagle vs PostHog](https://wagle.sh/vs/posthog): PostHog bundles flags with analytics, replay and experiments on a generous 1M-request free tier; wagle is flags-only with in-process eval by default. Cites PostHog's own Oct-2025 flag post-mortem. - [wagle vs GrowthBook](https://wagle.sh/vs/growthbook): GrowthBook wins outright on experimentation (best open-source stats engine, warehouse-native, 24+ SDKs); wagle fits only flipping flags and typed config without a data warehouse, on one per-sync meter. - [wagle vs Firebase Remote Config](https://wagle.sh/vs/firebase-remote-config): Firebase is the mobile config default and wagle has no mobile SDKs; wagle competes only for server-side teams wanting real per-environment config, a flag-first lifecycle with audit, and no Google coupling. ## How it works (one line each) - Evaluation is local: SDKs seed a snapshot once (a sync), keep it fresh on a per-client poll interval, and evaluate in-process with zero per-eval network hops. - Keyed by (project, environment): every flag, segment and evaluation is scoped to a project and an environment; environment folds into the bucket hash so each buckets independently. - Deterministic bucketing: xxHash64 over "{project}:{environment}:{flag}:{entity}", mod 10000, a stable, reproducible rollout. - Atomic versioned writes: each write bumps a single per-(project, environment) version and appends audit history; readers never see a torn config. - Cross-SDK fairness: the Go SDK, TS SDK and server share one normative algorithm pinned by a byte-identical vector file in CI. - Server-only flags: a flag can be excluded from the client sync so internal keys and rules never ship in a public bundle. ## Honest trade-offs (see /why for detail) - Flag changes are eventually consistent (picked up on each SDK's next poll), not an atomic global switch. - Auth built in but simple: JWT/session, three fixed per-project roles; no SSO/SAML yet. - Segments are one level deep on purpose (no nesting); compose by ANDing segments in a rule. - Every instance holds the whole index in memory, so memory scales with config size. - Segment membership is bounded (default 10,000 values); no member pagination. ## Pricing - [Pricing](https://wagle.sh/#pricing): you pay per SDK sync (the config pull); local evaluations are always free and unlimited.