MyBotBoxMyBotBox
Architecture

Architecture

How MyBotBox is built — the C4 model, request pipeline, multi-tenancy, and execution data flow.

MyBotBox is a multi-tenant platform for building, deploying, and running AI agent workflows. This section is the system-design reference: how the pieces fit together, how a request is authenticated and authorized, how tenants are isolated, and how a workflow actually runs.

These pages describe the hosted architecture. The same codebase is self-hostable — every external dependency (database, cache, queue, storage, email, LLM provider) sits behind a swappable port, so you can point it at your own infrastructure.

At a glance

graph LR
    subgraph BUILD ["Build"]
        A[Visual Canvas] --> B[190 Blocks]
    end
    subgraph ENGINE ["Engine"]
        C[Serializer] --> D[Executor DAG]
        D --> E[30 Block Handlers]
    end
    subgraph DEPLOY ["Deploy"]
        F[REST API]
        G[Webhook]
        H[Schedule / Poll]
        I[Chat]
    end
    B --> C
    E --> F & G & H & I

A workflow is authored on a ReactFlow canvas, serialized into an execution graph, run by a topological DAG executor that dispatches each node to a typed handler, and deployed as an immutable version reachable by API, webhook, schedule, poll, or chat.

In this section

Technology

LayerTechnology
RuntimeBun, Turborepo monorepo
FrameworkNext.js 16 (App Router), React 19, TypeScript (strict)
DatabasePostgreSQL 17 (Cloud SQL) + pgvector, Drizzle ORM (90 tables)
Cache / rate-limitMemorystore Redis 7 (sliding window), in-memory fallback
QueueCloud Tasks + Cloud Functions (async dispatch, polling)
AuthFirebase Auth (OAuth, SSO/SAML, TOTP), JWT session cookie
AI17 provider adapters (OpenAI, Anthropic, Gemini, Bedrock, …)
PaymentsStripe (subscriptions + usage metering)
HostingGoogle Cloud Run (blue-green canary deploy)
ObservabilityOpenTelemetry, Sentry, Datadog
On this page

On this page