Room to build at every layer.
A website platform with a Rust + Postgres core and a built-in agent runtime. People use React and React Native interfaces. Agents read published content as Markdown and operate through permissioned tools. Your extensions add the product-specific logic behind both.
System profile
- Deployment model: One site per deployment
- Extension backend: Rust → wasm32-wasip2
- Web / mobile: React / React Native
- Content & agents: Structured content · Markdown · MCP
In this overview
- Architecture
- Customization
- Extension contract
- Trust & data
- Stack decisions
- Agent browsing
- Agent operations
- Evaluate & ship
Several interfaces. One system of record. {#technology-architecture-title}
The public website, owner workspace, native app, and connected agents use the same site services. HTML and Markdown present published content to different readers. Authenticated tools reach the business operations behind it. The Rust backend owns persistence and authorization.
Runtime boundaries
React web / admin React Native Agent clients
Markdown / MCP
↓ requests / scoped tools
Rust host: authentication, authorization, services
└─ Wasm extension: routes / jobs → granted imports
↓ host-mediated access
Postgres + extension collections / configured providers
Conceptual architecture. Server-side Wasm isolation does not extend to browser or native UI code.
Host-owned services
Content, site configuration, provider connections, and access control stay in the platform. Customer identity and commerce are supplied by installed extensions such as Cedros Login and Cedros Pay.
Extension-owned behavior
Your package contributes routes, jobs, data models, page blocks, admin screens, and agent capabilities. A customer interface and an agent tool can call the same business service, with authorization enforced on the server.
Site-level isolation
A Cedros deployment serves one site. An extension that serves multiple organizations must model those organizations and enforce its own customer-level authorization.
Choose the layer that owns the change. {#technology-customization-title}
Appearance, page composition, and application behavior have different extension points. Keep a visual change in the theme; give new business logic an explicit runtime and data boundary.
Theme
Declarative tokens and manifests control typography, colors, spacing, and shared surfaces. Themes contain presentation, not executable business logic.
Page or shared template
Compose structured blocks and edit their content independently of the shared layout. Bespoke pages pair an interactive React interface with native components and an agent-readable Markdown representation. Keep the meaning and key links complete on every surface.
Extension
Ship reusable UI together with server routes, scheduled work, persistent models, and integrations. Add admin sections, dashboard cards, editor panels, or public blocks within the host's contracts.
Native contribution
Implement device-appropriate components in React Native. Mobile block renderers have their own registrations; screens, stacks, and providers use hosted App Builder releases or coordination with another native host.
One package. Explicit contributions. {#technology-extensions-title}
An extension is a versioned ZIP with one stable extensionId and one manifest. Its package family declares Rust server, React, and React Native members—even where a surface only needs a minimal bootstrap.
A typed server boundary
Rust compiles to a WebAssembly component targeting wasm32-wasip2. WIT defines the imported host services and exported routes and jobs. Pin the WIT version and checksum to the target host's authoring kit.
A packaged web runtime
Ship compiled ESM for the admin and public web contributions. The browser loader resolves React, its JSX runtimes, and cedros:admin; bundle other dependencies into the archive. Remote code imports are not supported.
Declarations meet execution
The host validates manifest and bootstrap agreement, requested access, and route/job bindings. A manifest entry alone does not implement a handler or make a native screen executable.
Install without a host rebuild
On a host with the Wasm extension runtime enabled, installing and enabling the component binds its supported routes and jobs without a server restart. Native package changes follow the mobile release process.
A route export, from the authoring kit
This declares GET /status for cedros-example-wasm. The host mounts it at /extensions/cedros-example-wasm/status.
fn list_routes() -> Vec<RouteSpec> {
vec![RouteSpec {
route_id: "cedros-example-wasm:status".to_string(),
method: "GET".to_string(),
path: "/status".to_string(),
}]
}
This excerpt comes from the published route-only Rust example. A complete extension needs the surrounding package. Its full implementation includes the request handler, response types, job exports, WIT bindings, and package manifest.
Archive structure (abbreviated)
cedros-extension.manifest.json
cedros-extension.bootstrap.json
cedros-extension.server.wasm
workspace/
react/dist/ # admin + web
react-native/ # native member
Include the complete manifests, package metadata, compiled contributions, and release evidence required by your surfaces.
The sandbox is a server boundary. {#technology-boundaries-title}
Wasm execution, browser code, and application authorization are separate concerns. A server capability grant controls what an extension may access; your handler still decides which user may perform the operation.
Wasm guest
The host gives each invocation a fresh instance, with memory and execution limits. No direct filesystem, sockets, environment variables, or raw Postgres connection. Persist durable state through host services, not guest globals.
Database access
Declare extension-owned content models and databaseAccess grants. The host provisions namespaced JSONB collections and checks model and operation scopes on each call. Use the published batch and compare-and-set contracts where you need atomic updates.
Providers & outbound HTTP
Provider calls use the site's configured services under declared access. Outbound HTTP has a separate operator-managed hostname allowlist, HTTPS requirements, SSRF protection, and request/response limits.
Browser & native code
Validated browser bundles run as same-origin ESM; they are not inside the Wasm sandbox. Treat them as trusted site code. Native contributions are packaged into an app release, not downloaded as sandboxed Wasm workloads.
Application authorization
Validate the caller, resource ownership, and business rules on server routes. A hidden admin panel, disabled button, or declared manifest permission is not a substitute for those checks.
Most privileged host interfaces are declared and granted at installation. Per-extension logging and secrets are always linked; outbound HTTP is governed by the operator allowlist. Read the runtime contract for the exact grant model.
Each technology has a specific job. {#technology-stack-title}
Each layer serves a different reader or workload: Rust owns durable services, Wasm runs extension logic, React and React Native provide human interfaces, and Markdown makes the published site easier for agents to browse.
Rust + Postgres
Rust brings memory safety without a garbage collector to the host services. Tokio and Axum handle asynchronous requests; SQLx connects those services to Postgres. Extension authors use typed host contracts instead of coupling their packages to core database tables.
WebAssembly + Wasmtime
Components give custom server logic a typed ABI and a bounded execution environment inside the host. This is an extension runtime, not a general container host: arbitrary daemons, native executables, and direct operating-system integrations are outside its supported contract.
React
Components serve the public web and admin. You can share interface conventions and React expertise while contributing distinct page blocks and operator workflows. Code must fit the relevant page or extension loader contract.
React Native
Mobile shares services and product concepts with the web. It has its own components, navigation, device integrations, testing, and signing. Reuse domain behavior without assuming DOM components render unchanged on a phone.
Markdown for agents
Markdown gives agents a direct text representation of the site: headings, explanations, links, tables, and code without the surrounding interface markup. Published pages, docs, and blog content have .md routes. Structured documents retain the visual layout; custom pages supply meaningful Markdown alongside their interactive code.
A site agents can read and navigate. {#technology-agent-browsing-title}
An agent researching a business needs to find the right page, understand its content, and follow the next useful link. Cedros serves explicit text and discovery interfaces for that job. Public research does not require an MCP connection or an owner account.
Readable page endpoints
A request to /technology.md returns this page as text/markdown. Pages, docs, and blog alternates resolve through the same published-content API used for HTML. Agents can read them without executing the web interface; authors preserve explanations, tables, code, and useful links in the Markdown channel.
A navigable content index
/sitemap.md is built from published site content and links to agent discovery resources. Documentation and blog indexes also have Markdown representations. An agent can move from an index to a relevant page without reconstructing the navigation from rendered menus.
Discovery before execution
/llms.txt introduces the site-operation surface and links to further guidance. /.well-known/ai-discovery.json maps the discovery endpoints; /skill.json describes published skills and extension capabilities. These documents let a client find the relevant contract before attempting an operation.
Capabilities that describe themselves
Installed extensions can publish skills and executable capability metadata into the site’s discovery surfaces. Skills explain the workflow; capability schemas describe accepted inputs and the host execution path. A published description does not itself grant permission to run the action.
Authoring context for coding agents
Page, theme, and extension skills route a coding agent to the appropriate contract. The version-matched extension kit includes schemas, WIT definitions, runnable examples, validation scripts, and checksums. An agent can build against the target host’s supported interfaces instead of inferring APIs from a screenshot.
Reading, discovery, and execution are separate interfaces. Markdown explains content; it does not execute an interactive page or authorize a transaction. Public discovery remains available when a site is gated, while protected content and operations keep their access controls.
Tools, context, and work that persists. {#technology-agents-title}
The built-in assistant and external MCP clients work against the site’s actual records and services. Cedros supplies more than a tool endpoint: it provides focused discovery, operating instructions, scoped context, durable work, and explicit release boundaries.
Load the relevant contract
MCP resources organize operations by area and section. A client can load a compact overview, then the exact schemas for the job. Page guides follow the same section-to-page pattern. This keeps unrelated documentation out of the working context; clients may still load the broader permission-filtered tools/list.
Operate the existing services
Content, CRM, communications, analytics, tasks, settings, and extension tools use the same service and validation paths as their admin surfaces. Results identify the target and resulting state, giving an agent evidence it can inspect after a write. There is no separate agent-owned copy of the business data.
Scope the connection
Personal MCP keys carry the issuer’s permissions at creation; tool restrictions can narrow the connection further. Task tokens are bound to a task and cannot become general site-admin credentials. Read, draft, and publish modes distinguish inspecting a record, preparing a change, and committing a consequential action.
Retain business context
The built-in assistant’s Brain stores facts, source references, current summaries, and correction history. Recall is bounded by a context budget and site/user scope. Personal memory stays separate from shared team context, so continuing work can use relevant retained knowledge without exposing it to public browsing agents.
Make custom behavior discoverable
An extension can pair its web or admin interface with a schema-defined agent capability backed by its server logic. The host validates capability inputs and permission claims; the handler enforces resource ownership and business rules. Extension activity can also write capability-scoped records into the shared site-brain history.
Continue work beyond a chat turn
Tasks retain plans, subtasks, owner input, status, and completed output. Routines add owner-approved schedules, manual runs, and execution history. Humans, the site assistant, and authorized external agents can coordinate through durable records rather than relying on a single conversation to hold the work.
Review the revision that will ship
Page Builder exposes draft saves, document validation, signed previews, release readiness, revision history, and publication as distinct operations. Tools declare their required write mode and any exact confirmation. An agent can prepare a change for review, then publish an authorized, reviewed revision and verify the live state.
For example, an authorized agent can read a page and its current revision, save an updated draft, validate the document, generate a preview, inspect release readiness, and publish that reviewed revision. It then checks the published result. A queued job, saved draft, or tool invocation is a different outcome from a live change.
Extension activity & site-brain records
Prove the integration on the target host. {#technology-delivery-title}
Start with the smallest useful vertical slice: one interface, one route, and one persisted record. Validate the runtime and permission assumptions before building the rest of the product.
01 / Resolve compatibility
Check the target site's Wasm capabilities and current authoring kit. Pin platform, manifest, WIT, and package-family compatibility. Hosted App Builder and other native hosts have different integration responsibilities.
02 / Validate the artifact
Verify manifest/bootstrap agreement, compiled contributions, requested grants, and archive contents. Keep stable extension and contribution IDs across releases. The versioned ZIP is the installable deliverable.
03 / Exercise failure paths
Test a valid request, an unauthorized caller, a denied grant, unavailable providers, and invalid input. An installed package is not evidence that every included surface works in production.
04 / Plan lifecycle & operations
Test enable, disable, upgrade, and rollback behavior with existing data. Disabling unbinds server routes and jobs; updates preserve settings and enabled state. Plan data migrations, retention, backups, and recovery explicitly.
Bring a real integration question.
Bring your data model, runtime requirements, and agent workflow. Read the published contracts, inspect the live discovery interfaces, or talk through the architecture with us.