Abby

Abby is an open-source feature flag, remote configuration, and A/B testing platform built for TypeScript developers who want compile-time safety alongside runtime flexibility. Unlike generic feature management tools that rely on string keys and runtime lookups, Abby threads your project configuration as TypeScript generics through its SDK, so the compiler catches mismatches between your code and your dashboard before they reach production.

The platform is structured as a Turborepo monorepo with a shared core SDK and dedicated packages for React, Next.js, Angular, Svelte, Node.js, and Remix — each framework adapter wraps the same core logic and exposes idiomatic hooks and utilities. The backend is a Next.js application using the T3 Stack (tRPC, Prisma, Tailwind), with a separate Hono-based REST API layer that serves flag data to client SDKs with Redis-backed caching for performance.

Abby is privacy-first by design: it collects no personalized user data and uses no marketing cookies. All A/B test data is anonymized, making it suitable for teams operating under GDPR, HIPAA, or other data regulations. You can self-host the entire stack using Docker Compose — the included configuration spins up MariaDB, Redis, and MailHog for a fully local environment — or use the hosted service at tryabby.com.

The project includes a browser DevTools extension for real-time inspection of active flags and remote config values, a CLI tool for managing configuration from the terminal, and an environment isolation system that lets teams test flag combinations in dev and staging before enabling them in production.

What You Get

• Compile-Time Type-Safe SDKs - Framework-specific SDK packages for React, Next.js, Angular, Svelte, Remix, and Node.js that encode your project’s flag and variant configuration as TypeScript generics, catching configuration mismatches at build time rather than runtime.
• Multi-Environment Isolation - Define separate dev, staging, and production environments per project so flag states can be tested and promoted independently without affecting live users.
• A/B Testing with Weighted Variants - Run A/B tests with custom variant names and configurable weight distributions; the SDK handles variant assignment with cookie-based persistence so users see consistent experiences across sessions.
• Remote Configuration - Manage typed string, number, JSON, and boolean remote config values from the dashboard and read them in your app through the same type-safe SDK surface, without requiring code deployments for value changes.
• Browser DevTools Extension - Inspect active feature flags and remote config values in real time through a dedicated developer tools panel, with the ability to override values locally for testing purposes.
• Privacy-First Architecture - No personally identifiable information is collected, no marketing cookies are set, and all event data is anonymized — making the platform compliant with GDPR and suitable for regulated industries.
• Hono-Based CDN API Layer - A lightweight Hono HTTP server sits in front of the flag data API with Redis-backed in-memory caching, so flag lookups are fast and don’t hammer the database on every request.
• CLI Tool - A command-line interface for creating and managing feature flags and remote config entries from the terminal, integrable into CI/CD pipelines.

Common Use Cases

• Typed feature rollout in a Next.js app - A frontend team defines a new feature flag in the Abby dashboard, adds it to their createAbby() config, and immediately gets TypeScript autocompletion for useFeatureFlag('newCheckout') — the compiler errors if they typo the flag name, and the flag can be enabled per environment without a code deploy.
• Gradual A/B test rollout - A product team creates an A/B test with ‘control’ and ‘redesign’ variants weighted 80/20 in staging, validates metrics, then shifts the production environment to 50/50 from the dashboard without touching code.
• Remote config for per-tenant limits - A SaaS platform stores tier-specific limits (API rate caps, feature quotas) as remote config values typed as Numbers and reads them at runtime, updating limits for all tenants instantly from the dashboard without a redeploy.
• GDPR-compliant behavioral testing - A European startup self-hosts Abby to run A/B tests on onboarding flows with zero PII collection, satisfying DPA requirements while still getting statistically meaningful variant data.
• Flag inspection during incident response - An on-call engineer opens the Abby DevTools panel in a staging browser tab to immediately see which feature flags are active for the affected environment, narrowing down which recently-enabled flag caused a regression.

Under The Hood

