How it Works

RootCX has two components: Studio (where you build) and Core (where things run). Everything you create --applications, AI agents, integrations --lives on a single Core instance that provides the entire backend infrastructure.

Studio + Core

RootCX Studio is a native desktop app (macOS, Windows, Linux). It connects to a Core instance over HTTP. You use Studio to write code (or generate it with AI Forge), deploy with a single keystroke, and monitor your running fleet.

RootCX Core is a Rust daemon. It manages the database, enforces authentication and RBAC, runs your backend processes, serves your frontends, and exposes the REST API. One Core instance runs your entire fleet of apps --whether that's one tool or several hundred.

Studio and Core are decoupled. You can connect Studio to a local Core running on Docker, or to a remote Core hosted on RootCX Cloud or on your own infrastructure. Multiple developers can connect their Studio to the same Core.

The Build → Deploy → Run cycle

1. Build

In Studio, you describe what you want to AI Forge, or write the code manually. A project is composed of:

• A manifest (manifest.json) that declares entities, fields, and permissions.
• A frontend -- a React app using the @rootcx/sdk to interact with the Core's Data API.
• An optional backend -- JavaScript or TypeScript handlers for RPC calls and scheduled jobs, executed by the Core in an isolated Bun process.

2. Deploy (F5)

When you hit Run, Studio executes a pipeline against the Core:

1. Schema verify --validates the manifest.
2. Manifest sync --the Schema Sync Engine applies entity/field changes to PostgreSQL (creates tables, columns, indexes).
3. Install dependencies --runs bun install if needed.
4. Deploy backend --uploads and starts the backend worker under the Core's process supervisor.
5. Publish frontend --uploads static assets to the Core, which serves them at /apps/{appId}/.

This pipeline is idempotent. Change anything, hit Run again, and Core applies the diff.

3. Run

Once deployed, the Core handles everything at runtime:

• Authentication --JWT-based sessions (Argon2id password hashing, HS256 tokens).
• RBAC --role assignments with inheritance, enforced at the database level before any query runs.
• Data API --auto-generated CRUD endpoints for every entity declared in the manifest.
• Backend processes --supervised Bun workers communicating with the Core via JSON-line IPC.
• Job Queue --durable, PostgreSQL-backed background job scheduling.
• Secret Vault --AES-256-GCM encrypted key-value store, injected as environment variables into backends.
• Audit Log --PostgreSQL triggers capture every INSERT, UPDATE, and DELETE. Immutable.
• Real-time Logs --stdout/stderr from all backends, streamed to Studio via SSE.

The Fleet model

Every application, AI agent, and integration you deploy runs on the same Core. They share the same database, the same authentication system, and the same permission model. This is what makes them a fleet --not isolated silos, but interconnected services that can reference each other's data and capabilities.

An AI agent can query data from any application in the fleet. An integration can push external data into entities used by multiple apps. Everything stays consistent because it all flows through the same Core.

Further reading

• Core reference --detailed technical reference for the Core daemon.
• Build an Application --manifest format, frontend SDK, backend handlers.
• Build an AI Agent --create autonomous agents that run on your Core.
• Self-Hosting --run the Core on your own infrastructure.