Architecture

An application platform with a connected data foundation.

Onyx brings development, research, and AI into a shared platform. Application runtimes, task execution, and database services have distinct responsibilities, connected through scoped APIs and persisted operations.

Workspaces

Web and mobile applications, agent tasks, Git history, private previews, and releases.

Agent Research

Investigations, permitted actions, reports, supporting files, and saved progress.

AI and models

Reusable agent workflows, model training, published predictions, and APIs.

Onyx platform services

Organizations and roles · Scoped APIs · Model access · Secrets · Task and release history

Onyx Database

Structured records, indexes, search, and schema-defined relationships. Connect application logic through APIs, saved scripts, and TypeScript, Python, Kotlin, or Go SDKs.

An organization with optional database bindings

Workspaces belong to an organization. New apps include a database by default; projects can also connect an existing database or add one later. Samples clone their own database. Organization membership and database roles determine which operations are available.

Application execution on a workspace runtime

A Workspace runtime manages Git checkouts, coding tasks, preview applications, and release images. Application code runs in isolated containers. The runtime can run alongside the API or on a separate execution host; the control plane records operations and results.

Research with scoped access

Research code runs in an isolated task environment. A scoped gateway provides authorized database reads and explicitly granted operations. Saved-script execution uses the same task permissions; database credentials stay outside the research environment.

Configuration belongs to an environment

Development, staging, production, and custom environments bind their own databases, authentication settings, and secrets. Managed credentials are injected into application servers, with separate credentials for migration jobs. Private starter previews use verified Workspace identity; deployed starters use Firebase sign-in.

A release records what is running

Publishing records a Git commit, immutable application image, configuration version, and migration version. Build, migration, startup, and readiness stages report their results before a successful traffic switch. Promotion reuses the existing image on the connected runtime.

Recovery follows the kind of change

Saved task state supports follow-ups and explicit continuation after interruption. Git checkpoints recover selected files. Application rollback selects a compatible release image. Schema compatibility checks keep application rollback separate from database migration recovery.

Live data stays behind application authorization

Browser and native clients call authenticated application routes. The server checks user access and queries the environment’s live Onyx database through the SDK. Task inspection uses a separate scoped gateway; its temporary access is never an application credential.

Mobile builds connect to a deployed backend

The mobile starter uses Expo and React Native for Android, iOS, and web. EAS builds a committed source snapshot with public app configuration and remote signing credentials. Phone apps use Firebase tokens to call the deployed backend; database credentials remain on that server. Store testing submissions and public store releases are separate steps.

The database is still at the heart of your application.

Model entities and relationships in the schema. Resolver-defined relationships let your application retrieve connected data, while indexed queries and search support everyday access. Research uses its own restricted operations; the full database API and SDKs serve application code.