Architecture Abby is organized as a Turborepo monorepo with a clear dependency hierarchy: a framework-agnostic core SDK sits at the base, framework-specific adapter packages (React, Next.js, Svelte, Angular, Remix, Node) build on top of it, and a Next.js web application and Hono-based CDN API form the server tier. The web app uses tRPC for type-safe server/client communication between the dashboard frontend and backend routers, while the public REST API for SDK flag data runs on a separate Hono router with route factories that allow modular composition. Redis provides request caching and rate-limiting at the API layer, and Prisma ORM handles all database access with MariaDB as the persistence backend. The SDK achieves its compile-time type safety by threading the project’s flag and test configuration as TypeScript generics through a createAbby() factory function, so every downstream hook and utility inherits precise key and variant types without manual annotation.

Tech Stack The backend web application is built on Next.js with React and TypeScript following the T3 Stack pattern, using tRPC for end-to-end type-safe RPC between frontend and server-side routers. Hono provides the lightweight HTTP framework for the public flag data API and CDN edge function, paired with Zod for runtime request validation. Prisma is the ORM targeting MariaDB; local development uses Docker Compose to orchestrate MariaDB, Redis, and MailHog together. Turborepo orchestrates the monorepo build with task-level caching, and Biome replaces ESLint and Prettier with a unified linting and formatting pipeline across all packages. Client SDKs are published as individual npm packages and support React, Angular, Svelte, Node.js, Remix, and Next.js. Tailwind CSS with shadcn/ui components handles the dashboard UI.

Code Quality Test coverage exists across the SDK packages using Vitest, with test suites for the core SDK (variant selection, feature flag retrieval, remote config, weighted math), the React SDK, Next.js SDK, Node SDK, Remix SDK, and Svelte SDK — covering both happy paths and edge cases like weighted variant correctness and environment-aware defaults. TypeScript is used comprehensively with strict generics, and Biome enforces consistent formatting and linting across all packages in a single configuration pass. Abstract service classes on the server side provide clean boundaries around database access, rate limiting, and caching. Error handling relies on explicit type narrowing and fallback values rather than custom error hierarchies, which keeps the codebase approachable but means errors surface as generic throws in some paths. No CI configuration was visible in the repository root, though the Turbo task graph provides a disciplined build and test pipeline.

What Makes It Unique Abby’s defining technical differentiator is its compile-time type-safe SDK API: by accepting the entire project configuration object as a TypeScript generic at createAbby() time, it ensures that useFeatureFlag(), getVariant(), and getRemoteConfig() calls are checked against known flag and variant names at compile time — a level of safety absent from most self-hostable feature flag tools, which typically rely on loosely-typed string identifiers. The multi-framework SDK architecture allows a single core implementation to power framework-native hooks and utilities across React, Angular, Svelte, Remix, and Node without duplicating flag evaluation logic. Combined with the privacy-first event model — where no PII is ever collected and all data is anonymized by design rather than by configuration — Abby occupies a niche as a developer-experience-first, compliance-friendly alternative to commercial feature management platforms.

Self-Hosting

Abby is released under the GNU Affero General Public License v3.0 (AGPL-3.0). In practical terms, this means you can use, modify, and self-host the software freely, including for commercial purposes. The key obligation is that if you modify Abby and make it available over a network — for example, running it as a service for others — you must also make your modified source code available under the same AGPL-3.0 license. If you are running Abby purely for internal use within your organization and not offering it as a hosted service to third parties, the AGPL copyleft clause does not require you to publish your changes.

Self-hosting Abby is straightforward for teams with standard Docker infrastructure. The repository ships with a Docker Compose file that orchestrates a MariaDB database, Redis cache, and MailHog email testing server, along with a multi-stage Dockerfile that produces a minimal, non-root Next.js standalone image. You will need to provision and maintain these services yourself — database backups, Redis availability, SSL termination, and environment variable management (NextAuth secrets, Stripe keys, email credentials, Redis URL) are all your responsibility. Database schema migrations are handled through Prisma and must be run as part of your deployment process. The Turbo-based build pipeline makes local development reproducible, but production deployments require your own orchestration layer.

Compared to the managed service at tryabby.com, self-hosting means you own all your flag data and never send it to a third party — a meaningful advantage for regulated industries. What you give up is the operational overhead abstraction: the hosted service handles uptime, database backups, scaling, and version upgrades automatically. The project’s activity level has slowed in recent months with very few commits per month, so self-hosters should factor in the risk of reduced upstream maintenance when evaluating long-term operational support.