Architecture
The most differentiating thing about Ember is not the chat UX. It is the proprietary pipeline that sits behind every project, every iteration, every deploy. Generic vibe-coding tools hand the user a zip file and tell them to figure it out. Ember runs a custom, audited, security-gated, version-swapping deploy pipeline for every action the user takes - and the user never sees it. This page shows what is in the engine.
Ember in one picture
Reading the diagram top-down: a user chats with the Web App, the orchestrator drives the Ember Pipeline through nine stages, the result lands in an isolated container in the Workloads tier, and external platforms (Telegram, X, Discord) integrate at the workload layer for the agent target. Every action passes through the Audit Logger and the Realtime Event Emitter so the platform's state is observable end-to-end.
The Ember Pipeline - the proprietary CI/CD
This is the thing that takes a prompt and produces a working, deployed, isolated, signed, audited application. Each of the nine stages is a deliberate piece of engineering, and the combination is what generic vibe-coding tools cannot ship.
Stage 1: Spec Collector
A purpose-built conversational LLM call refines what the user wants into a structured intent: target type, template pattern, slot values, required secrets. The collector is deeply integrated with the rest of the platform - it knows the available templates, the skills library, the security policy of each target, and the required-credentials list. It asks clarifying questions rather than committing resources prematurely, and the user can back out at any point without cost. Every interaction is logged and feeds back into improving the collector's intent-recognition over time.
Stage 2: Adaptive Tiered Generator
Three engineered tiers run behind an adaptive classifier that picks the right one for the request's complexity, drawing on the project's iteration history and the template's edit conventions to make the call. The classifier observes outcomes and improves routing over time; each tier is independently tunable so the platform's intelligence sharpens with usage rather than depending on a single static prompt.
Tier 1 - the direct path. A lightning-fast slot-update for content and styling refinements: the kind of change a user makes when they are polishing a working app. The platform knows exactly which files and which fragments are affected, so the LLM is only asked the smallest possible question. Ideal for "change the headline to..." or "make the accent colour navy".
Tier 2 - structural diffs. A single-call multi-file diff generator that handles structural changes: new sections, layout shifts, feature additions, scoped refactors. The LLM sees the project's existing files and the template's edit conventions, then emits a complete patch in one response. Faster than the agentic loop, more capable than the direct path.
Tier 3 - the agentic loop. This is the cutting-edge piece, and the one that separates Ember from single-shot vibe-coding tools. The LLM is given a sandboxed file-system view of the project plus a tool set: read_file, write_file, list_files, check_syntax, lint, and read_template_manifest. It then operates as an autonomous coder, running a self-correcting loop:
- Reads the template's manifest to understand where things live.
- Reads the files it needs to modify.
- Writes the changes.
- Checks syntax and lints its own work.
- If errors come back, reads the error output and writes a fix.
- Continues until the bundle compiles, lints clean, and the user's request is satisfied.
The loop has hard caps (maximum turns per generation, maximum cost per generation) and a stuck-detector (same file written three times → abort) so it cannot run away. Every turn is streamed to the user's dashboard in real time: "reading the navigation component...", "writing the updated styles...", "checking syntax on layout.tsx...", "found a missing import, fixing...". The experience feels like watching a senior engineer work, not waiting on a black box.
This is what makes Ember capable of real refactors, not just first drafts. A user can say "restructure the whole site so the dashboard lives in its own route and add a sidebar", and the agentic loop will do exactly that: inspect what exists, plan the changes, implement them across multiple files, verify the result compiles, and surface clear status the whole way. Generic vibe-coding tools cannot do this - their architecture commits to the LLM's first response, no self-correction, no second chances.
Stage 3: Static Security Gate
Every generated bundle goes through this gate before any cloud resource is allocated. Seven rule families inspect the bundle for secret leakage, dangerous code patterns, unapproved dependencies, network-egress violations, environment-variable abuse, filesystem-escape attempts, and known-malicious patterns. Each target type (web, Telegram bot, X bot, agent) has its own policy. Failures stop the pipeline before anything cloud-side has happened. This is the layer that has caught every red-team prompt to date.
Stage 4: Bundle Assembler
Combines the slot-filled template files with the skills modules the project needs into a single deployable bundle. The skills library is curated and platform-controlled - users cannot inject arbitrary modules. The assembler also produces the hardened Dockerfile and container config; the LLM never writes those.
Stage 5: Image Builder
Builds a container image from the bundle, layered on top of one of Ember's pre-built base images (web runtime base, dev container base, agent runtime base). Pre-built bases drop cold-start time enormously because dependencies are baked in. The Ember Image Registry stores every image with content-addressable digests for reproducibility.
Stage 6: Secret Pusher
Stages per-project secrets into the Ember Secret Vault and pushes them to the target container before deploy. The pusher enforces per-project scoping: a secret can only be written to the container that owns the project, verified against the platform's container ledger. A typo or attacker-controlled container name is rejected here, before any sensitive value leaves the control plane.
Stage 7: Container Provisioner
Creates the per-project isolated container on Ember Compute. Each container gets its own name (ULID-based, never reused), its own private network namespace, and its own scoped secrets store. The provisioner is idempotent and uses an append-only ledger that prevents name reuse forever, even after destruction.
Stage 8: Readiness Verifier
After the container starts, the verifier trusts only the compute platform's authoritative state, not HTTP probes or optimistic flags. The container must report itself ready before the next stage runs. If the container fails to start, the pipeline aborts and the previous version of the project keeps serving traffic untouched.
Stage 9: Traffic Swap
Sequential cutover. The new container serves alongside the old one until the new one is verified healthy; only then does traffic swap and the old container get destroyed. Failed deploys never take down a working version. The swap also updates the project's current-version pointer in the database, which propagates to the edge router for subdomain routing.
That is the Ember Pipeline. Nine stages, each doing one thing well, composing into a CI/CD platform that is purpose-built for AI-generated code with hostile inputs and untrusted bundles. This is not duct-tape over GitHub Actions. It is a custom orchestration system designed for this exact problem.
The pipeline runs asynchronously
A subtle but important design choice: the entire pipeline executes as a background process, not as a foreground RPC. When the user clicks Build, the orchestrator immediately writes the project record to the database, kicks off the pipeline, and returns. The pipeline then runs to completion on the control plane independently of the user's session. Status events stream to the database via Realtime as each stage progresses, and the frontend subscribes to those events so the dashboard always reflects the platform's authoritative state.
What that buys the user: they can close the tab, walk away, and come back later to find their project built. A complex agentic-loop iteration that takes several minutes does not require the user to sit and stare at a spinner. They start the work, do something else, return at their convenience. The dashboard catches up automatically, replays the status events that landed while they were away, and shows them whatever state the project is currently in.
What that buys the platform: resilience. A user network blip does not abort their build. A page refresh does not lose their place. The orchestrator can be horizontally scaled across multiple instances because the work is queue-based rather than tied to an HTTP session. The pipeline can take as long as it needs to take - there is no client-side timeout pushing it to cut corners.
This is industrial-strength orchestration. The user experiences it as "the app just appears", but underneath there is a real distributed-systems primitive at work: durable background execution with realtime status fan-out, the same pattern that powers CI/CD platforms operating at scale.
Core Platform Services
Around the pipeline sit several services that every component of the platform depends on.
Secret Vault. AES-256-GCM envelope encryption with a master key held only on the control plane. All BYO platform tokens (Anthropic, OpenAI, Telegram BotFather, etc.) live encrypted at rest and are decrypted just-in-time at container boot or at API-validation time. The plaintext never persists to disk.
Audit Logger. Append-only log of every privileged action: project creation, deploy start/complete, secret writes, agent tool invocations, destructive operations, token rotations. Each row carries actor, action, scope, and details (with secret patterns scrubbed before insert). The audit log is the trust anchor that makes Ember credible to enterprise customers.
Realtime Event Emitter. Pushes every state transition to the frontend over a websocket-backed subscription. This is why the build status display shows real progress instead of a fake spinner. Every stage of the Ember Pipeline emits events here.
Cost Metering. Every LLM call is metered with token counts, costs, latency, model, and feature attribution. The data flows into an admin dashboard that surfaces cost per feature, cost per template, cost per user. This is what makes the tiered-generation cost story trackable.
Orphan Sweep. Continuous reconciliation between the database (what the platform thinks exists) and the compute layer (what actually exists). Detects ghosts (DB row, no container) and orphans (container, no DB row), surfacing both through the audit log and the admin dashboard. By design the sweep is detect-only - destructive actions on infrastructure require explicit operator approval, never automatic execution. This two-stage pattern (detect → human-approved resolution) is what keeps reconciliation safe and auditable at scale, the same discipline enterprise-grade orchestration platforms apply to their own infrastructure.
Idle Reaper. Garbage-collects dev containers and agent containers that have been idle past a threshold. Pairs with the auto-suspend behaviour on the compute layer to keep cost near zero for inactive users.
Template Registry. The catalog of templates the spec collector can pick from. Templates are versioned by commit and cached locally on the control plane. New templates pass a quality gate (manifest validated, slot definitions complete, sample iteration completes in bounded turns) before they enter the catalog.
Skills Library. Curated, human-authored, security-reviewed modules that templates can require. Examples: auth helpers, database connection pooling, common API client wrappers. Skills are platform-controlled - users cannot inject arbitrary code into the skills library.
Image Registry. Ember's private container image registry, hosting the pre-built base images and every per-project image. Image rolling is automated through the pipeline; new base images propagate to all new project deploys automatically.
Per-Project Workloads
Where generated code actually runs. Three flavours, all built on the same container primitive but configured for their specific job.
Production containers. When the user publishes, a fresh container with its own immutable version ID gets provisioned. Each version of each project is its own container. Sequential swap ensures old versions keep serving until new ones are verified healthy. Per-target hardening: web targets run on slim Linux with a non-root user and production-only dependencies, Telegram/X bots have no inbound HTTP surface (polling-only), and all run with default-deny outbound traffic limited to a per-target allowlist.
Agent runtimes. Long-lived containers for the agent target. Each agent project gets its own container with the user's chosen LLM provider, the user's system prompt, the configured tool set, and per-chat conversation history. The agent loop handles incoming chats (from the dashboard or via webhook from Telegram/X/Discord), runs tool execution in a sandbox with the project's host allowlist, and feeds results back to the LLM for self-correction. Webhooks are HMAC-authenticated using a per-project signing secret.
Dev containers. The iteration preview surface. Hot-reload server on one port, signed writer endpoint on another. Iterations push file diffs to the writer; the hot-reload server detects the change and refreshes. Configuration includes a local git repo that auto-commits per iteration, giving users a free undo history.
All three workload types live behind the Ember Edge for routing. Containers idle-suspend when not in use, waking on the next request - which keeps cost near zero for inactive projects.
Data Layer
Control DB. Managed Postgres with Row-Level Security policies that scope user data per-user. Every user-facing table has an owner-scoped SELECT policy; mutations are service-role only and routed through the orchestrator, which validates ownership before issuing the write. Real-time subscriptions stream status events to the frontend.
Tenant DB. A separate Postgres instance for per-project tenant data. Generated apps that opt for shared-DB mode get a dedicated schema with a scoped role. Cross-tenant access is blocked at the database-role level, verified by impersonation tests in the provisioning module. Apps that opt for BYO mode connect to the user's own Postgres directly.
AI Layer
Platform LLM. A frontier-tier LLM provider drives code generation, iteration, the spec collector, and the theme generator. Prompt caching reduces cost on tier 2 and tier 3 generations significantly. The tool-use API is what powers the agentic iteration loop.
User-side LLM. For the agent target only, the user brings their own LLM provider key. This decouples Ember's cost from the user's conversation volume - the most strategically important architectural decision in the platform. Generic vibe-coding tools cannot ship chatty agents because the per-message cost would destroy their margin; Ember can.
External Platforms
Agents integrate with external platforms through inbound webhooks. The pattern is the same across Telegram, X, and Discord: the user pastes their platform token, Ember validates it, encrypts it, stages it as a per-project secret, and registers the webhook URL on the platform's side. Incoming messages are HMAC-verified against a per-project webhook secret before they reach the agent runtime. Outgoing messages go through built-in tools that the agent's LLM can invoke (send_telegram_message, etc.).
This pattern generalises: adding a new platform is a configuration change plus a small adapter, not a re-architecture. New platforms inherit all of Ember's security defaults (HMAC auth, per-project secret scoping, audit logging) automatically.
How the planes scale independently
Each layer of Ember scales on its own terms.
The frontend is cached at the global edge and can serve a million users without changing the architecture.
The control plane is stateless from a user-request perspective. All state lives in the data layer. Scaling is horizontal - more orchestrator containers behind a load balancer when traffic justifies. The orchestrator is currently a single container; horizontal scaling and high-availability are on the roadmap.
The Ember Pipeline runs per-request as part of the orchestrator's work. Pipeline parallelism is naturally high: many projects' pipelines can run concurrently because they touch disjoint container namespaces and disjoint database rows.
The workload layer scales with the number of active projects. Idle-suspend keeps cost proportional to active iteration, not raw project count.
The data layer scales with Postgres, which is well-understood. Read replicas, connection pooling, and dedicated compute are standard next steps when traffic warrants.
The AI layer's cost is proportional to active iteration on the platform-borne side, and to user usage on the BYO side. The decoupling between those two is what makes the unit economics work.
Why this shape
A platform that takes untrusted prompts, generates code with an LLM, and runs that code with secrets nearby needs three properties that conflict in practice: it has to be fast, it has to be safe, and it has to scale at sustainable unit economics. The Ember Pipeline is the answer to all three at once.
Fast because the pipeline runs in parallel where it can (container provisioning happens while secrets are being pushed), and because each stage is purpose-built rather than glued on top of a general-purpose CI/CD tool.
Safe because the static gate is a non-negotiable stage in the pipeline, not an optional check. Every bundle goes through it. Every red-team test runs against it. Every new target type inherits its policy.
Sustainable because the adaptive generation system matches compute investment to actual request complexity, the per-project containers idle-suspend so dormant projects consume no resources, and the agent target's BYO-key model decouples Ember's cost basis from the user's conversation volume - a structural property that gives the platform enviable unit economics as it scales.
These three properties together are the reason Ember can credibly ship to non-technical users with real budgets while staying secure enough for serious customers. The pipeline is what makes that possible. It is not something a competitor can recreate by gluing together off-the-shelf tools - it is a purpose-built orchestration system, evolved over months of red-team testing and security gates. That depth is the moat.