Skip to main content

System Overview

Ember is an AI-powered application platform. A user describes what they want - a landing page, a Telegram bot, an autonomous agent - and Ember builds it, deploys it, and hosts it. From "I wonder…" to a real product anyone can use.

What Ember does​

The first generation of vibe-coding tools - Lovable, Bolt, v0 - got something important right: they removed the friction between idea and prototype. A non-developer could now describe an app and watch the LLM produce React. But they all share three limits.

They only build websites. No bots. No agents. No background workers. The output is a static React app, deployable to one of three places, and that's it.

The user has to host it themselves. The tool generates code; the user ships it. Bridging that gap takes a developer.

Generated code runs unsupervised. No security model, no static scanning, no isolation. If the user's prompt accidentally produces unsafe code, the platform shrugs.

Ember was built to be the next thing. Five differences define it:

  • Multi-target. One conversation can produce a marketing site, a Telegram bot that auto-replies to mentions, or an autonomous agent that runs around the clock. Each target has its own deploy pipeline and runtime - invisible to the user.

  • Hosted by Ember, end-to-end. The user never sees Docker, deployment configs, environment variables, or anywhere to upload to. They paste a prompt, and a real URL comes back. Iterate in chat, watch it hot-reload in the preview window. Click "publish" to ship a versioned production release.

  • Per-project containers, isolated by default. Every project runs in its own container with its own secrets, its own network surface, its own audit trail. Generated code can't see other projects' data - not by accident, not on purpose, not even theoretically. The isolation is structural, enforced by the platform, verified by red-team testing before each phase ships.

  • Agentic code generation. Complex requests do not go through a single-shot LLM call that hopes for the best. They run through a sandboxed agent loop where the LLM has read/write/lint/validate tools and operates as an autonomous coder: it inspects existing files, writes the change, checks its own work, fixes mistakes, and only finishes when the bundle passes validation. Hard turn caps and stuck-detection prevent runaways. This is the difference between an app that "looks right" and an app that actually compiles, lints, and runs - and it is what lets Ember handle real refactors, not just first drafts.

  • Asynchronous, background-first. Generation does not block the user. The pipeline runs as a true background process on Ember's compute platform - the user can close the tab, come back later, and find their app built, deployed, and serving traffic. Status events stream over a Realtime channel so the dashboard always reflects the current state, even mid-build. Long-running iterations (a complex refactor, a fresh-from-scratch generation) work the same way: kick it off, walk away, return to a finished project. The product feels like delegating to a coworker, not waiting on a tool.

The result is a platform that can credibly ship to non-technical users while staying secure enough for paying customers.

How a user gets from idea to live​

That loop - from "I want X" to "X is live" - runs fast. Subsequent iterations hot-reload because the iteration preview runs in a dedicated container that the platform keeps warm.

When the user is happy, one click promotes the iteration into a versioned production release. The new version goes live, the previous version steps down cleanly, the URL stays the same.

Architecture in one picture​

The platform has four planes. Each has one job; clean contracts between them are what makes the security model work.

Frontend is what the user sees. A modern web app with a chat box, a preview window, and a project list. Stateless from a secrets perspective - it holds nothing sensitive.

Ember Control Plane is the brain. Inside it sits the Ember Pipeline - a proprietary 9-stage CI/CD chain that takes a user prompt and turns it into a deployed, isolated, signed, audited application. Around the pipeline live the core platform services (Secret Vault, Audit Logger, Realtime Event Emitter, Cost Metering, Orphan Sweep, Idle Reaper) and the generation assets the pipeline relies on (Template Registry, Skills Library, Image Registry). Everything that matters happens here, behind one trust boundary.

Per-project workloads are isolated containers - one per project version, one per agent project, one per active iteration session. Generated code only ever runs here. Each container can see only its own data, its own secrets, its own network. The control plane talks to them via signed channels; they cannot talk to the control plane back.

Data is managed Postgres for everything user-facing (projects, versions, agent conversations, audit log), plus a frontier-tier LLM provider for code generation. Both scale independently of the rest.

The blue arrow from User to Containers is the only place a user's request reaches a generated app - proxied through the Ember Edge so we can route by project ID, but the actual response comes straight from their container.

The deep architecture - all nine pipeline stages, every core service, the full per-target deploy flow - is in the Architecture page. That's the technical case for why this is hard to replicate. This page is the one-line version: it is a complete, custom, end-to-end application platform we own from prompt to production.

What's special about the agent target​

The most strategically important thing Ember does is the agent target. A user describes a behaviour - "watch my Twitter mentions and draft replies", "answer customer questions on Telegram", "chase invoices once a week" - and Ember scaffolds an autonomous LLM agent. Persistent. Stateful. Plugged into Telegram, X, Discord, webhooks, or just a chat panel in the dashboard.

That on its own would be table stakes; OpenAI sells you something similar. The difference: the user brings their own LLM provider key. Their messages bill to their own Anthropic or OpenAI account, not ours. We charge for the platform - the hosting, the tooling, the integrations, the security - not for the conversation volume.

This decouples our cost from their usage. A user can have an agent loop fifty times a day responding to Telegram messages, and our cost per active agent is roughly the same as if they sat idle. That's why generic vibe-coding tools can't credibly ship chat agents: their unit economics break the moment the agent gets talkative. Ours doesn't.

The agent target is what positions Ember as the platform for building agents, not just one more no-code app builder. It's the strategic differentiator.

How the pricing model holds together​

Three pricing layers, each chosen to keep margins resilient as we grow:

What the user getsWhat's behind it
SubscriptionActive projects, iteration budget, custom domains, supportPlatform compute, code generation, edge routing, infrastructure
Per-project computeEach project gets its own container, automatically idle-suspendedBundled into the subscription; idle projects cost effectively nothing
Agent inference (BYO)Unlimited agent messages on the user's own LLM provider accountEmber earns nothing on conversation volume - the user pays their provider directly

The cost shape is the right one: fixed costs barely move as users grow, variable costs scale linearly with active iteration, and the most cost-sensitive workload (chat agents) is paid for by the user. Margin grows with scale.

Where the platform is heading​

  • Multi-platform agent integrations - the Telegram webhook pattern generalises to X, Discord, Slack and other platforms with no architectural changes
  • Scheduled triggers for agents - cron-style automation so agents can act without a user message in the loop
  • Vertical-specific opinionated templates - faster path to value for specific user segments
  • Enterprise tier - regional residency, formal SLAs, compliance certifications when customer demand justifies the operational lift
  • User-owned custom domains - paid-tier feature so customers ship under their own brand