RebelAI

Self-hosted character chat for people who want their own keys, data, and control.

RebelAI is a self-hosted character chat stack for people who want to bring their own API keys and keep conversations on infrastructure they control. It is built around ownership, portability, and explicit product boundaries rather than platform lock-in.

Why This Exists

RebelAI is built on a simple idea: character chat should be able to grow without making creators, users, or operators hostages of a single platform.

Platforms, moderation rules, and product boundaries are normal. The real problem is irreversible lock-in: losing your data, your characters, or your ability to move because one service controls the whole stack.

That is why RebelAI keeps self-hosting, BYOK, portable native formats, and explicit trust boundaries together. The goal is not to deny platforms. The goal is to preserve the ability to keep work, move it, and rebuild without starting from zero.

What RebelAI Optimizes For

• Your keys: bring your own model API keys and control your own cost surface
• Your data: keep conversations, characters, and assets in infrastructure you operate
• Your server: self-host the app instead of depending on a platform-owned runtime
• Portable character stack: use RebelAI-native RBX + SUU instead of raw HTML/script card execution
• Boundary-conscious design: separate core, fallback, experimental, and removal paths instead of treating every feature as equally trusted

Who This Is For

• People who want BYOK instead of platform-managed model billing
• People who care about data ownership and self-hosting more than instant hosted convenience
• Character chat users who want less platform lock-in
• Power users and developers who care about format boundaries, trust boundaries, and deployability

Who This Is Not For

• People looking for a fully hosted sign-up-and-go chat service
• People who want the simplest possible setup with no deployment or operations responsibility
• People who expect experimental features to have the same support promise as the core path

What Makes It Different

Many chat products can offer one or two of these. RebelAI is explicitly trying to keep them together:

• self-hosted deployment
• bring-your-own-key cost control
• data ownership
• a portable native character format
• bounded transcript recall for exact older dialogue recovery when summaries are not enough (experimental)
• trust-boundary-first engineering choices

This is also why RebelAI avoids broad security marketing claims. The goal is not to claim perfect safety. The goal is to keep the trust surface explicit, narrow, and reviewable.

Current Operating Mode

• Public signup is still closed by default.
• The active first-class mode is a maintainer-operated closed / low-cost deployment.
• Vercel Pro + Supabase Pro is still documented as a future public-serving profile, not as the current day-to-day default.
• Exact behavior should be treated as code-first. README is the entry point, not the exact source of truth.

If you want the current doctrine behind support levels and experimentation boundaries, read docs/SUPPORT_BOUNDARIES.md.
If you want the current operating defaults and public-opening gates, read docs/OPERATING_PLAN.md.

Quick Start

Prerequisites

• Node.js 24.x
• Supabase account
• At least one supported model API key

Minimal Setup

git clone https://github.com/devforai-creator/rebel-ai.git
cd rebel-ai
nvm use
npm install
cp .env.example .env.local
npm run dev

For the actual environment and Supabase setup flow, use:

• docs/GETTING_STARTED.md
• SUPABASE_SETUP.md

Read Next

• docs/GETTING_STARTED.md: fastest route from checkout to a working local or closed deployment
• docs/HOSTING_PROFILES.md: low-cost closed profile vs future managed public profile
• docs/SUPPORT_BOUNDARIES.md: stable doctrine for core / fallback / experimental / removal
• docs/FIRST_CLASS_SMOKE_CHECKS.md: post-deploy verification for the current first-class mode
• docs/OPERATING_PLAN.md: maintainer operating note for current defaults and public-opening gates
• SECURITY.md: security model, reporting policy, and self-hosting requirements
• docs/README.md: full docs map

Implementation Notes

The repo still includes a lot of engineering detail, but that detail now lives in docs and code instead of the landing page. In practice:

• runtime behavior lives in active code paths and tests
• schema truth lives in supabase/migrations/, supabase/schema.sql, and generated types
• maintainer operating decisions live in docs/OPERATING_PLAN.md
• stable support philosophy lives in docs/SUPPORT_BOUNDARIES.md

License

AGPL-3.0-or-later. See LICENSE.

License history: versions up to and including the commit tagged apache-2.0-final (commit 0fd90cacf7cfc64192aceef40b432b9218b981cf) were released under Apache-2.0 and remain available under that license. All later versions are licensed under AGPL-3.0-or-later.