# Fractera — full knowledge base

> Open Code (source-available), AI-native self-hosting platform. Deploy a complete AI coding
> workspace — 5 AI engines, an autonomous Hermes orchestrator, and private graph
> memory (LightRAG) — onto your own Ubuntu VPS in about 10 minutes. This file is
> the complete /mcp-info knowledge base plus the full /ai-workspace-architect and
> /ai-development-loop references (with their canonical diagrams) in one document:
> architecture, Zero-Ops deployment, customization, pricing, the full FAQ,
> real-world use cases, the workspace architecture, the development loop, the
> Next.js Aircraft Carrier (the pre-built 50,000-line parallel-routing framework),
> the token economics of the MCP-First / Zero-Agent paradigm, the interactive
> AI consultant, the authentication scheme (roles & providers), and the legal text.
> The same content is queryable section-by-section via the MCP connector at
> https://www.fractera.ai/api/mcp (get_project_info,
> get_ai_workspace_architect_info, get_ai_development_loop_info).

## What is Fractera

Fractera is a source-available (Open Code) platform that turns a bare Ubuntu VPS into a complete, self-hosted, AI-native development environment in about 10 minutes — with one click or a short chat.

On your own server you get: five AI coding platforms (Claude Code, Codex, Gemini CLI, Qwen Code, Kimi Code), the **Hermes** orchestrator, **LightRAG** persistent memory, authentication, a database, and file storage — all pre-wired. No Clerk, no Supabase, no Vercel. One bill (your VPS), one place, full ownership of code and data.

You can install the full stack, or pick only the components you need — down to a plain server with a database and sign-in and no AI at all.

---

## How deployment works

1. You provide a server (IP + root password) — or buy a VPS first (see "VPS & pricing").
2. You choose what to install — the full stack or only the components you need.
3. Fractera's automated setup service configures everything on your server for you: it installs the tools you selected and sets up the database, authentication, file storage, and web routing, then brings all services online. You never run any commands yourself.
4. In ~8–14 minutes the workspace is live. You get email notifications when setup starts and when it finishes.

The result is **IP-first**: when it finishes, your workspace is live on plain HTTP at `http://<your-IP>:3002` — that is the Admin workspace where you start coding. Attaching your own domain with HTTPS is an optional later step you do yourself, inside the workspace (Admin → Personal Domain).

Three ways to start: the one-click form on the website, a partner/embed widget, or by chatting with an AI agent through the Fractera MCP connector.

---

## Zero-Ops deployment — from a bare VPS to a full stack in ~10 minutes

Traditional self-hosting is plagued by DevOps friction — hours spent configuring an Nginx reverse proxy, wrestling with Let's Encrypt SSL renewals, securing the database, and wiring up authentication gates. Fractera removes that barrier.

You provide nothing more than your bare Ubuntu server credentials, and an automated orchestration layer configures the entire infrastructure from scratch — with no terminal commands on your end.

Better still, you don't even need to open a browser: you can trigger the whole deployment — and check its status on demand — programmatically through our custom MCP (Model Context Protocol) connector, right inside your AI coding environment. It's the simplicity of Vercel, brought natively to your own private hardware.

---

## Components you can choose

You decide what gets installed (a lighter, cheaper server). Selectable components:

- **Claude Code** — Anthropic coding agent
- **Codex** — OpenAI Codex CLI
- **Gemini CLI** — Google coding agent
- **Qwen Code** — Alibaba Qwen coding agent
- **Kimi Code** — Moonshot Kimi coding agent
- **Memory** — LightRAG vector knowledge base
- **Brain** — Hermes orchestration agent

Always installed (the core, never optional): the web app, authentication, database, object/file storage, the admin panel, and the admin panel's own **system terminal**. Unchecking every box above gives you a plain server with a database and sign-in — no AI.

You are never locked in: any recommended or custom tool can be installed later from the terminal built into your admin panel.

---

## The five AI coding platforms

Claude Code, Codex, Gemini CLI, Qwen Code, and Kimi Code — all preconfigured on your server, each driven through a WebSocket bridge.

Key principle: they run on your existing **subscriptions**, not pay-per-token API keys. Sign in to each platform once (standard browser-based login, like a local CLI). No API keys to manage, no per-token billing surprises. You can switch platforms mid-task without losing your project context — LightRAG keeps the thread.

"Bridge online" means the process is alive and the WebSocket handshake works; logging into each platform's subscription is a separate one-time step after that.

---

## Subscriptions vs. API keys — what you actually pay

Two separate billing models — do not conflate them:

- **The five coding platforms (Claude Code, Codex, Gemini CLI, Qwen Code, Kimi Code) run on YOUR existing subscriptions.** You sign in once with your normal account (standard browser login, like a local CLI) — no API keys, no per-token billing. This is where the heavy AI work happens, and it costs you nothing beyond the subscription you already pay the AI vendor.
- **Brain (Hermes) and Memory (LightRAG) use one small OpenAI API key** — the cheap gpt-5-mini (about 1 cent per hour) is plenty to start, or a Codex subscription if your usage is heavy. This is the only per-token piece, and it is tiny and auxiliary.

So: **a Claude Code user pays through their Claude subscription, not per token.** Per-token API spend, if any, is limited to the small Brain/Memory model — not the coding platforms.

**Track Brain and Memory spend separately (optional).** Brain and Memory keep their OpenAI keys in two independent places, so you can meter each one on its own. Create **two separate API keys** in OpenAI and paste one into the Memory key field and the other into the Brain key field (in the OpenAI settings). One key works fine for both — but two keys let you watch each line item independently in the Usage dashboard at platform.openai.com.

---

## Memory (LightRAG)

Memory is a persistent vector knowledge base (LightRAG by HKUDS) shared across all your coding platforms. Feed it your codebase, documents, and architectural decisions; the agents query it to stay grounded in your context.

Why it matters: without persistent memory, every AI session starts from scratch — tokens spent re-explaining "where is the navbar?" are tokens not spent on your feature. Memory compounds with every iteration, so tasks that take 10–20 back-and-forth messages in a vanilla chat often resolve in 2–3. It does not auto-learn — it stores only what agents explicitly push. Activating it needs an OpenAI API key (used economically — the embedding model is among the cheapest), set in Admin → Memory settings.

---

## Brain (Hermes orchestrator)

Brain is the Hermes Agent (by Nous Research) deployed and configured on your VPS — the thinking centre of the workspace. It coordinates the connected AI subscriptions through shared context and can run autonomous, multi-step pipelines where each loop refines the next ("let Claude do this and Codex do that" — in parallel).

You talk to Brain through its **built-in web chat**, which opens automatically in the admin panel and is the primary way you use the system — just add a model to start. Talking to Brain from your phone via a Telegram bot is an optional secondary channel. (See "Hermes Web Chat — the main way you talk to Brain".)

---

## How authentication blankets the whole layer

Authentication is not a single login screen bolted on — it is a layer-wide gate. A dedicated Auth service is the **only** component that issues the session, and every other service and page checks that session before serving anything.

- **One session authority.** The Auth service (NextAuth) is the sole writer of the session cookie. Providers: email + password (bcrypt) and Google OAuth / magic link. Client code never calls the auth service directly — pages ask a single `/api/me` endpoint, which resolves the current session.
- **Per-service gate.** The user-facing app and the admin workspace each run a request gate ("proxy") that runs BEFORE any page or API handler: no valid session → redirect or 401. So hitting any of these services without a session gets you nothing.
- **Gate for the non-web services too.** The database/storage service, Memory, and Brain don't serve web pages, so in secure mode the web server (Nginx) enforces an auth check (`auth_request`) on each of their subdomains — every authenticated host requires a valid session, closing any side door.
- **Roles.** Each user has roles (default `user`). `user` can use the app; `admin` has full access to the admin workspace and the coding platforms. The **first person to register on a fresh server becomes the admin**; admins can promote others.
- **Modes.** In open/IP onboarding mode the gates are intentionally relaxed for friction-free first access; once you attach a domain (secure mode) the cookie becomes `Secure`, scoped to your domain, and every gate strictly enforces.

---

## How the database and object storage live in the layer

Both the database and the file/object storage run on your own server as part of the layer — there is no external Supabase, no S3 bill.

- **Database.** A single SQLite database file (`app.db`) holds the application data. The schema is defined in ONE place and applied automatically at startup, so the local and remote paths always agree — there are no migration files to juggle and no "run migration" button. A dedicated data service owns the database and exposes it over an authenticated HTTP API; the app talks to it through that service.
- **Object / file storage.** The same data service stores media and files on the server's local disk and handles image work (icon generation, thumbnails, crops). Uploaded media is served back through the app, never from a third-party bucket.
- **Ownership.** Because both live on your VPS, your records and files never leave your server. Back them up (export) and restore (import) whenever you like; pausing the project never deletes your data.

---

## How Brain (Hermes) drives the coding agents via MCP

Each of the five coding platforms runs on your server behind its own WebSocket bridge — a live process you can drive interactively. Brain (Hermes) sits above them as the orchestrator.

- **Delegation over MCP.** Brain reaches each coding agent through a per-platform MCP delegation tool (each platform gets its own MCP endpoint on its own port). Through these tools Brain can hand a task to Claude Code, Codex, Gemini CLI, Qwen, or Kimi — individually or several at once.
- **Parallel, multi-step work.** Because delegation is tool-based, Brain can run autonomous pipelines: split a job ("let Claude do this part and Codex do that part"), run them in parallel, collect results, and decide the next step — each loop refining the next.
- **Shared context.** The agents are not isolated silos: they share project context (and Memory, below), so switching an in-flight task from one agent to another does not lose the thread.
- **You talk to Brain, Brain talks to the agents.** There is no separate chat UI for each agent in normal use — you direct Brain through its built-in web chat in the admin panel (or, optionally, a Telegram bot) and Brain coordinates the rest.

---

## The Product Loop — a deployments table that goes beyond Vercel

Inside the admin panel there is a **Deployments** table that logs every development deployment — the running journal of *how your project gets built*. It deliberately mirrors the familiar Vercel deployments list, then adds the columns a generic cloud host cannot have.

A standard cloud platform shows you *that* a deploy happened: commit, status, branch, duration. Fractera shows you the whole story of the change:

- **Result** — a 1–3 star quality rating (first column). Hermes records each row with a default of three stars; you can change the rating at any time by clicking the stars and saving — your honest feedback on how good the work was.
- **Platform** — which AI coding agent actually did the work (Claude Code, Codex, Gemini, Qwen, Kimi).
- **Model** — the exact model used.
- **Tokens** — the real token cost of producing the change, captured straight from the agent's run (not estimated).
- **Page** — the URL where you review the change (last column), alongside a **Created** timestamp and the familiar commit / status / duration / branch / author cells. Every column sorts, and you can split deployments by **project** (a projects list you manage) and filter the table by one or more of them.

**Why this is the loop.** Hermes takes a decision, delegates the coding to one or more agents, deploys, then records the result and hands you the page link to review. You rate it. Over time the table becomes a feedback record of agent-driven development — which agent and model produce the best results for your project, at what token cost — something a deploy log alone can never tell you. It is the visible heart of Fractera's "product loop": build, deploy, review, rate, improve. See the whole agent-driven cycle visualized in the [Fractera development loop](/ai-development-loop).

---

## How Memory accumulates knowledge and how Brain & agents use it

Memory (LightRAG) is the shared accumulator of the whole layer — one vector knowledge base that every agent reads from and writes to, so context compounds instead of resetting each session.

- **Shared accumulator.** There is a single Memory for the server. Whatever any agent stores there — your codebase, documents, architectural decisions, solved problems — becomes available to every other agent. Knowledge accrues over time rather than living in one chat's history.
- **How information gets in.** Memory does **not** auto-learn. Agents (and you) push content into it explicitly through an ingest endpoint; each write is tagged with the identity of the agent that made it. This keeps the store curated, not noisy.
- **How Brain and each agent use it.** When working a task, Brain and the coding agents **query** Memory to ground their answer in your accumulated context before acting — so an agent starts a session already knowing your project instead of asking "where is the navbar?". Brain in particular leans on Memory to coordinate: it pulls shared context, then delegates with that context in hand.
- **Practical effect.** Tasks that take 10–20 back-and-forth messages in a vanilla chat often resolve in 2–3, because the model arrives already grounded. Activating Memory requires an OpenAI API key (used economically — the embedding model is among the cheapest), set in the admin panel.

---

## Two modes: IP (open) and Secure (your domain + HTTPS)

**IP / insecure mode** (the default right after deploy): the workspace is reachable at `http://<IP>:port` over plain HTTP, with open onboarding. This gets you into your workspace in seconds, with no DNS or certificate wait. Your browser will show a "Not secure" warning — that is normal until you attach a domain.

**Secure mode** (after you attach your own domain): everything runs on `https://<your-domain>` with a free Let's Encrypt certificate (auto-renewed), strict role-based sign-in, and a host firewall that closes all service ports except 80/443. For regions or compliance rules where Let's Encrypt is unavailable, you can upload your own certificate.

You switch from IP to Secure yourself, inside the workspace (Admin → Personal Domain), whenever you want — and you can switch back.

---

## Connecting your domain: the IP → Secure transition in detail

A fresh deploy is IP/insecure by default. Moving to secure mode is a guided wizard in Admin → Personal Domain, run entirely from your own server:

1. **DNS.** Point your domain's A-records — the apex plus the service subdomains (www, auth, admin, data, hermes, lightrag, and **chat** for the built-in web chat) — at the server IP. The wizard verifies they resolve.
2. **Certificate.** The admin app runs certbot on the server to issue a single Let's Encrypt certificate covering all those hostnames. Alternatively you **upload your own certificate** — a first-class path for regions where Let's Encrypt is unavailable or where compliance requires specific (e.g. national / GOST) certs.
3. **Activate.** The workspace switches every service into secure mode at once: the mode flag flips in all services, the session cookie becomes `Secure` and scoped to your domain, Nginx is rewritten for HTTPS, and a host firewall closes every inbound port except 80/443. A safety watch probes the new domain and auto-rolls-back to the previous settings if it doesn't come up — so a mistake degrades gracefully instead of bricking the server.

**How the coding-platform bridges connect.** In IP mode the browser talks to each platform's bridge directly over `ws://<host>:<port>`. In secure mode they move to path-based **wss** under the cert-covered admin host — `wss://admin.<domain>/ws/...` — so the interactive terminals keep working over TLS with no mixed-content blocking.

**Reading the Step 3 health-check (200 / 307 / 404 are all fine).** The final check marks a host **healthy** when three things hold: DNS resolves to your server, the TLS certificate is valid (strict verification passes), and the service answers with any normal code in the 200–499 range (not a timeout, not a 5xx). The exact code is just informational — it tells you what the service returns at its root `/`:
- **200** — the service serves a page at `/` (apex, www, admin, hermes, **chat**).
- **307** — the service redirects at `/` (auth → the sign-in form; lightrag → its own UI). A normal redirect.
- **404** — the service has no page at `/` (data — a media/DB API that legitimately serves nothing at the root).
Only a real failure blocks the switch: DNS not resolving, an invalid certificate, a timeout, or a 5xx. If none of those occur, all hosts are green even with a mix of 200/307/404.

**Reversible.** A "switch back to IP / demo mode" option restores the previous configuration and reopens the service ports. Certificates auto-renew (~every 60 days); if a certificate nears expiry an early warning email is sent.

---

## Data ownership & cloud exit

Everything your application needs — authentication, database, file storage, AI memory — lives on a server you own. No third party has access to your data. No dependency on someone else's uptime, pricing changes, or terms.

This is the cloud-exit promise: no Clerk subscription, no Supabase invoice, no Vercel bill that scales with traffic; one server, one bill. If you pause your business, your data does not disappear — back it up and restore when ready. Your application code lives on GitHub, so recovery is always possible, and the built-in AI assistants can help rebuild even when dependencies have aged. It also helps you meet regulatory or internal-policy requirements and avoid surprise bills.

---

## The admin panel (Bridges) and its default functions

The admin workspace — also called Bridges — is the control panel that runs on your server. It is where you actually drive everything, and it requires the admin role (the first person to register on a fresh server). By default it gives you:

- **A carousel of your installed coding platforms.** Click one to open its live interactive terminal; an always-present **system terminal** is the last card (see "The system terminal").
- **Brain and Memory canvases** (if those components are installed) — open the Hermes and LightRAG interfaces inline.
- **Settings menu:** Users (accounts and roles), Upload media, Database browser (view and edit tables directly), Environment variables, Personal Domain (the IP → secure wizard), Hermes / Memory settings (API keys), Export / Import data (a backup ZIP of database + storage), and Help.
- **Footer actions:** Deploy (rebuild the open app layer after changes), GitHub connect with one-click Pull / Push, Info (README), links to Skills and Product Loop, and the current build version.

Everything an agent or you build lives behind this panel, and every part of it is gated by authentication (see "How authentication blankets the whole layer").

---

## The system terminal

The admin panel includes a system terminal — a plain project-level shell on the server, always present as the last card in the carousel. Unlike the AI platforms it can never be disabled, because it is part of the core.

Use it to install extra tooling, run one-off commands, link your Telegram bot to Brain, install your own copy of a coding agent, or anything else the server level needs. It opens at the project root where the services live.

---

## VPS, specs & pricing

Fractera is free. There are **no plans and no tiers** — the platform is always free to use. The only money involved is the VPS you run it on (paid to your hosting provider, never to Fractera) and **optional, voluntary sponsorship** ($1 / $5 / $20 — see "Sponsorship & Fractera Pro").

For full AI-coding workloads the recommended minimum is **4–6 cores and 6–8 GB RAM**; storage depends on your project (75 GB is a solid baseline). Once active AI development wraps up, you can downgrade to ~2 cores / 4 GB RAM — often just a couple of euros per month. A plain server with no AI needs even less.

You bring your own VPS from any provider.

---

## Who it is for & use cases

- **Vibe-coders and solo founders** who want a production stack (auth, DB, storage, AI) without wiring ten cloud services together.
- **Experienced developers** who want to offload cloud-resource management and DevOps — deploy a plain server, sync it with a local IDE (e.g. VS Code) over GitHub, and treat their own VPS as a self-hosted alternative to Vercel.
- **Teams needing data sovereignty** — keep user data, auth, and database on infrastructure they control, to meet regulatory or internal-policy requirements.
- **Builders bringing an existing project** — connect a GitHub repo and continue AI-assisted development on the server.
- **People who want autonomous AI workflows** — let Hermes coordinate multiple agents on multi-step tasks.

The same server can be used purely as a self-hosted backend (database + object storage + optional auth) with no AI at all.

---

## Real-world use cases — what founders & teams actually build

Fractera is not just a theoretical framework — it is a deployment engine for practical, custom automation. Because the architecture enforces a strict split between the public-facing application (open layer) and the authenticated admin panel (guarded layer), builders use it to solve asymmetric operational problems with minimal token spend. Here is what real users have already built and deployed on Fractera.

**1. The Collaborative Content Engine (private internal workspace)**

- **The problem:** a high-traffic blogger needed a unified workspace where a distributed team of editors could collaborate on content planning, draft preparation, and asset management — without exposing the system to the public.
- **The Fractera solution:** deployed entirely in secure, authenticated mode. The team uses the built-in SQLite database and file storage to manage the publishing pipeline. Editors work in an isolated environment, using Fractera's cross-platform AI routing to brainstorm structures and refine texts collaboratively — turning a standard VPS into a private corporate command center.

**2. The Local Service Dispatcher & Smart Kanban (automated lead routing)**

- **The problem:** a custom-furniture salon manager needed to automate dispatching for kitchen and wardrobe measurement requests — ingesting incoming emails from the marketing site and dynamically routing them to field engineers by geographic proximity to cut city-travel costs.
- **The Fractera solution:** a background service fetches inbound emails via API and turns them into structured data. Fractera's local database acts as the state machine, rendering a secure, internal-only Kanban board. It stores field-tech availability and locations, letting authenticated staff orchestrate logistics privately — without a single byte of customer data leaking to third-party cloud platforms.

**3. Adaptive AI Tutor (hybrid public/private EdTech)**

- **The problem:** a parent wanted a hyper-personalized programming course for her child that adapts daily based on real performance, controlled securely via mobile commands.
- **The Fractera solution:** a hybrid public/private structure. The child uses an unauthenticated, lightweight public page to complete interactive daily coding challenges; results are piped securely to the backend database. The parent uses a private dashboard and a dedicated Telegram bot connected to the Hermes orchestrator. Based on the child's performance metrics, the parent issues a voice command, prompting the AI to instantly restructure the next day's lesson database.

**4. Viral Trend Scraper & Autonomous Blog Loop (public passive-traffic generator)**

- **The problem:** a content creator wanted to monitor trending topics across competitive Telegram channels, enrich those signals with live web data, and autonomously publish optimized long-form articles to a public blog and external resources to capture maximum traffic.
- **The Fractera solution:** the server acts as an autonomous data agent. A scheduled script monitors specified Telegram channels, feeds hot topics to the Hermes orchestrator, expands them with real-time search (e.g. the Exa API), and publishes the enriched posts via external APIs. The public site runs as a static, blazing-fast SEO blog with no user registration. Meanwhile traffic metrics are piped back to the creator's Telegram bot, so they can track performance and iteratively optimize publishing schedules.

**5. Dynamic School Timetable (collaborative scheduling)**

- **The problem:** building a school timetable is notoriously hard and never static. The standard schedule constantly needs exceptions — one teacher requests a day off, another is out sick, someone has to take overtime or cover substitute classes, someone comes in on a day off for school-wide events. Reconciling everyone's constraints by hand is painful.
- **The Fractera solution:** the school started by using the agent to generate surveys, sending links through their existing chat to private pages where each teacher's availability and preferences are collected. The agent forms a baseline timetable; each teacher has a private page to request changes; the system reads every teacher's input and the schedule dynamically re-builds until it is approved in a way that suits the maximum number of teachers. When something unplanned happens — a teacher falls ill — the model can even suggest which teachers would be the best fit to offer the substitute lessons to.

---

## Partner program (affiliates for bloggers)

Fractera's partners are bloggers and YouTube creators who recommend Fractera to their audience. Instead of a plain referral link — which would send their readers to the general landing page (aimed at a different audience) and leak traffic — each partner gets two conversion-focused surfaces:

- **Partner page** — a personal mirror of the Fractera landing at `https://www.fractera.ai/partner/<lang>/<slug>`, trimmed to just the order section (enter server details, pick a provider). It also satisfies what hosting providers require for affiliate approval: a real URL where the affiliate link lives.
- **Widget** — an `<iframe>` the partner embeds on their own site or blog; it renders the same single order section, so the creator can write about any topic and offer server signup right inside their own page.

Partners connect their own affiliate links in two categories that match the two deploy phases: a **VPS provider** (the IP-first server phase) and a **domain registrar** (the later secure custom-domain phase). Only providers on Fractera's trusted whitelist appear automatically — this protects readers from links to fake resources. To get a new provider added to the whitelist (for servers or for domains), a partner contacts the Fractera team for review.

Becoming a partner is one click (auto-approved) from the Partners page; the cabinet then lets the partner manage their server/domain affiliate links, fill in the page footer details, and copy the widget snippet.

---

## Browser-first development & voice commands

Production AI development happens entirely in your browser, from the first second — no VS Code, no local environment to configure, no database to spin up, no deployment pipeline to debug. You open a tab and the server is already live, the domain registered, the database running, and the coding platforms wait for your first command.

- **Voice commands.** Issue coding commands and navigate content hands-free via microphone; agents respond to natural voice input in real time.
- **Instant production.** One click deploys your changes live — no CI pipeline, no hosting config.
- **Any device.** All computation runs on the VPS, so a laptop, tablet, or phone is enough.

This is what lets anyone with an idea — not only engineers — build, ship, and scale a real product without leaving the browser.

---

## What Fractera can and cannot do (ownership & trust)

This is your software on your servers. Fractera helps install it — and nothing more.

- **Change your password after install.** Immediately after installation completes, change the password for access to your server.
- **No access, no control.** Fractera does not gain control over your code, and we have no access to your servers. There is no backdoor — the deployed product cannot push to our repositories (verified by a security audit).
- **Always recoverable, always portable.** Your code lives on GitHub and your data on your VPS; you can inspect it, back it up, export it, or walk away at any time. Nothing locks you in.

---

## MCP connector — security, data & trust (FAQ)

Direct answers to the questions technical reviewers and security teams ask most about the Fractera MCP connector.

**Does Fractera store my server's root password?**

No. The root password is used only transiently, inside the single deployment SSH session, to install the workspace — it is never written to our database. A placeholder is stored in its place, and the dashboard shows a "password is never stored" indicator. For `retry_deploy` you simply provide the password again. We strongly recommend changing the server password immediately after installation.

---

**Can Fractera access or control my server after deployment?**

No. Because we do not retain the password — and we recommend rotating it after install — Fractera holds no standing administrative access to the servers it deploys. There is no backdoor: a deployed workspace cannot push to Fractera's own repositories (verified by a security audit). You can have your own AI agent audit every installed file against the public source at https://github.com/Fractera/Agent-Engineering-Infrastructure, before and after deployment.

---

**What data does the connector collect and keep?**

Only what is needed to deliver the service: your **email** (to send install / completion / recovery notifications) and your **server IP** (to provide follow-up value such as TLS-certificate-expiry reminders and health notices), plus your component selection. The root password is NOT kept (see above). Your application data — database records, files, user accounts — never leaves your own server.

---

**Does the connector require authentication?**

No. It is an open connector — no API key, OAuth, or account is required to connect. Authorization for the destructive action is implicit: a deploy only ever touches the specific server whose IP and credentials the user explicitly provides in that conversation.

---

**What does each tool do, and which are destructive?**

- `register_and_deploy` — **destructive**: wipes and installs the workspace on the server you provide.
- `retry_deploy` — **destructive**: re-wipes and reinstalls on the same server after a failed attempt.
- `check_status` — read-only: returns deployment progress.
- `get_subdomain` — read-only: returns the finished workspace address.
- `get_vps_recommendation` — read-only: suggests a VPS provider.
- `get_project_info` — read-only: answers questions about the project.

All tools carry the proper `readOnlyHint` / `destructiveHint` annotations. The read-only tools are completely safe to test without any server.

---

**Does it enable cross-service automation, or move money?**

No to both. The connector does not chain or relay between third-party services — it acts only on a single target: the user's own VPS. It never transfers money, cryptocurrency, or executes financial transactions; the deployment itself is always free.

---

**Is the connection encrypted?**

Yes. The connector is served over HTTPS/TLS using the streamable-http transport, with CORS configured for clean client handshakes. The SSH session to your server during deployment is likewise encrypted.

---

## Included features (and what Pro adds)

Included for everyone:
- Hermes AI agents with self-learning memory
- Voice AI commands
- Built-in auth: Google OAuth, magic-link email, credentials, role management
- Database (SQLite, WAL mode) + object/file storage + media service
- One-click backups & restore (snapshot and re-upload to restore or clone)
- GitHub sync — push, pull, and deploy from the admin panel in one click
- All five coding platforms preconfigured; LightRAG memory initialized on first start
- Skills marketplace access

Advanced — Fractera Pro ($20 sponsors): production SEO, PWA and multi-language routing; element highlighting (click any UI element to capture its exact id — fewer tokens); up to 11 parallel routing slots with static SEO; ready-made page sections that cut token spend many times over. See "Fractera Pro".

---

## Why now — the opportunity

In early 2026 the largest untapped AI value was described as sitting inside businesses that have neither a website nor an API — the work currently handed to outsourcers (customer service, operations) that AI could do directly, framed as close to a trillion-dollar opportunity.

Fractera is built to let a single founder or a small team reach that opportunity: stand up real, owned software infrastructure fast, then let AI do both the building and the operating. The point is not "another dev tool" — it is letting anyone with an idea ship and run a real product, owning the whole stack.

---

## AI Company Brain (B2B appliance) — distinct from on-VPS Memory/Brain

Separate from the on-VPS "Memory" and "Brain" described above, Fractera offers a B2B **AI Company Brain**: a physical Apple Silicon appliance (Mac mini or Mac Studio) placed in your office and personally configured by the Fractera founder.

It combines a private LightRAG knowledge graph — ingesting meetings, documents, voice memos, emails and chat history into structured corporate memory — with a Hermes agent that acts on it and returns finished work as clean links (a document, a deck, a site), briefed by voice from Telegram. It runs 24/7 on your desk (~30W) and nothing leaves the building. Pricing is by agreement (each engagement scoped to the business); capacity is strictly limited. First step is a founder consultation — admin@fractera.ai.

---

## Sovereignty & import substitution (Russia)

Country-specific note for Russia. The public side of your project is 100% under Russian jurisdiction: server, user data, domain and certificate stay in the Russian Federation.

- **User data in Russia (152-FZ).** Database, file storage and authentication run on your server in Russia; the infrastructure lets you meet the 152-FZ requirement to store citizens' personal data in-country.
- **Server in Russia.** Deploy with a Russian provider (e.g. Timeweb Cloud); the whole production perimeter stays under Russian jurisdiction, with no foreign clouds in the data path.
- **Domain & certificate by Russian law.** A .ru domain at a Russian registrar (e.g. reg.ru) and TLS are set up automatically; national / GOST certificates fit the sovereign-infrastructure logic (you can upload your own certificate).
- **Development is the developer's free choice.** You write code with any AI assistant and may work from abroad — that is the private side, outside the regulated personal-data perimeter. For those who want full sovereignty, Chinese models Qwen and Kimi are available without restrictions.

Responsibility boundary (honest): the infrastructure is sovereign; responsibility for processing specific personal data in production rests with the developer. Fractera "lets you comply", it is not a certification.

---

## Open Code & what runs where

The workspace that runs on your server is open and available as Open Code on GitHub — every layer of it: the web app, authentication, database/storage service, the coding-platform bridges, the memory (LightRAG) and orchestrator (Hermes) integrations. You own it and can inspect, extend, or self-host it entirely.

Provisioning, billing, and the automated setup/delivery are handled by an external Fractera service that we operate. It is what puts the Open Code workspace onto your server and manages your account — you interact with its results (the deploy, the dashboard, the emails), not its internals.

So: the product on your server = open. The service that delivers and bills it = operated by Fractera. Your code and data always stay on your server.

---

## Extending authentication — providers & roles

By default your server ships with a minimal auth setup. There is **no limit** on extending it: using the in-VPS AI agents you can ask to add new auth providers or new roles freely.

One strong recommendation: **do this while in insecure (IP) mode.** Insecure mode does not restrict access to the admin panel, so if a change accidentally breaks authentication you can still get back in and keep working. In **secure mode**, breaking auth can lock you out of the project entirely. So experiment with auth in insecure mode, confirm it works, and only then switch to secure mode.

---

## Add tools & change the project — it is encouraged

You can add tools yourself through the system terminal — OpenClaw, OpenCode, or any other tool. The AI model has enough patterns in the codebase to copy how an existing platform works and add a new window plus a carousel button for it — just ask it directly to do this.

More broadly, you may change the architecture, add skills, or optimize the project however you see fit. This is not only allowed — it is recommended. That is exactly why every part of the Agentic Engineering Infrastructure is fully Open Code (source-available).

---

## Removing the "Powered by Fractera" line

If you want to remove the "Powered by Fractera" line that appears on your public pages: you will most likely **not** find it in the application code, and trying to hunt it down may break your project — it is applied at the web-server layer, not in app code.

If its presence bothers you, the simplest safe trick is to overlay your own container on top of it to make it invisible. The recommended path, though: become a sponsor (the $5 tier removes it) and just ask — we'll tell you how to do it properly.

---

## Skills & Product Loop (roadmap)

Two future products (planned, not fully built yet):

- **Skills** — packaged, reusable AI workflows. Package the workflows you have solved, sell them, share them free, or buy battle-tested recipes from other builders.
- **Product Loop** — the digitized end-to-end entrepreneurial journey (company registration → traffic → unit economics → scaling) as conditional, branching decision logic another founder can buy. Not a step-by-step manual but a living knowledge base of the decisions that worked.

**Pricing is set by the users** who create the skills or digitize their business — Fractera does not set prices. The project acts only as the observer/host: it provides the server capacity these services run on and takes a **20% commission**.

---

## Partner program (affiliates for bloggers)

Fractera's partners are bloggers and YouTube creators who recommend Fractera to their audience. Instead of a plain referral link — which would send their readers to the general landing page (aimed at a different audience) and leak traffic — each partner gets two conversion-focused surfaces:

- **Partner page** — a personal mirror of the Fractera landing at `https://www.fractera.ai/partner/<lang>/<slug>`, trimmed to just the order section (enter server details, pick a provider). It also satisfies what hosting providers require for affiliate approval: a real URL where the affiliate link lives.
- **Widget** — an `<iframe>` the partner embeds on their own site or blog; it renders the same single order section, so the creator can write about any topic and offer server signup right inside their own page.

Partners connect their own affiliate links in two categories that match the two deploy phases: a **VPS provider** (the IP-first server phase) and a **domain registrar** (the later secure custom-domain phase). Only providers on Fractera's trusted whitelist appear automatically — this protects readers from links to fake resources. To get a new provider added to the whitelist (for servers or for domains), a partner contacts the Fractera team for review.

Becoming a partner is one click (auto-approved) from the Partners page; the cabinet then lets the partner manage their server/domain affiliate links, fill in the page footer details, and copy the widget snippet.

---

## Regional partners (official resellers)

Separate from the affiliate Partner Program, Fractera is looking for **regional partners** who represent Fractera in their region on equal terms — promoting the business and receiving and fulfilling orders to install Fractera and the AI Company Brain locally.

- **Business requirements:** a registered legal entity operating 3+ years; a significant audience of partners or subscribers; strong SEO and external-link skills; business-development skills.
- **What we offer:** a page for your region carrying your own VPS + domain referral links; referral rewards split **30 / 70 (partner keeps 70%)**; official Fractera reseller status in your region.
- **Partner responsibilities:** promote your regional page in search by driving traffic via your own publications, pages and mailings — the more visitors, the more referral reward from VPS and domain sales.
- **What a "region" is:** either a whole country (when it is effectively one state/region) or a state/region within a country — so one country can have several regional representatives.
- **How to apply:** email admin@fractera.ai with the subject "Regional representation application". Full page: /en/regional-partners (or /ru/regional-partners).

---

## Sponsorship & Fractera Pro

Fractera charges nothing — support is **entirely voluntary**. There are exactly three sponsorship amounts: **$1, $5, or $20 per month**. No other amounts are ever charged, and there are no hidden plans.

Each tier unlocks perks:
- **$1** — access to the private sponsor community (architecture details, debugging help, faster fixes).
- **$5** — also removes the "Powered by Fractera" branding from your site.
- **$20 — Fractera Pro:** the full, densest set of advanced pre-built capabilities (see "Fractera Pro"), plus direct access to the founder.

Even $1/month makes a real difference and unlocks the private channel.

---

## Fractera Pro

Fractera Pro is an advanced architecture built on deep, hard-won Next.js 16 expertise — it unlocks the full power of the framework.

Advanced capabilities like **parallel routing, search-engine optimization, and static generation** — with a focus on doing the work with **minimal calls to the server** — are exactly the things AI tools most often get wrong or wire up with serious mistakes. The reason is simple: there are almost no correct examples of these patterns on the internet, so a model has nothing reliable to imitate. The right configuration is found only through an enormous amount of testing to discover the patterns that actually work.

Pro gives you the **densest possible saturation** of these advanced features — and you **don't spend tokens** building them. They arrive as **pre-configured page templates and tools**, ready to use. Fractera Pro is available to **$20 sponsors**.

---

## System anatomy — the services on your server

On your VPS the product runs as seven cooperating services (kept alive by a process manager) behind one web server (Nginx):

- **Shell app** — the main user-facing application and iframe host; this is the open layer where your product is built.
- **Auth** — the only service that issues the login session.
- **Admin / Bridges** — the control panel (carousel, settings, domain wizard, deploy) and the Memory (RAG) proxy.
- **Bridges** — the WebSocket bridges to the five coding platforms, and the always-on system terminal.
- **Data** — the SQLite database plus media / file storage.
- **Memory** — the LightRAG vector knowledge base.
- **Brain** — the Hermes orchestration agent.

Only ports 22/80/443 are public. The service ports are reached through Nginx in secure mode, or directly on the IP during onboarding. Nothing else is needed — no external Postgres/MySQL, no S3/MinIO, no Docker; the database is a file and storage is local disk, all on your server.

---

## Open layer vs guarded layers

The product exists so AI agents can build YOUR app, so the layers have different access rules:

- **Open layer (the app):** where the in-VPS coding agents work freely — this is your product.
- **Guarded layers (auth, data, memory, bridges):** soft-protected from accidental agent edits; advanced users can still extend them — add an auth provider, a new data strategy, or tune the agent ↔ memory wiring.

The whole product on your server is Open Code (source-available). A security audit confirmed that a deployed server cannot push to Fractera's own repositories — your instance is isolated and yours.

---

## Security model — why a raw port can't bypass secure mode

In secure mode access is protected by two independent layers:

- **Per-process authentication.** The mode flag is per-service; in secure mode every service enforces login. The session cookie is Secure and scoped to your domain, so it is never sent to a bare-IP address — you cannot be logged in over the plain-IP path.
- **Host firewall.** Secure mode closes every inbound port except 80/443, so the service ports (database, Memory, Brain, etc.) are unreachable from the internet. Nginx on 443 becomes the only entrance, while the local reverse proxy to each service keeps working.

In onboarding (IP) mode the ports stay open on purpose for zero-friction first access; only secure mode locks down.

---

## Is it safe to install? Audit the code yourself

A fair question: could the installed software hide a threat — something that quietly runs an unwanted behavior? The honest answer is the strongest one: you are installing **Open Code (source-available)** software, so you can verify everything.

- **Audit before going live.** At any time you can ask an AI agent to run a detailed audit of the files installed on your own server. Your agent can confirm the installed code is safe and matches the public reference on Fractera's GitHub.
- **Go as deep as you want.** You can ask the agent to analyze every file on your server, not just ours. This is exactly the right instinct: we are entering an era where you should trust no one blindly, and installing files from someone else's source genuinely can carry hidden risk.
- **Why ours stands up to it.** The packages we install are maximally transparent — all from open source, so they can be inspected by any security team or accredited auditor without a shred of doubt. Source of truth: https://github.com/Fractera/Agent-Engineering-Infrastructure.

In short: don't take our word for it — have your AI agent check, before and after deployment.

---

## "Powered by Fractera" footer

By default the public pages of your site carry a small "Powered by Fractera" link — a crawlable back-link to the project. It is added at the web-server layer (not inside your app code), so it is consistent across your public pages.

Sponsors at the **$5 tier (white-label)** have it removed automatically and permanently — and if you rebuild your server, white-label status is reapplied so it stays removed.

---

## Hermes Web Chat — the main way you talk to Brain

Brain (Hermes) ships with a built-in **web chat** — a friendly chat panel that is the **primary way you interact with the system**. The moment your workspace opens, the chat is already there: it **opens automatically** in the admin panel, ready to use. The only thing you need to add is a model.

**How it works.** The chat is a thin, friendly front-end wrapped around the same Hermes agent running on your server. Your messages go to Brain, which thinks, queries Memory, and coordinates the coding agents, then replies in the chat. It reads the same single credential pool as everything else, so a provider you connect once works everywhere.

**Where it lives.** Inside the admin panel the chat opens automatically. On a custom domain it ALSO gets its own clean, auth-protected subdomain — **chat.<your-domain>** — so you can open it as a standalone "Remote Command Post" and manage the whole project from a light external link (even from your phone), without the full control panel. In IP mode it is reachable directly at `http://<your-ip>:9120`.

**Login.** The chat has **no separate login of its own** — its built-in registration / setup wizard is deliberately turned off (one credential store, not two confusing onboarding flows; you never set a chat password). On a fresh IP server the chat is open like the rest of the onboarding workspace. Once you attach a domain (secure mode), the chat — and the agent dashboard and Memory — are protected by **Fractera's own authentication**: you sign in once (admin role), and every internal port and subdomain is gated. So the chat is ready instantly, yet fully protected the moment you go secure.

**Telegram is secondary and optional.** It is **not** the main surface — it simply lets you *also* talk to Brain from your phone. Unlike the web chat (ready immediately, zero setup), Telegram needs setup: a @BotFather bot token in **Settings → Telegram**. Use the built-in web chat as your main tool; add Telegram only if you want a phone channel too.

**Recommended model.** Start with **gpt-5-mini via the OpenAI API** for both Brain and Memory — it costs about a cent per hour and is plenty to get going. Only switch to a **Codex subscription** once your usage would exceed roughly **$20/month**; below that, pay-as-you-go gpt-5-mini is the better deal.

---

## Free daily model quotas — keep agents running at no cost (optional)

Many providers offer a **free daily quota** on some of their models. You can optionally configure these free models in your workspace so that when one model's free limit for the day runs out, the agents **fall back to another** and keep working — without you paying anything. This is an extra option that the rich multi-model setup here makes possible: in a plain single-model dev setup you simply wouldn't have so many models to fall back across. It is not required — set it up only if you want to stretch usage at zero cost.

---

## Emails you receive

At key moments Fractera emails you. (Your server reaches the Fractera service, which sends the mail — you never configure an email provider yourself.) Typical messages: installation started; installation progress; a recovery token (to re-engage via the MCP agent if anything breaks); your server is ready (with the links); domain activated (secure mode live); certificate-expiry warning; deploy failed (with recovery options); and subscription / sponsorship notices. Always use a real address you control.

---

## Your dashboard

You manage everything from your Fractera dashboard at fractera.ai/dashboard: your servers — each with direct links to its app and admin panel — and your subscription / sponsorship status. The links shown adapt to whether a server is on a bare IP (plain HTTP) or a real domain (HTTPS).

---

## How Fractera (the service) connects to your server

A clear split. The product runs on **your** server (Open Code, all the layers above). An external Fractera service — operated by us — is what **provisions** it, **delivers** it and its updates, **sends** your emails, **powers** the dashboard and the MCP chat-deploy, and handles **billing / sponsorship**.

You interact only with the RESULTS of that service — the deploy, the dashboard, the emails, the MCP agent — and your code and data always stay on your server. (How that service is built internally is intentionally not part of this reference.)

---

## Security & passwords — does Fractera keep access to my server?

**Does Fractera store my server password?**

No. When you deploy, your server's root password is used only in memory, for the few minutes of installation, to connect to the server and set it up. It is never written to Fractera's database — our records keep only a masked placeholder ("*****"), never the real password. This is enforced in code at every place a server record is created.

**So can Fractera access my server later?**

No. Because the real password is never stored, Fractera has no credential to authenticate with once installation finishes. There is no hidden key, no backdoor, no "support access". The connection that performed the install is closed and nothing is retained.

**Then why must I change the password after deployment?**

Two reasons. First, you typed the password to start the install, so as basic hygiene you should rotate it. Second, changing it is your own guarantee: once you set a new password that only you know, it is provably impossible for anyone — including Fractera — to reach the server with the original one. Changing it is your responsibility and a condition of using the service (see the Terms of Service).

**Could I be hacked "because the password was with Fractera"?**

No claim of that kind can hold. Fractera does not store the password and requires you to change it. If a server were ever compromised, the cause would be something else — a weak or reused password you kept, an exposed service, malware, a third party you shared access with — never retained Fractera access, because there is none. If you complete the password change, Fractera cannot retain access under any circumstances.

**Who is Fractera, legally?**

Fractera, Inc. is a registered Delaware C-Corporation (USA) with a real legal address, publicly accountable for its actions. Not an anonymous operator: we publish our Terms of Service and Privacy Policy and are bound by them.

**Best practice — deploy on a clean server.** For complete peace of mind, install onto a fresh VPS that holds none of your existing data. Then there is nothing pre-existing to worry about, and after you change the password the server is exclusively yours.

---

## Terms of Service

### 1. Acceptance of Terms

By accessing or using Fractera, you agree to be bound by these Terms of Service ("Terms") and our Privacy Policy. If you do not agree to these Terms, please do not use our services. These Terms constitute a binding legal agreement between you and Fractera, Inc.

### 2. About Fractera, Inc.

Fractera, Inc. is a corporation incorporated under the laws of the State of Delaware, United States. We provide a platform for deploying and managing AI coding environments on your own server infrastructure.

### 3. Description of Service

Fractera, Inc. provides a platform for deploying and managing AI coding environments on your own server infrastructure. We facilitate subdomain registration and server setup, but you retain full ownership and control of your server. We are not responsible for the content, security, or uptime of servers you provision.

### 4. Account Responsibilities

You are responsible for maintaining the confidentiality of your account credentials and for all activities that occur under your account. You agree to notify us immediately of any unauthorized use of your account.

### 5. Subscriptions and Payments

Some features of Fractera require a paid subscription. By subscribing, you agree to pay the fees set out at the time of purchase. Subscriptions are billed in advance on a monthly or annual basis. Most payments are processed by Stripe; alternative local payment providers may be used depending on your country of residence and will be displayed at checkout.

Cancellations and refunds are governed by our Refund Policy, which includes country-specific rights (EU 14-day withdrawal, Brazil 7-day regret, UK cancellation rights, and Australian consumer guarantees).

### 6. Acceptable Use

You agree not to use Fractera to:

- Violate any applicable local, state, national, or international laws or regulations.
- Infringe intellectual property rights of Fractera, Inc. or third parties.
- Transmit harmful, unlawful, defamatory, or fraudulent content.
- Interfere with the proper functioning of our services or servers.
- Attempt to gain unauthorized access to our systems or other users' accounts.

### 7. Intellectual Property

The Fractera platform, including its software, design, trademarks, and content, is owned by Fractera, Inc. and protected by intellectual property laws. Your subscription grants you a limited, non-exclusive, non-transferable license to use the platform for your internal business purposes.

### 8. Limitation of Liability

To the maximum extent permitted by applicable law, Fractera, Inc. shall not be liable for any indirect, incidental, special, consequential, or punitive damages arising from your use of the service, including but not limited to loss of data, revenue, or service interruptions. Our total liability to you for any claim arising from these Terms shall not exceed the amount you paid us in the 12 months preceding the claim.

### 9. Disclaimer of Warranties

The service is provided "as is" and "as available" without warranties of any kind, express or implied, including but not limited to implied warranties of merchantability, fitness for a particular purpose, and non-infringement.

### 10. Termination

We reserve the right to terminate or suspend your account at any time for material violations of these Terms, with or without notice. You may terminate your account at any time by contacting us. Upon termination, your right to use the service ceases immediately.

### 11. Governing Law and Dispute Resolution

These Terms are governed by and construed in accordance with the laws of the State of Delaware, United States, without regard to its conflict of law principles.

Any dispute arising from these Terms shall first be subject to good-faith negotiation. If unresolved within 30 days, disputes shall be submitted to binding arbitration in Delaware under the rules of the American Arbitration Association (AAA), conducted in English.

EU / EEA residents: Nothing in this clause limits your rights under mandatory consumer protection laws of your country of residence, including your right to bring a claim before your local courts or consumer authority.

### 12. Changes to Terms

We reserve the right to modify these Terms at any time. We will notify you of material changes by email at least 14 days in advance. Continued use of the service after changes take effect constitutes acceptance of the revised Terms.

### 13. Server Access Credentials & Your Security Obligations

To install Fractera on your server, you provide your server's IP address and root password. This password is used only transiently, in memory, to perform the installation. Fractera does NOT store your server's root password: our systems retain only a masked placeholder, never the actual credential. Once installation completes, Fractera has no technical means to access, log into, or control your server.

You acknowledge and agree that changing your server's root password immediately after installation is YOUR responsibility and a condition of using the service. You are solely responsible for the ongoing security of your server, including password rotation, firewall configuration, and access management. We strongly recommend deploying onto a fresh, clean server that contains no pre-existing data of yours.

Because Fractera does not retain your server password and requires you to change it after installation, any claim, demand, or theory of liability premised on Fractera having retained access to your server through the installation password cannot be sustained: where you fulfil your obligation to change the password, Fractera cannot, under any circumstances, retain access. Fractera, Inc. is a duly registered Delaware corporation accountable for its actions. Nothing in this section limits any mandatory consumer rights you may have under the law of your country of residence.

### 14. Contact

---

## Privacy Policy

### 1. Introduction

Fractera, Inc. ("we", "our", or "us"), a Delaware corporation, is committed to protecting your privacy. This Privacy Policy explains how we collect, use, disclose, and safeguard your information when you use our platform. Please read this policy carefully.

### 2. Information We Collect

We collect the following categories of personal information:

- Account data: email address, name, and authentication credentials when you create an account.
- Payment data: billing details processed by Stripe or other payment providers. We do not store full card numbers.
- Usage data: log data, IP address, device type, browser, pages visited, and feature usage.
- Server data: the IP address and optional subdomain of servers you provision. We do NOT store your server's root password — it is used only in memory, during installation, and is never written to our database; we keep only a masked placeholder ("*****").
- Communications: messages you send to our support team.

### 3. How We Use Your Information

We use the information we collect to:

- Provide, operate, and improve our services.
- Process payments and manage subscriptions.
- Send transactional emails (account creation, billing receipts, password reset).
- Respond to support requests.
- Detect and prevent fraud or security incidents.
- Comply with legal obligations.

We do not sell your personal data to third parties.

### 4. Data Storage and Security

Your account and subscription data is stored on servers located in the European Union (Neon managed PostgreSQL, EU region). We implement industry-standard technical and organizational measures including encryption at rest and in transit, access controls, and regular security reviews. Despite these measures, no system is completely secure. Importantly, we never store the root password of the servers you provision: it is used transiently to run the installation and is then discarded, so Fractera retains no credential capable of accessing your server after setup completes.

### 5. Data Sharing and Third-Party Services

We share your information only with the following categories of service providers:

- Stripe — payment processing.
- Resend — transactional email delivery.
- Upstash — session caching (Redis).

We may also disclose your information if required by law, court order, or to protect the rights and safety of Fractera, Inc. or others.

### 6. EU / EEA Residents — GDPR Rights

If you are located in the European Union or European Economic Area, the General Data Protection Regulation (GDPR) grants you the following rights:

- Access: request a copy of the personal data we hold about you.
- Rectification: request correction of inaccurate data.
- Erasure: request deletion of your data ("right to be forgotten").
- Portability: receive your data in a machine-readable format.
- Object / Restrict: object to or restrict certain processing.

Our legal basis for processing is performance of a contract (subscription services) and legitimate interests (security, fraud prevention). To exercise your rights, contact us by email. We will respond within 30 days.

### 7. California Residents — CCPA Rights

If you are a California resident, the California Consumer Privacy Act (CCPA) grants you the following rights:

- Know: request disclosure of what personal information we collect, use, disclose, and sell.
- Delete: request deletion of personal information we have collected from you.
- Opt-Out of Sale: we do not sell personal information. No opt-out is necessary.
- Non-Discrimination: we will not discriminate against you for exercising your CCPA rights.

To submit a CCPA request, contact us by email or by mail at the address below. We will verify your identity before processing your request.

### 8. Data Retention

We retain your personal data for as long as your account is active and for a reasonable period thereafter to comply with legal obligations, resolve disputes, and enforce our agreements. You may request deletion of your account and associated data at any time.

### 9. Cookies

We use cookies and similar tracking technologies. Please see our Cookie Policy for details.

### 10. Changes to This Policy

We may update this Privacy Policy from time to time. We will notify you of material changes by email or by posting a notice on our platform. Continued use of the service after changes constitutes acceptance of the updated policy.

### 11. Server Access Credentials

When you provision a server through Fractera, you supply its IP address and root password. The root password is used only in memory, for the duration of the installation, to connect to and configure your server. We do NOT persist your server's root password to our database or any of our systems — only a masked placeholder ("*****") is retained. After installation, Fractera holds no credential capable of accessing your server.

Because we do not store this password, we ask you to change it immediately after installation and to manage your server's security yourself. See our Terms of Service for the corresponding security obligations.

### 12. Contact

---

## Agentic Engineering Infrastructure: Self-Hosted & Token-Free

The Fractera robot installs agentic engineering infrastructure on your VPS in 10 minutes.

- **Zero to Production** — Your VPS, domain, auth, database, and five AI platforms — live in 10 minutes. No cloud accounts to set up. No infrastructure decisions to make.
- **Exit the Cloud** — No Clerk. No Supabase. No Vercel. Auth, storage, and database run on your own server — one bill, one place, full ownership.
- **Any Device, Full Speed** — All computation runs on your VPS. Build from a laptop, tablet, or phone without hitting hardware limits.
- **Ship 10× Faster** — AI skips months of scaffolding. Production-grade starters mean your first feature ships in hours, not weeks.

---

## The Self-Hosted AI Agent Infrastructure: Zero Token Metering

**Hermes Orchestrator: Multi-Model Agentic Loops**

Hermes Agent by Nous Research, deployed and configured on your VPS. Coordinates Claude Code, Codex, and Gemini CLI through shared context. Switch to API mode for autonomous agentic workflows that run without your input — every loop refines the next.

**LightRAG: Persistent Memory for AI Agents**

A persistent vector store by HKUDS, shared across all five coding platforms. Your codebase, every architectural decision, every solved problem — always in context. No more starting each AI session from scratch. The company brain that compounds with every iteration.

**Five AI Coding Platforms, One Server**

Claude Code, Codex, Gemini CLI, Qwen Code, and Kimi Code — all preconfigured on your server. Run on your existing AI subscriptions. No API keys to manage, no per-token billing. Switch platforms mid-task without losing your project context — LightRAG keeps the thread.

**Dedicated VPS Environment with Custom Domain**

Dedicated Ubuntu 24.04 VPS configured automatically. Custom domain provisioned, SSL issued, Nginx routed — before you write the first line of code. Recommended provider: Contabo. 4 cores and 6 GB RAM is the minimum we recommend.

**Pre-Configured Secure Database & Auth Stack**

Google OAuth, magic-link email, SQLite with WAL mode, file storage, and vector store — preconfigured on your server. No Clerk subscription, no Supabase invoice, no separate email provider. One stack, owned by you, billed once through your VPS provider.

**Monetize AI Workflows via Skills Marketplace**

Package the workflows you've solved into reusable AI Skills. Sell them in the community marketplace, share them free, or buy battle-tested recipes from other builders. Your self-hosted stack becomes a passive revenue stream — your best work earns while you sleep.

---

## Autonomous AI Orchestration Under Your Full Control

Modern AI coding is easy — the hard part is owning the infrastructure. Fractera makes ownership effortless: a dedicated Ubuntu VPS, an automatic custom domain with SSL, and a production-ready product stack — all yours, forever.

1. **Private AI infrastructure on your VPS** — Buy once, and minutes later your own web infrastructure is live. You only add your VPS credentials a single time. The site, the admin panel, AI agents, memory, database, and storage all deploy and sync automatically. Everything belongs to you alone — not a single byte in someone else’s cloud.
2. **Custom domain and SSL in a minute** — The moment it deploys, your project is reachable and ready — over plain HTTP, which is plenty for early experiments. For everything else, connect your own domain: buy it from any registrar and attach it in under a minute. SSL certificate, DNS, and Nginx routing configure themselves.
3. **Your domain triggers secure mode** — Activating your own domain flips the server into secure HTTPS mode automatically. You sign in as administrator inside your own authentication platform. Later you can add more admins — but by default you’re the only one with access to the AI agents. No shared SSO, no third-party access console.
4. **A full map of your server** — Every important server event is mirrored to your email. So domain activation hands you a full map of what was built for you: the admin panel with agents, your public site, your Hermes orchestrator agent, a LightRAG knowledge base, your own auth platform governing every service, plus a database server and object storage.
5. **Admin panel: five core tools** — After signing in you land straight in the admin panel — mission control for your agents and web space. Five tools: a live preview of your main app; an agent selector carousel (Grok Builder lands soon); project settings; GitHub integration for local IDE work; and the Fractera skills marketplace.
6. **Hermes orchestrator — your project core** — Activate Hermes — the orchestrator agent you actually talk to. It routes tasks across AI agents, developers, and the memory agent. It can run on the OpenAI key you added earlier, but a Codex subscription is far more efficient: authorize in the browser and slash token spend on a powerful model. On a truly beefy server or home machine (AI company brain mode) you can skip subscriptions and use your own compute.
7. **LightRAG — your project’s memory** — Switch on your project’s global memory — it stores everything happening across your work and business. All it needs is an OpenAI key: the service is extremely frugal with tokens, just keep the balance positive. This vector memory is a future-defining edge: the more it knows, the fewer tokens your main AI agents burn.
8. **Claude Code on your own server** — Want to code with the Anthropic agent? Run /login and activate your subscription by following the prompts. From there you can write code right inside this terminal. But the priority, recommended path is working through the Hermes agent from Telegram — one entry point to every platform.
9. **Codex: your key or subscription** — Codex is available automatically the moment you activate your key in the previous step. To switch to a subscription, first leave registration mode with /logout, close the tab, and reopen it. Then repeat authorization, choose the subscription, and finish signing in by following the prompts.
10. **Gemini — free production coding** — No AI keys yet? Start with Gemini — it hands you a free trial and refreshes session limits every single day. The simplest way into production coding at zero cost. No command needed: just follow the authorization steps in order.
11. **Qwen Code — an alternative engine** — Qwen Code also runs on a subscription right in the terminal and is driven through Hermes. Every platform tackles broadly similar tasks, but each styles app interfaces differently by default. The design Qwen generates often comes out noticeably bolder.
12. **Kimi Code — generous credits** — Kimi Code runs on a subscription and serves as an alternative to the standard models. In certain scenarios it grants more generous credits for the same spend — a handy backup engine when you need more volume at the same price.
13. **Your own database, zero cloud** — The database is already installed on your server and wired into the project. For convenience the admin panel gives it a dedicated tab — a clear web UI to watch database health and make changes when needed. Under the hood it’s lightweight Postgres, and your AI agent already knows how to create and update data models with zero dependency on someone else’s paid cloud.
14. **Your object storage, out of the box** — The image processing and storage service is part of your server too, deployed automatically. Nothing to configure: start adding images to your project right away. Files live on your own disk, not in someone else’s S3.
15. **A production starter from minute one** — Your server ships with an app already built in: public and private routing, a clean structure built to grow, modern patterns, and solid scaling. Best of all, the starter saves you tokens and time — almost everything you’d normally build and integrate before the real work is already done. A preview is always in your admin panel, and the same version lives at your main address.

---

## Production-Grade RAG Architecture: Hermes & LightRAG Integration

Production AI development happens entirely in your browser, from the first second. No VS Code. No local environment to configure. No database to spin up. No domain to wire. No deployment pipeline to debug. You open a tab — your server is already live, your domain is already registered, your database is already running, and five coding platforms wait for your first voice command. This is not just a tool for developers — this is the moment anyone with an idea can build, ship, and scale a real product without leaving the browser.

**AI Coding in Browser** — Open a tab, speak your intent, watch code appear. No IDE, no local setup. Five coding platforms run directly in your browser — terminals included.

**Live in Production. Instantly.** — Your server launches in seconds. One click deploys your changes live. No CI pipeline, no hosting configuration — just ship.

No API keys. No local setup. All five coding platforms run on your server with full terminal access and persistent LightRAG memory.

- **Claude Code** (Anthropic) — Writes, runs, and fixes code in your terminal. The gold standard for AI-assisted development workflows.
- **Codex** (OpenAI) — Browser-native coding agent. Full project context, no terminal required.
- **Gemini CLI** (Google) — Long-context coding agent. Understands your entire project structure in one prompt.
- **Qwen Code** (Alibaba) — Open-source coding agent. No subscription lock-in — powerful and free.
- **Kimi Code** (Moonshot) — Context-first model for large codebases. Excellent for refactoring and architecture work.
- **LightRAG** (Fractera) — Your company brain. Persistent vector memory shared across all five coding platforms.

* The project runs on your own subscriptions to the AI platforms — Fractera does not charge any additional fees or commissions for their use. You are free to connect one, several, or all five platforms — at your own discretion.

---

## The Hidden Costs of Fragmented AI Stacks

Modern AI development stacks are fragile, expensive, and forgetful. Here is what that costs you in practice.

**Unpredictable Cloud Costs**

The problem: Auth, storage, database, email — each service bills separately and scales with traffic. Free becomes paid, paid scales with load. Miss one payment and your live product goes dark.

How Fractera solves it: Fractera runs auth, databases, and storage on one server. One subscription, one bill. Cost does not scale with your users. Pause the business — your data stays safe.

**AI Loses Context Every Session**

The problem: Without persistent memory, every session starts from scratch. Tokens spent on "where is the navbar?" are tokens not spent on your feature. Two messages become fifteen.

How Fractera solves it: Fractera includes LightRAG — a persistent vector store that remembers your codebase and every architectural decision. Switch between Claude Code, Gemini CLI, or Codex without losing the thread.

**Too Many Single Points of Failure**

The problem: Ten services mean ten billing cycles, ten dashboards, ten places something can break. One service quietly expires — you do not know which one caused the white screen.

How Fractera solves it: Everything your application needs lives on one server. Code stays on GitHub — recovery is always possible. Built-in AI assistants can rebuild the project even with outdated packages.

**Your Hardware Limits Your Output**

The problem: Persistent memory, autonomous agents, five platforms in parallel — it pushes your machine hard. Performance drops the moment you open another tab. Not everyone has a dedicated GPU workstation.

How Fractera solves it: With Fractera your device carries zero load. All computation runs on your VPS. Scale cores and RAM when needed. Works on a laptop, tablet, or phone.

**Your Data on Their Servers**

The problem: Host on Vercel, store in Supabase, authenticate via Clerk — your business data sits on their infrastructure. One pricing change or one outage and your product goes down.

How Fractera solves it: Fractera moves auth, database, storage, and AI memory to a server you own. No third-party access to your data. No dependency on their uptime, their pricing, or their terms.

---

## Deploy Private AI Infrastructure on Your Own Server

Install Fractera on your own VPS and get the full AI development environment — completely free, Open Code (source-available).

**Free forever** — Free — install on your VPS.

- Hermes — AI orchestration agent
- 5 coding platforms
- LightRAG — the company brain
- Database, file storage & auth — built in
- Open Code — self-hosted forever

**Recommended Ubuntu 24.04 VPS Provider for AI Workloads.** Fractera installs on any Ubuntu 24.04 VPS with 4 cores and 6 GB RAM. Contabo is our recommended choice — high-resource configurations at the lowest price point, popular among AI builders.
- Contabo — High-resource VPS at unbeatable prices. Popular for AI workloads. (from €3.60/mo)

**Recommended Domain Registrar.** A domain gives your server HTTPS, a memorable URL, and removes browser security warnings. Hostinger gives you direct DNS management without forcing a proxy — exactly what Fractera needs.
- Hostinger — Direct DNS management, broad TLD support, no mandatory proxy. (from $0.99/yr)

---

## Enterprise-Grade Features for Agentic Infrastructure

Fractera Light covers 90% of what a professional application needs. Fractera Pro unlocks the remaining 10%.

- **Hermes AI Agents** (For all users) — Fully configured agents with self-learning memory. The most powerful AI technology available in seconds — not hours of setup.
- **Voice AI Commands** (For all users) — Issue coding commands and navigate content hands-free via microphone. Agents respond to natural voice input in real time.
- **Auth Stack Built-in** (For all users) — Google OAuth, magic-link via Resend, and Credentials — all pre-configured with role management and enterprise sessions.
- **Database & Storage** (For all users) — SQLite with WAL mode, object file storage, and media service included. Scales with your project without extra subscriptions.
- **Backups & Restore** (For all users) — Snapshot your database and object storage at any moment, then upload the archive to restore your project or clone it into a new one.
- **GitHub & Dev Workflow** (For all users) — GitHub sync, production coding and local development unified. Push, pull, and deploy directly from the admin panel in one click.
- **Platforms in 50ms** (For all users) — All five coding platforms preconfigured and ready to use. LightRAG global memory initialized on first start. Zero setup time.
- **Skills Marketplace** (For all users) — Discover, buy, and sell automation workflows in the community library. Share free skills or monetise your own recipes.
- **SEO, PWA & i18n** (For VIP sponsors) — Production-grade SEO, Progressive Web App support, and multi-language routing — all configured before your first user arrives.
- **Element Highlighting** (For VIP sponsors) — Click any UI element to capture its exact identifier. Communicate precise changes to the AI — fewer tokens, faster iterations.
- **Parallel Routing** (For VIP sponsors) — Up to 11 parallel routing slots with static SEO: tabs within one window update each other's state with no page reload at all.
- **Ready-made Sections** (For VIP sponsors) — Prebuilt page blocks cut token spend many times over: header, footer, AI, tools, advanced SEO architecture and a design platform.

---

## One Apple Silicon Appliance That Remembers Everything Your Team Has Ever Decided — And Acts On It

For B2B leaders who watch their company knowledge walk out the door every time someone leaves, every time a new hire joins, every time a meeting recap gets lost. The AI Company Brain is a single Mac mini in your office that captures the operating memory of your business — decisions, processes, voices, projects — and lets a Hermes-powered agent act on it on demand.

Fractera AI Company Brain is a physical Apple Silicon device (Mac mini or Mac Studio), personally configured by the Fractera founder, that combines two things you cannot buy off the shelf: a private LightRAG knowledge graph that ingests your meetings, documents, voice memos, emails and Slack history into a structured corporate memory — and a Hermes orchestration agent that uses that memory to do real work for you. A single box that replaces what would otherwise be a small team — a junior analyst, a project manager, a research assistant, a knowledge-base curator — and does it without forgetting, without leaving, and without leaking a single document into someone else's cloud.

**How the AI Company Brain replaces a small team**

**Captures the memory your team keeps losing**

LightRAG ingests every meeting recording, project doc, voice memo, customer email and decision log into a private knowledge graph. Names, dates, decisions, dependencies, "why we did it this way" — all linked, all queryable. When the founder asks "why did we kill that supplier last spring?" the Brain returns the meeting transcript, the email thread, and the deck — in seconds. No more Slack archaeology. No more "ask Anna, she remembers".

**Acts on the memory — does not just store it**

Hermes uses the Brain as its long-term memory and routes work to five subscription-grade AI specialists (Claude Code, Codex, Gemini, Qwen, Kimi) running on the same device. Brief it by voice from Telegram: "draft this quarter's investor update using last quarter's deck and our latest cashflow", "answer this customer email in our usual tone", "build a one-pager for the new product using our 2024 brand guidelines". The Brain remembers your context; Hermes turns it into shipped work.

**Returns finished work as a link, not a chat scrollback**

Every result comes back as a clean URL — a real document, a real deck, a real site, a real analysis. Open on your phone, project on the boardroom screen, forward to a teammate. This is the Iron Man moment: results, not prompt-engineering sessions. The Brain owns the institutional knowledge; Hermes owns the execution; you own the time saved.

**Runs 24/7 on your desk — nothing leaves the building**

The device runs in your office on Apple Silicon, sips ~30W, and never sends your knowledge graph or recordings to anyone's cloud. Schedule recurring jobs ("every Monday at 8am summarize what the leadership team agreed last week and what needs my attention this week"), or fire one-off requests. The Brain is awake while you sleep — you wake up to finished links in Telegram.

**Pricing & delivery.** By agreement — each AI Company Brain engagement is scoped individually because each business is different. Every package includes: founder-led memory audit (what knowledge your team is losing), the Apple Silicon device (Mac mini or Mac Studio), full LightRAG + Hermes + five-platform pre-installation tuned to your business, an initial ingestion of your existing meeting recordings / documents / Slack / email archive, hands-on training for you and your team, and 12 months of post-delivery support and process refinement. Year two and beyond — by separate agreement.

**Strictly limited capacity.** A small number of partner businesses per quarter. The depth of personal involvement by the Fractera founder is the value — and that requires bandwidth. If the next slot is full, we will tell you a realistic date.

**Why we know this is exactly what you need.** The AI Company Brain is the distilled life experience and business expertise of Fractera's founder. Dozens of personally shipped projects. Hundreds of allied companies. A thousand partners. And — most importantly — tens of thousands of hours of consulting, business development, and software engineering. Ready to amplify the memory and decision-making muscle of your business, and make it a sharper player in your niche. Just talk to us.

**Apply for a founder consultation.** Tell us about your business, the knowledge your team keeps losing, and what work you would hand to the Brain first if it were on your desk tomorrow. A short conversation with the Fractera founder is the first step — no commitment, no pitch deck, just a working session to see whether the AI Company Brain belongs in your office. (Email admin@fractera.ai)

---

## Frequently asked questions

**Why does Hermes reduce development costs rather than increase them?**

There is a widespread belief that an orchestration layer like Hermes is wasteful — that it is better to talk directly to a coding model and skip the middleman. We disagree completely, and here is exactly why.

The real cost driver in AI-assisted development is not the number of requests — it is context window inflation. Every message in a direct coding session appends to the running context. After two or three hours on a typical project, the context is carrying the full transcript of the session. Most providers charge for both input and output tokens, and because every new message pays for everything before it, costs grow faster than linearly. Real-world data shows a Claude Code session on a mid-size project in hour three costs five to ten times what it cost in the first fifteen minutes. When you forget to manage the context window yourself — and everyone forgets eventually — that cost compounds.

Hermes is the external observer that prevents this from happening. It runs on inexpensive models (gpt-5-mini, qwen-turbo, and similar) that cost twenty to fifty times less than frontier coding models. These models do not need sophisticated reasoning — they read a spec, extract what matters, route a task, and immediately clear the context before the next call. That is exactly the work they are suited for.

- LightRAG eliminates session amnesia — without persistent memory, every new session spends the first 10–30% of its tokens re-explaining the project from scratch. LightRAG stores architecture, patterns, anti-patterns, and decisions, so the actual coding prompt can be laser-focused from the first word.
- Precise task specs from context — instead of a vague "build a dashboard", Hermes reads LightRAG and generates: "In app/dashboard/page.tsx, add a component using the Card pattern from components/ui/card.tsx, following the auth pattern from lib/auth.ts." This alone eliminates several back-and-forth exchanges per task.
- Immediate context clearing — after each task completes, Hermes clears the coding model's context. The next task starts with a clean slate, not carrying the entire previous conversation.
- Intelligent routing between models — simple tasks (documentation, refactoring, file renaming) go to cheap or free models. Complex architectural decisions go to frontier models. You pay frontier prices only for frontier work.
- Pattern and anti-pattern tracking — Hermes knows what approaches have worked in your project and which ones caused problems. It does not let the coding model re-discover the same dead ends.

This is only the surface. The deeper value is in what Hermes prevents: redundant searches for components that already exist, re-solving problems that were solved last week, sending the same context to five models in parallel when one focused call would do. Every one of those is a token cost that never appears on your invoice because it never happened.

We believe the future of efficient AI-assisted development is not about squeezing more out of a single model — it is about a system that knows your project well enough to ask the right model the right question at the right moment, and stop before it becomes expensive. That system is Hermes, and it is at the core of what Fractera is building.

---

**The same AI platforms — yet Fractera ships faster with fewer tokens. Why?**

Regular vibe coding puts all the heavy lifting on the AI: design the architecture, write boilerplate, locate the right component, recall what was decided last session. Every token spent on that overhead is a token not spent on your actual feature.

Fractera eliminates that overhead at every layer:

- Production-ready starters — Auth, database, file storage, and advanced routing ship fully pre-configured. The AI skips months of scaffolding and goes straight to your feature from day one.
- Component highlighting — Click any element on your live site to jump directly to its source. No tokens wasted asking "where is the navbar?".
- LightRAG, your company brain — A persistent vector store that remembers your entire codebase, every architectural decision, and domain knowledge. Every AI message arrives with full context.
- AI-optimized skills & instructions — Pre-built prompts and workflows designed for non-professional developers. The right approach on the first try.
- Cross-platform orchestration — LightRAG coordinates all five coding platforms so they share context. Switching from Claude Code to Gemini CLI doesn't mean losing the thread.

The result: tasks that take 10–20 back-and-forth messages in a vanilla AI chat typically resolve in 2–3 focused exchanges inside Fractera — token spend drops 70–90% compared to classic vibe coding.

This is Fractera Pro. And once you've tried it, there's no going back to plain vibe coding.

---

**How does Fractera keep your business stable?**

Modern web development has a tempting formula: combine a handful of "free" services — Clerk for auth, Supabase for your database, a dozen other cloud APIs. It looks great on day one.

The problems surface when your prototype becomes a real business. Each service quietly updates its pricing. What starts as free becomes a paid tier that scales with traffic.

Worse: ten billing cycles to track. Miss one and your project goes dark. No warning, no grace period. Partners who switched to Fractera often share this story: a live project lost because one service expired. By the time they figured it out, the reputation damage was done.

Fractera is built around a different principle: everything your business needs — authentication, databases, media storage — lives on your server, not spread across a dozen cloud dashboards.

- One subscription, one server — cost does not scale with your users.
- If you pause your business, your data does not disappear. Back it up and restore when you're ready.
- Your application code lives on GitHub — recovery is always possible, even if dependencies have aged.
- Built-in AI systems can help rebuild the project even when some packages are outdated.

One server. One bill. Maximum resilience — whether you are running one project or ten.

---

**Do I pay per token for the AI, or use my own subscription?**

You use your own subscriptions — that is the whole point. The five coding platforms (Claude Code, Codex, Gemini CLI, Qwen Code, Kimi Code) run on the subscriptions you already have: you sign in once with your normal account, like a local CLI. No API keys to manage, no per-token billing surprises. This is where the heavy AI work happens, and it costs you nothing beyond the subscription you already pay the AI vendor.

The only per-token piece is small and auxiliary: Brain (Hermes) and Memory (LightRAG) use one inexpensive OpenAI API key — the cheap gpt-5-mini runs at roughly a cent per hour and is plenty to get going. If your Brain usage grows heavy, you can switch it to a Codex subscription instead.

- Coding platforms (Claude Code, Codex, Gemini, Qwen, Kimi) — your existing subscriptions, no per-token billing.
- Brain + Memory — one small OpenAI key (gpt-5-mini, ~1¢/hour), or a Codex subscription if heavy.
- So a Claude Code user pays through their subscription, not per token.

---

**What server specs do I need?**

For full AI-coding workloads, the recommended minimum is 6 cores and 8 GB RAM. Storage depends on your project — 75 GB is a solid baseline.

Once active AI development wraps up, you can downgrade to 2 cores / 4 GB RAM — typically €1–2 per month.

---

**Step by step — what does the full path from buying a server to monetizing my product look like?**

The complete cycle: from an empty VPS to a live product on the marketplace. Under 30 minutes to launch, everything after that runs at your development pace.

1. Buy a VPS from Contabo (our recommended provider). Receive your IP address, login, and password.
2. On the "Your Server" tab, enter those credentials and launch the deployment. Watch real-time events for a few minutes. Two emails arrive: one when installation starts, another when it completes.
3. Your dashboard sits in the top-right corner — click your name after signing in. Inside you will find direct links to your live site and admin panel. The same links arrive in your completion email.
4. Sign up in the admin panel with a real email and password (save them carefully). The first user becomes the administrator — only admins can change settings. You can promote more admins later.
5. Have your own domain? Open "Settings", enter the domain name, copy the A-record. Set it at your DNS provider — and it works immediately.
6. Authorize one or more coding platforms (Claude Code, Codex, Gemini CLI, Qwen Code, Kimi Code). Codex is recommended as the channel for working through Hermes. Authorization is standard browser-based, just like in a local CLI. One-time setup.
7. Open Hermes and configure it your way. Add a messenger channel, or use the chat directly in the admin panel.
8. Tell Hermes what to change or what to generate. For example: "Let Claude do this and Codex do that" — both run in parallel through Hermes orchestration.
9. Upload documents (requirements, business description, any reference material) to your Company Brain — powered by LightRAG — manually, or ask Hermes to automate your data ingestion.
10. Want to accelerate? Ask Hermes to find a ready-made solution from the Fractera skills marketplace.
11. Your domain is live from minute one. After every development cycle, the site updates automatically — no manual deploy step.
12. Finished a project? Ask Hermes to turn it into a skill and publish it on the marketplace. Set a price, sell it, earn.

This loop repeats as many times as you want. Every product stays yours — on your server, under your domain, your code, your data, your subscriptions.

---

**Roadmap & vision: where is Fractera headed?**

When you start a business for the first time, almost everything around you is unfamiliar. Registering the company, opening a bank account, standing up a website and social profiles, streamlining production, finding traffic, balancing the unit economics, and finally scaling. An AI agent helps at every step — but it is not a single "do it all" button: it is a road you cannot walk in a day, or even a month.

Along that road the AI keeps proposing solutions. Some turn out right, some wrong; some save you money, some waste it, and once in a while income appears out of nowhere. Until now, this priceless zero-to-product experience lived only in your head. Now it can be digitized.

And this is nothing like reading a book or running through a checklist. The AI that solved every task alongside you, listened to your conversations, prepared your presentations — can assemble not a step-by-step manual but a living knowledge base. Not yes/no, but the complex conditional logic of decisions that modern AI can analyze and carry over — even to a different region, with different inputs and a different outcome.

So whoever is lucky enough to buy your digitized experience walks the same road faster and with far fewer mistakes. Admit it — you would want to be in their place too: to save years of your life and not pay for someone else's mistakes with your own money.

- More than a book — a book gives one route; the loop remembers the forks.
- More than a checklist — a checklist answers yes/no; the loop reasons in context.
- More than a course — a course teaches in general; the loop knows your exact path.

This is what we call the product loop — and it is the product we want to build in the near future.

Already have experience, or a company of your own? Want to digitize your current business — or your next one? Become a project sponsor: you join a private Telegram group where you can talk to the founder directly and be first to shape what our core service becomes — the product loop and its skill marketplace.

Stay with us — we will build it together.

---

**Can I bring my existing project into Fractera and continue AI-assisted development?**

Yes. Connect your existing GitHub repository to your Fractera workspace and start coding with AI immediately. Depending on your project's complexity, some initial migration steps may be needed — Fractera's built-in AI assistants can guide you through.

---

**Can I deploy a finished project to Vercel instead of keeping it on my own server?**

Yes — once a project is complete and no longer needs active AI-assisted development, you can export it to Vercel.

Important: moving to Vercel means leaving the Fractera environment behind. The AI coding workspace, terminal access, LightRAG memory, and all five development platforms only run on your own server.

Also keep in mind that Vercel and cloud storage pricing can escalate quickly under real-world traffic. Migrating back to a self-hosted Fractera server is straightforward — your code is already on GitHub.

---

**Can I deploy a regular project without AI?**

Yes — you can deploy a plain server with no AI at all. It is a common, deliberate choice, especially among experienced developers who want to offload the work of managing cloud resources and avoid DevOps overhead.

A server like this can be used at any time, synced with your home or work IDE (for example, Visual Studio Code), or simply to host and run your existing projects on infrastructure you control.

- Optional authentication — turn it on whenever you need it.
- Local database and object storage (for example, media) — included, with no cloud subscriptions.
- Freedom from cloud lock-in — meet regulatory or internal-policy requirements and avoid surprise bills.

A plain server like this needs only a lighter, more economical VPS. During deployment, switch to custom mode and tell us which services you want.

Don't worry if you turn off something you might need later — you can always add any recommended or custom AI tool through the terminal built into your admin panel.

---

**Do I need a Claude Code subscription to deploy via the MCP connector?**

Not necessarily. If the Fractera connector is your only custom MCP, you can use it on the free tier and get the full deployment service — no subscription required.

The condition is that you have not added another primary or custom MCP. If you already use a different custom MCP, you have two options: remove it before adding the Fractera connector, or move to a paid Claude plan (for example, Claude Pro, around €20/month), which lets you keep several custom connectors at once. Note this is Anthropic's own plan for the connector — it is unrelated to Fractera, which is always free.

---

**Can I combine local development with the Fractera production platform?**

Yes — and for developers with an existing local setup, this is often the most natural workflow.

If you prefer working with hot reload in your IDE, you don't have to change your habits:

1. After setting up your Fractera project, connect it to a GitHub repository and push the initial codebase.
2. Pull the code to your local machine. Develop the way you always have — your IDE, hot reload.
3. When ready to ship, push your changes to GitHub.
4. Return to your Fractera workspace, pull from GitHub, and hit Deploy.

Your changes go live in production in minutes. In effect, your own server becomes a self-hosted alternative to Vercel: GitHub is the bridge between your local environment and production.

Your local environment will continue to use the database and file storage that live on your server — no cloud subscriptions required.

---

**Do you have a referral program?**

Yes — the Fractera Partner Program. The model is simple and provider-agnostic: you recommend Fractera deployment, your readers buy a VPS from any host with an affiliate program, the host pays you directly.

Fractera doesn't pick the provider for you and doesn't restrict your choice. You decide who to work with: Hetzner, DigitalOcean, Vultr, Hostinger, RuVDS, Timeweb, Contabo — dozens of hosts run affiliate programs. Direct programs (RuVDS, Timeweb, Hostinger) approve in a day and pay up to 30–40% of the customer's first payment. Affiliate-network programs (Contabo via CJ.com, others via Admitad) pay a fixed amount per new customer but take a few days to approve.

The Fractera cabinet works with any affiliate link — we provide the infrastructure (mirror page, embed widget, MCP, cabinet), the host pays the commission.

For questions: admin@fractera.ai

---

**How do I earn with Fractera?**

Your income from partnership is closer and simpler than you might imagine. One approval at any hosting provider, then passive payouts for as long as your content keeps bringing readers.

1. Pick a host with an affiliate program. Direct programs are faster: apply on the provider's own site (Hetzner, RuVDS, Timeweb, Hostinger and others each have their own affiliate cabinet). Affiliate networks (CJ.com for Contabo, Admitad for several providers) are slower but unlock a catalogue of 3000+ brands through a single registration.
2. Get your affiliate link once approved by the provider.
3. Open the Fractera partners page, create your partner cabinet, add your affiliate link (or multiple links from different providers — the cabinet supports several at once).
4. Receive your personal Fractera landing mirror, an embed widget for your blog, and a single MCP link for AI agents. Your links replace the defaults in the "Where to buy a VPS" block.
5. Recommend Fractera in your blog, YouTube channel, social posts — wherever developers and entrepreneurs gather.
6. Any visitor who follows your link and buys a server from a partner host triggers a payout. Amount depends on the provider: direct programs pay up to 30-40% of the first payment, networks pay a fixed amount (Contabo: 20-55 € depending on configuration). The host pays you directly — Fractera is never in the middle.

The math is simple: one approval at one provider, then passive payouts for as long as your article, post, or video keeps bringing traffic. Hosts compete hard for new customers — and you get rewarded for every one you bring in.

---

**Are you looking for regional partners?**

Yes — and this is a different kind of opportunity. We are looking for official regional partners to build localized versions of Fractera together: adapted for local regulations, delivered in the native language of the region, backed by people who understand the local market from the inside.

This is not a reseller arrangement. A regional partnership means your own branded product, your own customer base, your own revenue stream — on an Open Code foundation that is already production-ready. The infrastructure is built. What a regional partner brings is market knowledge, local trust, and the ability to serve customers in ways a remote team cannot.

- Regulatory alignment — help your region meet local data residency and compliance requirements.
- Native-language support — technical support and documentation in the language of your customers.
- Your own business — not a franchise, a co-venture with full transparency into the product.

===

# Agentic Engineering Infrastructure architecture

Reference page: https://www.fractera.ai/ai-workspace-architect
Canonical diagram: ![Fractera Agentic Engineering Infrastructure architecture diagram — Hermes multi-agent orchestration, LightRAG memory and five coding agents](https://www.fractera.ai/Fractera-Web-Architect.jpg)

## How Fractera works

Fractera turns one bare VPS into a complete AI development workspace. The picture above shows the whole flow; here it is in plain words.

**You drive it through middle layers, never raw infrastructure.** As the admin you have two ways in. You can manage the project **through Hermes** — the brain — in **natural language** using the **Hermes chat Web UI** inside your workspace, and you can also reach the same brain from **Telegram** or any other messenger. Or you can work **directly with the coding agents** in their terminals.

**It keeps working even without an API subscription.** Between you and a coding agent sits a small **modal sign-in layer**: you authenticate your existing subscription there, and the same window is used to send commands and receive results. **Hermes talks to the coding agents through the Model Context Protocol (MCP)** that drives that very window — so work stays resilient even when a third-party subscription tool is rate-limited.

**LightRAG is the central memory — this is where the token savings come from.** Every tool reads and writes a shared **vector database** through its own connector. Recalling exactly the right context instead of re-sending everything cuts token spend dramatically. That is why **LightRAG is the central memory** — a **Knowledge Graph RAG** shared by every agent and every session.

**Hermes is the brain; the coding agents do the heavy lifting.** We call Hermes the central brain, but the hardest work — generating code — is done by the **coding agents** such as Claude Code. Hermes is a light **multi-agent orchestrator**: it tracks each platform's token use, picks the right platform for a task, dispatches the work, launches deployments, and talks to GitHub.

**It also runs locally.** Without a paid subscription you can still use AI models — Hermes can run automatically, or you use the manual tools. This **Open Code, self-hosted AI platform** runs on **Next.js** on a standard **VPS**, with a built-in local **database** and **object storage**, plus many tools that streamline the work; it can also use the vector database to accumulate experience with your users and admins, steadily growing useful business data.

**The output is a secure web app.** On the way out the project is served over a **secure HTTPS connection** when you run it on your own domain, or it runs on a local machine over a plain **IP address** — in which case you secure the connection with one of the available options.

To see how this architecture actually *builds* software — how one request becomes tested, deployed code — read the [Fractera development loop](/ai-development-loop).

## What the AI Workspace looks like

This is what you get inside Fractera right after you deploy — a rich workspace that starts on its own. Click the screenshot above to see it full screen.

**It starts ready.** The workspace opens on the **Hermes chat Web UI**, ready to go. To activate Hermes you set your own key — and the **same key** can activate your **Memory**. Open the **Brain** tab, then the **Memory** tab, and press **Activate** in Memory to start embedding the starter documentation, so it is available at any time — used both as a help desk and by the coding agents.

**Pick your coding models.** The top row lists the **five coding platforms**. Choose one or several you want to work with, open it, and activate its subscription — just follow the prompts; it looks almost exactly like the standard interface. The far-right card is the **Terminal**, handy for watching the development process, and where you can add another code-generation platform if you like.

**Everything is one panel.** On the left, the **Settings** tab opens full control over your app and tools. In the footer you will find buttons to connect your **GitHub** repository, trigger a **deploy** by hand, and buttons that switch on later — when the marketplace of skills and ready-made digitized businesses goes live. Top-right, **Preview** shows the current state of the page you are building and the service pages that let you watch development. Unlike the main app, this view can highlight code and helps you find the right element — routing a request from a selected element straight to the Hermes chat or Telegram.

**It explains and improves itself.** The project ships fully **Open Code (source-available)**, so Hermes — or any model — can read this very codebase and give you a complete, detailed explanation of any feature: how it works and how it is built. You can just as easily ask a model to improve not only your end apps but the **admin panel shown here**. A word of caution: experiment on a **secondary account**, and keep your main one on reliable, proven solutions. If you want to add something, or you found a bug, please do not hesitate to open a **pull request** — we hope your contribution helps strengthen an already powerful architecture.

**Found this while researching modern architectures?** Then it is worth knowing: this whole complex setup on your **own server** takes literally one click. Enter your server credentials, start the deployment, make no settings and no choices — and in about **10 minutes** you get a fully configured app. After that you change your server access and connect a domain, and the security certificates assemble themselves automatically.

## Hermes — the orchestrator (Company Brain)

**Hermes** is the **multi-agent orchestrator** at the centre of the workspace (`fractera-hermes`, dashboard on `:9119`). It reads its identity and memory at every wake-up and drives the five coding platforms through their MCP bridges — this is the **AI agent orchestration** that makes Fractera a true multi-agent system.

Hermes is deliberately **light**: it does not write the hard code itself. It tracks how many tokens each platform is spending, chooses the platform that fits a task, dispatches the work to specialized coding assistants, records every build into the Product Loop journal, launches deployments, and integrates with GitHub. Its wiring lives in `config.yaml` (what it can reach); its personality lives in `SOUL.md` (who it is). See how it connects to everything in the [full workspace map](#schema) below.

### Hermes Chat Web UI

The chat window inside your workspace (`fractera-hermes-webui`, `:9120`) where you talk to Hermes in plain language. You brief the brain like a teammate and it drives the five coding platforms for you — no commands to memorise. This is the primary way most people use the system.

### Telegram and messengers

A gateway process (`fractera-hermes-gateway`) lets you reach the same brain from **Telegram** on your phone, and the design extends to any other messenger. Start, check on, or steer work away from the keyboard; the workspace keeps building while you are out.

## LightRAG — the central memory

**LightRAG** (`fractera-rag`, `:9621`) is the shared long-term memory of the whole workspace — not just Hermes. It is a **Knowledge Graph RAG** implementation: every agent queries the same graph and writes back to it — Hermes and all five coding platforms. This is **RAG for AI agents** done right.

That shared memory is the reason Fractera spends so few tokens. Instead of pasting the whole codebase into every prompt, each agent recalls exactly the relevant entities, relations and decisions. Ingest a document once and every agent can use it forever. It needs an embedding/LLM key to be active; without one it stays wired but silent. More background in the [project knowledge base](/mcp-info).

## Coding agents

Five subscription **AI coding assistants** run preconfigured on your server and do the heavy lifting of **automated code generation**. Each is driven through a bridge that keeps it alive over WebSocket and exposes it to Hermes as an MCP server (ports `3210–3214`). Integrate leading agents like **Claude Code** and **Gemini CLI** via **MCP**, using each one's strengths for multi-file changes or deep code review. You run them on your **existing subscriptions** — no API keys, no per-token billing — and you can switch platform mid-task without losing context, because LightRAG keeps the thread. [See all five platforms on the homepage](/en#platforms).

### Claude Code

Anthropic's coding agent. Its primary project-context file is `CLAUDE.md`. Strong at architecture, planning and careful multi-file changes — often the platform Hermes hands the hardest work to.

### Codex

OpenAI's coding CLI. Its primary project-context file is `AGENTS.md`. A fast generalist for implementation and iteration.

### Gemini CLI

Google's coding agent. Its primary project-context file is `GEMINI.md`. Large context window — useful for sweeping over big codebases and reviews.

### Qwen Code

Alibaba's coding agent. Its primary project-context file is `QWEN.md`. Another subscription option in the rotation Hermes can delegate to.

### Kimi Code

Moonshot's coding agent. Its primary project-context file is `AGENTS.md`. Rounds out the five platforms so Hermes always has an alternative when one subscription is busy or limited.

===

# The Fractera development loop

Reference page: https://www.fractera.ai/ai-development-loop
Canonical diagram: ![Fractera Development Loop diagram — one admin request flows through Hermes, a coding agent and LightRAG memory to tested, deployed code](https://www.fractera.ai/Fractera-Development-Loop.jpg)

## How the autonomous AI development loop works

The diagram above is the **Fractera Development Loop** — the cycle that turns a single request into tested, deployed, recorded software, with no human writing code. Here it is in plain words, following the arrows from the bottom up.

**1. A request comes in.** It starts with a **new admin request** — you ask for something in natural language, through the **Hermes chat Web UI** inside your workspace or from **Telegram**. You describe the outcome; you do not write code.

**2. Hermes wakes up and gets its bearings.** **Hermes** — the orchestrator, the brain — first loads *who it is* and *where it is*. It reads its identity file (`SOUL.md`), the AI core catalogue, and the current project's context files (`CLAUDE.md` / `AGENTS.md`). It asks the workspace which project is active and pulls that project's state. All of this is recalled from **LightRAG**, the shared memory — so Hermes starts already knowing your codebase instead of from a blank slate.

**3. Hermes picks the right worker.** Hermes is deliberately light — it does not write the hard code itself. It checks **which coding agents are ready** (installed and signed in) and chooses the best fit for the task — for example Codex for fast iteration, or Claude Code for careful multi-file work. This is multi-agent orchestration: the right agent for the right job.

**4. The chosen agent is enriched.** Before it works, the coding agent is grounded: it reads its own instruction file (`AGENTS.md`), the shared **glossary** (`GLOSSARY.md`, so it uses your terms), and the **completed development steps** — the history of what was already built and why. Again, all pulled from LightRAG.

**5. Generate a task, then the code.** The agent turns the request into a concrete **task** (you can optionally step in and steer it), then **generates the code** in the open `app/` layer. As it works, the result **renders step by step** so you watch the project take shape in real time.

**6. Test, deploy, branch on the result.** The change is **built and deployed**, then the loop branches on the result:
- **Error** → the failure feeds back into the loop: the agent gets a new task informed by what went wrong, and tries again. The loop self-corrects.
- **Success** → the loop records the outcome.

**7. Record and close.** On success the workspace **updates the completed steps** (the development log) and **updates the deployments tab** (the Product Loop journal — which agent, which model, how many tokens, the quality rating). The request is done, and everything learned is written back into memory.

**8. The output is a secure web app.** What ships is a real, running application — served over **HTTPS on your own domain**, or plain HTTP on an IP while you onboard. Your code, your server.

**Why it is a loop, not a pipeline.** Every pass writes back to LightRAG and to the recorded history, so the next request starts smarter than the last. Memory compounds, mistakes feed corrections, and the whole cycle runs on **your own VPS** — fully Open Code (source-available), no cloud lock-in.

## Inside steps 1 and 2: where a request becomes software

Of the eight stages above, **two carry the whole idea of the loop**: the moment a single request is broken into a buildable plan, and the moment that plan materialises into a working interface you can watch take shape. Everything else — memory recall, agent selection, test, deploy, record — exists to serve these two. If you read only one part of this page to understand how Fractera *actually builds*, read this one.

Across both steps the work stays **visible and steerable**, because it runs on real surfaces you can open, not hidden state: the `/architecture` page (the live map of every route), the `/development-steps` page (the work log), and **LightRAG** — the Company Memory that grounds every decision.

### Step 1 — Decomposition: one request becomes many development steps

When the enriched prompt reaches the first stage, Hermes does not start writing code — it runs a **decomposition task**. A single natural-language request is split into several intermediate **development steps** (the sub-steps of the work), each one small enough for a coding agent to pick up and finish.

#### From an enriched prompt to a decomposition task
The request arrives already grounded: Hermes has loaded its identity, the active project's context, the glossary and the completed-steps history from LightRAG. On that footing it answers one question — *what are the concrete sub-steps that turn this outcome into shipped code?* The result is a short, ordered list of development steps, not a single monolithic task.

#### The unit of work: a development step
Each sub-step is written as a **real file** — `DEVELOPMENT-STEPS/NEW-STEPS/<NN>-<slug>.md` — and appears under **New steps** on the `/development-steps` page. For every step the model drafts a **technical description**, and where it helps it embeds **code examples** or recalls a ready **UI pattern from memory** (the reusable `PATTERNS/` catalogue surfaced on the `/patterns` page, retrieved through LightRAG). Each step carries an importance — optional, mandatory or critical — and a to-do list an agent later executes.

#### When a step needs a page: the frozen template
If a sub-step requires a new screen, the workspace first creates an **empty stub page** — a *minimal, frozen architecture template*. Nothing is built yet; the route exists only as a placeholder so the rest of the plan can reference it.

##### The declared route — a README beside an empty page
On the `/architecture` map this is a **declared route**: a folder that has a `README.md` but no built `page.tsx` (shown with an orange label and a `req` badge). All the technical requirements for the page go into that `README.md`, sitting right next to where the page will live; for a page that already exists, the same requirements update its existing record instead. An agent reads that file to pick up the work, builds the page, and the node flips from **declared to live**.

##### Routing shape: parallel, intercepting, static or dynamic
The stub is not generic — its shape is declared up front in the route's `_meta.ts`: a **parallel** or **intercepting** route, **statically** prerendered or **dynamically** rendered. An intercepting route, for example, is how a request opens as a **modal dialog** (a shadcn/ui component) over the current page instead of a full navigation.

##### Usually one request, one route
As a rule, a single request resolves to **one route**. Only the less common cases — parallel or intercepting routing — spawn an extra page alongside the main one, such as that dialog. Keeping one request to one route is what keeps the plan easy to follow on the live map.

### Step 2 — Iterative build: sub-steps become a living interface

With the plan declared, the second stage **executes it**. The model takes each development step in turn and builds it — and because the workspace renders progress live, you watch the empty template fill with real functionality.

#### The agent works one step at a time
The chosen coding agent pulls the next sub-step, reads its `README.md` and to-do, and writes into the open `app/` layer. The frozen stub stops being a placeholder: the interface for that request grows piece by piece, step after step.

#### Watching it happen in real time
Keep a second monitor and open two tabs — the `/architecture` page and the `/development-steps` page. Both poll the filesystem and **highlight exactly what changed**: on the architecture map the affected route blinks and scrolls into view as it goes from declared to live; on the steps page the sub-step pulses as its tasks are picked up. You see *which* page is being built and *which* sub-step is in flight, as it happens.

#### A worked example: building a full content page
Some requests take many passes. Take building real content for a page — here the loop runs several iterations, and you can step in at every one.

##### Iteration 1 — research and a first structure
The model gathers what the page should say: it researches keywords, parses competitors, and sketches a preliminary structure. No final copy yet — just the shape of the work.

##### Iteration 2 — a to-do list on a frozen page
Back on step two, the frozen template now renders a **to-do list in its own interface** — the tasks it intends to take on next. The architecture tab highlights the update; the real page, still a blank sheet, shows only the outer layout wrapped around an **interactive to-do table in the centre of the screen**. This is your window in: you can pause the process, open the to-do with your own tools or notes, and describe what the page should become. Do nothing, and the model loops back to step one to re-plan.

##### Iteration 3 — per-section to-do lists
Next the model breaks the article into **sections**, and each section gets **its own development sub-step and its own to-do list**. Now the blank page shows not one list but a **separate to-do per section** — so you steer each one directly: *in this section, cover X; use this layout; embed that YouTube clip on topic Y*, and so on.

##### Final iterations — generation and proofreading
On the next pass the model **generates each section in full**, following the instructions, keywords and settings already set. How many iterations a job like this runs is itself defined by a **skill** the workspace pulls from its skill store. Watching in the browser, you now see the page **almost in its final form** — still carrying its to-do list, still open for you to override the remaining tasks. When every task is done, the last pass runs the **final proofread** (or whatever closing tasks the skill specifies).

#### Dynamic content: the SPA approach
While it is being built, the page renders as **dynamic content** — the single-page-application approach familiar from a classic React app — so you always see the closest possible preview of the current state. The closing move of this stage is to **transform that working draft into the final format** the next stages need for testing and the build.

### The cycle in four moves

Strip the example away and the engine underneath is always the same four moves:

1. **Decompose** the incoming request into as many sub-tasks as it needs.
2. **Build the tracking interface** — the to-do lists and the live tabs that show each sub-task progressing inside the main task.
3. **Run as many build-and-visualise cycles** as the work requires.
4. **Transform** the temporary working format into the finished result.

From here the loop hands off to testing and the build — the deploy stages described below, and out of scope for this block. To see the workspace all of this runs inside, read the [AI Workspace architecture](/ai-workspace-architect); for the full project reference, see the [project knowledge base](/mcp-info).

## Hermes — multi-agent AI orchestration

**Hermes** is the brain at the centre of the loop (`fractera-hermes`, dashboard on `:9119`). It is the only part that talks to *you*, and the part that decides *what happens next* at every turn of the cycle.

At each wake-up Hermes loads its **identity** from `SOUL.md` (who it is: the brain of a Fractera workspace, an orchestrator of software development) and the **project context** from the repo's `CLAUDE.md` / `AGENTS.md`. It then reads the current project state and the relevant history out of **LightRAG**, so it is grounded before it acts.

Hermes is intentionally **light**: it plans, it chooses, it dispatches, it records — but the heavy lifting of writing code is delegated to the coding agents. In one loop it can split a job across several agents, run them in parallel, collect the results, and decide the next step. You brief Hermes like a teammate; it coordinates the rest.

## AI coding agents: choosing the right one for the task

Five subscription coding agents run preconfigured on your server — **Claude Code, Codex, Gemini CLI, Qwen Code, and Kimi Code** — each driven through a bridge that exposes it to Hermes over MCP (ports `3210–3214`).

Before delegating, Hermes checks **readiness**: which agents are installed and actually signed in (a green bridge means the process is alive; being logged in to the subscription is a separate fact). From the ready agents it picks the **best fit** for the task — a fast generalist for iteration, a careful planner for sweeping multi-file changes, a large-context model for big reviews.

Crucially, the agents run on **your existing subscriptions**, not pay-per-token API keys — so the heavy AI work costs you nothing beyond the subscription you already have. Hermes can switch agents mid-task without losing the thread, because the shared memory keeps the context.

## LightRAG — Knowledge Graph RAG memory at the centre of the loop

On the diagram, **LightRAG** is the tall column on the right that every stage reads from and writes to — and that is exactly its role. It is the shared long-term memory of the whole workspace (`fractera-rag`, `:9621`), a **Knowledge Graph RAG** queried by Hermes and all five coding agents.

This shared memory is what makes the loop efficient. Instead of re-explaining the codebase on every request, each stage recalls exactly the relevant context: the project state, the glossary, the completed steps, past decisions. A task that takes ten back-and-forth messages in a vanilla chat often resolves in two or three here, because the model arrives already grounded — and that is where the **token savings** come from.

It does not learn on its own — it stores only what agents explicitly push, which keeps it curated. Activating it needs an inexpensive embedding/LLM key; without one it stays wired but silent.

## The instruction layer that steers every AI agent

The loop is steered by **real files on disk**, not hidden settings — the same files an agent reads as plain text, so you can inspect and shape them.

- **`SOUL.md`** — Hermes's identity and operating rules (who it is, how it works). Read at every wake-up.
- **`CLAUDE.md` / `AGENTS.md`** — the project-context files each coding agent reads in your repository. `AGENTS.md` is Codex's; `CLAUDE.md` is Claude Code's. They set how the agent behaves in *your* project.
- **`GLOSSARY.md`** — the workspace term map (approved abbreviations and preferred phrasings) so every agent reads your terms the same way.
- **The completed development steps** — the log of what was built and why, which an agent consults before starting so it does not repeat solved problems.

Because these are files, the loop is transparent and editable: change the instructions and the next pass of the loop follows them.

## From request to code: autonomous code generation

Inside the loop, a request becomes code in three visible moves.

- **Declare the task.** The agent turns your request into a concrete development task. You can optionally step in to steer or refine it before work begins — the human stays in the loop exactly as much as you want.
- **Generate the code.** The agent writes into the open `app/` layer — the public application that is *your* product. This is where automated code generation happens, grounded by everything recalled from memory.
- **Render it step by step.** As the agent works, the result renders progressively, so you watch the page or feature take shape in real time rather than waiting for a black-box result.

The split between the open `app/` layer (where agents build freely) and the guarded service layers (auth, data, memory, bridges) means the agents change *your* product without touching the infrastructure underneath.

## AI DevOps: automated build, deploy, and self-correction

Writing the code is not the end — the loop **tests and deploys** the change, then branches on the outcome. This is the decision point on the diagram.

- **On error**, the failure is not a dead end: it feeds back into the loop. The agent receives a new task shaped by what went wrong and iterates. The cycle self-corrects instead of stalling.
- **On success**, the change is live and the loop moves to record it.

Deployment is one motion — the open app layer is rebuilt and reloaded, and you see the result on the live URL. There is no separate CI pipeline to babysit and no hosting config to manage; the workspace owns the build.

## The record: development steps and the Product Loop deployments log

When a request finishes, the loop **writes down what happened** — and this recorded history is what lets the next request start smarter.

- **Completed development steps.** The step that drove the work is moved into the completed log with its date — a durable record of what was built and why, read by future agents.
- **The deployments tab (the Product Loop).** Every build is logged in a deployments table that deliberately goes beyond a normal cloud deploy list. Alongside the commit, status and duration, it records **which agent** did the work, **which model**, the **real token cost**, and a **quality rating** you can set. Over time this becomes a feedback record of agent-driven development — which agent and model produce the best results for your project, at what cost.

Both records are pushed back into LightRAG, closing the loop: the memory that grounded this request is now richer for the next one.

## Why the autonomous dev loop compounds

A pipeline runs once and forgets. The Fractera loop **compounds**, because every pass leaves the workspace smarter than it found it:

- **Memory grows.** Each request writes its decisions, code and outcomes back into LightRAG, so the next agent starts already knowing them.
- **History accumulates.** Completed steps and the deployments record build a real account of how the project was made — and which agents and models work best for it.
- **It is all yours, and open.** The whole loop runs on **your own VPS**, fully **Open Code (source-available)**: you can read every file, inspect every decision, and verify exactly what the agents do. No cloud lock-in, no black box.

The result is a development cycle where one natural-language request becomes shipped software — and the system that shipped it is a little more capable every time. Deploy the whole stack to your own server in about ten minutes, and start the loop.

To see the workspace this loop runs inside, read the [AI Workspace architecture](/ai-workspace-architect); for the full project reference, see the [project knowledge base](/mcp-info).

===

# The Next.js Aircraft Carrier — pre-built parallel routing

Reference page: https://www.fractera.ai/next-aircraft-carrier
Canonical diagram: ![Next.js parallel-routing layout — Header, Promo Screen, Left, Right, Center Header, Center, Center Footer and Footer slots with an active-slots checklist](https://www.fractera.ai/nextjs-parallel-routes.png)

## Preventing AI Context Window Inflation

Let us meet the objection directly: *"50,000 lines of code is overkill — and surely it just burns more AI tokens."* The opposite is true, and here is the mechanism.

The real cost driver in AI-assisted development is not the size of the codebase — it is **context window inflation**. An agent that scans the directory tree, reads hundreds of lines to find where to insert code, and rewrites half a file pays for all of that on every pass, and the bill compounds. This is the **cost-effective AI development** problem nobody priced in.

Fractera removes that work. Because roughly **99% of the architecture is already written and verified** — parallel routing, i18n, production SEO, database, auth — the agent never re-invents or re-reads the infrastructure. To ship a feature it processes a few lines of clean business logic, not the whole framework. The 50,000 lines are not a bill; they are **prepaid stability** — an armored shield for your token budget and the core of **AI code generation cost optimization**.

## What Parallel Routing Is — and Why the Next Generation of Apps Needs It

**Parallel routing** is a Next.js capability built so that, within a single URL — effectively a single screen — a person, an architect, or an AI model can combine a large number of dynamic parts called **slots**. Some are fixed in place; others appear on demand — as drawers sliding in from the left, right, top or bottom, or as modal windows flashing up in the centre. Most of this happens **without changing the main route, without a page reload, and without losing any content**.

Under the hood Next.js manages application memory and error handling so robustly that if one tab fails, the maximum damage is the loss of that single tab until it is reopened — the application keeps working. It is an exceptionally reliable model, and it is where the web is heading. Done right, this is also how you win **next js parallel routing SEO**: every slot is real, crawlable HTML.

## Next.js Parallel Routing & On-Demand ISR for Infinite Scale

An AI agent trained to create and activate parallel-routing slots gains the ability to model an interface at an almost limitless level. The Rubik's Cube analogy is even clearer here: instead of letting a project scatter global blocks of content and logic across unpredictable parts of the app, parallel routing **structures the core of the Next.js project and lays down the rails** that every future page deployment runs along.

Note the word *deployment* rather than *generation*. Backed by **on-demand ISR** (Incremental Static Regeneration), the framework regenerates thousands of pages without overloading the server or the AI — the foundation of genuinely **scalable web application architecture** and excellent **Next.js App Router performance** and Core Web Vitals.

## Deployment, Not Generation

Inside each section there are strictly regulated rules for creating content and design, described by the design system. That means the model simply **selects the section it needs and passes the required data into it**. For this, code generation is barely needed — it is a choice among available options, not authorship from scratch.

These are **immutable code patterns**: compiled, verified building blocks an AI agent configures but cannot accidentally break. You get the flexibility of custom assembly with the reliability of an enterprise backend.

## When Code Generation Kicks In — and Becomes a Reusable Widget

Code generation switches on only at one moment: when the architect decides to add a new section or a new technical, tooling solution. At that point generation runs once and turns the result into a **reusable widget** the application will use again and again — with no further generation.

So generation is the exception, not the loop. The default path is selection and configuration; authorship happens once and is then frozen into a reusable part.

## The Fractera Widget Marketplace

Architects on Fractera will not only create their own widgets but also find them in the **Fractera marketplace** (coming soon). There, developers can sell their own widget — anything from an AI chat to something far more involved, such as a calculator for the made-to-order price of a fitted kitchen. Architects place these widgets in the marketplace and then attach them to one of their routes.

This is also where **MCP server development layout** comes in: the AI manages structure and layout — adding, moving, and wiring widgets — through the Model Context Protocol, like turning a Rubik's Cube.

## Why There Are So Few Parallel-Routing Examples

There is a simple reason the web has so few real parallel-routing implementations: the technology is **too complex for today's AI** and demands deep, reliable reference examples. In understanding and in building it, developers run into the fact that parallel routing simultaneously requires a deep grasp of how content is stored, delivered, reused, and refreshed.

In production this matters enormously. A small mistake can flip a project from **static generation into dynamic generation**, which triggers an instant, avalanche-like spike in server load and an uncontrolled volume of database calls — inflating either your cloud-database bill or your own resource usage.

## How Fractera Solved It

With Fractera this does not happen. Before you ever received this offer, Fractera spent a year testing and refining the interaction between parallel-routing slots — so that you receive an application you do not need to *develop*, only to **fill with data and parameters**.

We also taught the AI model, through several dedicated **MCP connectors**, to combine all the necessary slots on a single URL — and to change them when needed — in answer to any question from you or your visitor. It is an extraordinary bridge to the future that Fractera hopes will permanently change how applications are built. This is what makes it real **high-traffic web infrastructure, self-hosted** on hardware you control.

## A Self-Hosted Alternative to Vercel for High-Traffic Web Infrastructure

Because the whole stack runs on your own VPS, Fractera is a **self-hosted alternative to Vercel**: the same one-click deploy speed, none of the per-request pricing that escalates under real-world traffic. Your database, file storage, auth, and the entire parallel-routing framework live on one server, billed once through your VPS provider.

For high-traffic projects this is the difference between predictable infrastructure cost and a bill that scales with every visitor.

## Why 50,000+ Lines — and What You Can Build With Them

This is the largest Next.js starter we know of — and the size is the point. 50,000 lines of code so your offer generates new pages in seconds **without spending tokens**; so you can build dozens, hundreds, or a thousand applications; so you can run many projects on one server — for yourself, for work, for family — to manage business processes and staff, whatever you wish, all in one interactive screen.

Multi-language routing is already wired into those 50,000 lines and works out of the box, so **Next.js multi-language routing** is a solved, routine problem rather than a project of its own. And the stronger AI models become, the more extraordinary the applications you will build — bringing the Tony Stark and Jarvis era a little closer each year.

## What's Inside — and What's Coming

This page is the tip of the iceberg. It will grow into a detailed catalogue — more than a hundred screenshots, each describing one feature, plugin, or widget of the parallel-routing system.

For now, see the live system this runs inside on the [AI Workspace architecture](/ai-workspace-architect) page, read how a request becomes shipped software on the [AI Development Loop](/ai-development-loop), or understand the cost model on the [Token Economics](/token-economics) page. When you are ready, deploy the whole stack to your own VPS in about ten minutes.

===

# Token economics — how Fractera saves tokens

Reference page: https://www.fractera.ai/token-economics

## Preventing AI Context Window Inflation: Why 50,000 Lines of Code Is a Shield, Not a Bill

When a developer hears "a 50,000-line template that AI agents work inside", the reflex is fear: a token-devouring monster that burns API limits in three messages. With Fractera the effect is the exact opposite.

The real cost driver in AI-assisted development is not the size of the codebase — it is **context window inflation**. A traditional agent sends files back and forth, scanning the directory tree and re-reading layout scripts to find where to insert code; every pass expands the prompt history exponentially, and you pay for all of it again and again. That is why **reducing LLM API costs** — and the explicit question of **how to reduce Claude Code token spend** — is what every team eventually confronts.

Fractera removes that work with **context window optimization strategies** baked into the architecture. Because roughly **99% of the application — parallel routing, multi-language i18n, production SEO, database structures, auth sessions — is already written and verified**, the immutable 50,000-line skeleton stops the agent from recursively processing layout scripts at all. To build a feature it processes a few lines of clean business logic, not the whole framework. The 50,000 lines are prepaid, monumental stability — an armored shield for your wallet.

## The Rubik's Cube: Finite Faces, Near-Infinite Combinations

Fractera treats web architecture like a Rubik's Cube. The application layer is a strictly optimized, deterministic set of pre-built facets — parallel routing slots, global design tokens, synchronized layout structures. You get a complete project skeleton that already contains almost every idea you could need later.

Instead of *creating* new material, the system *combines* what already exists: a strictly limited set of faces on one side, a near-infinite set of combinations on the other. These are **deterministic states** of a **pre-built application framework** — so the AI acts as a selector switch, not an unconstrained code author. This is what **deterministic AI code generation** looks like: nothing is generated from scratch when it can be switched on from the skeleton, and switching something on costs a fraction of the tokens that generating it would.

## Generation by Hermes, Not Code-Writing Agents

Standard "vibe coding" calls a heavy coding agent — Claude Code, Codex — for every change, and pays for the full generation loop each time. Fractera shifts that work to **Hermes**, which does not really write code: it selects the right combination of existing facets.

It is the difference between carving a new piece and turning a Rubik's Cube — a simple, mechanical move from A to B against a fixed set of standards. Hermes runs on inexpensive models that cost twenty to fifty times less than frontier coding models, reads a spec, routes the move, and clears its context before the next call. You pay frontier prices only for genuinely frontier work.

See the orchestration in full on the [AI Development Loop](/ai-development-loop) page.

## The MCP Server Architecture: Updating Layouts with Zero Token Overhead

Design is one of the most expensive stages of development. The Fractera Design System removes it from the code-generation budget entirely. Want a new font, a video background, a reused section? You do not run an agent — you apply a rule.

This is **MCP server architecture for web layouts** in practice. A short JSON execution model sent through the Model Context Protocol updates a design token, and **Next.js on-demand ISR** path revalidation propagates the change to **one page, several pages, or all of them at once**. A single ~50ms instruction rewrites the structural environment across an entire array of routes — without executing a full generative code cycle. It is like running one sequence of moves that builds all six sides of the cube simultaneously: bulletproof structural stability across thousands of pages, with token consumption driven to nearly zero.

## Achieving True AI Token Cost Optimization at Infinite Scale

Put the mechanisms together and the result is horizontal scale without the bill. Tens, hundreds, thousands of pages — bound together by shared logic and functionality, all responding to atomic MCP function calls rather than heavy code-generation loops.

A task that takes ten to twenty back-and-forth messages in a vanilla AI chat typically resolves in two or three focused exchanges inside Fractera. You get enterprise-grade scalability with a token-billing overhead driven toward absolute zero — because the heavy framework was engineered once, so your AI agent does not have to.

See the workspace this runs inside on the [AI Workspace architecture](/ai-workspace-architect) page, or the full project reference in the [knowledge base](/mcp-info).

## Prefer the Classic Workflow? One Click

None of this locks you in. If a project demands a standard workflow — a small, fully custom application — you can switch to the classic Next.js code-generation mode from the app settings. It is exactly one click: disable the parallel routing matrix and build with the freedom of a clean sheet. Fractera adapts to your development philosophy instead of forcing one on you.

===

# The interactive AI consultant — one button on every page

Reference page (documentation): https://www.fractera.ai/en/documentation/one-button-workspace-ai-consultant

A deployed Fractera workspace ships a floating "AI consultant" button in the
bottom-right corner of every public page (mounted globally, not tied to any
optional layout feature). Clicking it opens a small chat where any visitor can
ask questions OR request actions in natural language; the agent answers and may
return clickable action buttons.

## The core boundary: brain on the server, action in the browser
A server-side tool can know what is possible, read config, converse and PROPOSE
an action, but it cannot reach into a live browser tab. So per-visitor view
actions (language, theme, width, navigation) are executed CLIENT-side by the
chat widget, while shared, workspace-wide changes stay server-side. This is why
"switch me to French" actually switches the page instantly, with no reload.

## Access tiers (public / user / owner), resolved server-side
Tiers nest: public is a guest (own view only), user is a signed-in end-user
(their own data, scoped to their identity), owner is the administrator (shared
config, global defaults, growing the project). The tier is decided on the
server from the session, never trusted from the browser.

## Client actions: server proposes, browser executes
Per-visitor tools (navigate / set locale / set theme / set width) return a small
deferred envelope { "__client_action__": true, tool, args } instead of acting.
The chat renders it as a button; clicking runs an ALLOWLISTED browser handler
after validating arguments (e.g. the language must be one the site is configured
for). The browser never executes an arbitrary instruction from the stream.

## Safe by construction
The public consultant runs as its OWN sandboxed agent process whose toolset is a
strict subset — owner tools are simply absent, so an anonymous visitor cannot
reach them. A runtime guard caps the process at tier "user" for defense in depth,
it binds to loopback (visitors talk only to the /api/consultant endpoint, which
holds the agent token server-side), and it uses its own API key so anonymous
traffic never drains the owner's quota.

## Sign-in escalation
If a request needs the visitor's identity (their own data) or a higher role, the
agent itself picks the right message — "sign in to access your personal
information" vs "this function isn't registered for your role" — and offers a
sign-in button that returns the visitor to where they were. Signing in just
establishes the real role/identity; an administrator is not blocked.

## Growing the toolset
New tools/skills are authored at <your-domain>/ai-draft-settings: describe a new
MCP server, skill or instruction in free form and pick who it is for (guest /
signed-in user / owner). A specialized agent turns the draft into a real tool.
The workspace also ships with source code, a terminal and local development, so
it can be extended without limit. The consultant grows as the toolset grows:
one small button fronting an evolving set of MCP tools, an orchestrator (Hermes)
and global graph memory (LightRAG).

===

# Authentication, roles & providers

Reference page (documentation): https://www.fractera.ai/en/documentation/authentication-roles-and-providers

Every deployed Fractera workspace ships a complete, production-shaped sign-in
system already wired in — you do not assemble it, you turn parts of it on. It is
built on NextAuth (Auth.js) running as a dedicated authentication service on its
own port, with JWT sessions carried in a signed cookie shared across the project's
subdomains. Under the hood it uses a database adapter together with the providers
so that modern sign-ins persist correctly.

## One account, many providers — no duplicates
You start with email + password. The moment you paste a provider's credentials in
the secure admin settings, its sign-in button appears automatically; remove the
credentials and it disappears — nothing to redeploy. Two providers are pre-wired:
Google OAuth and a magic-link (email) flow. A single identity can sign in through
several providers and remain ONE account: the system links each new provider to
the existing user (matched by email) instead of creating a duplicate.

## The required tables
Four tables back it: users (one row per person — email, display name, the role
list, sign-in method, verification and active/blocked status, and the user's image
such as a Google avatar, plus locale/timezone and a bio); accounts (one row per
external provider linked to a user — the link that enables one-account-many-
providers); sessions (present for completeness; sessions actually live in the
cookie); and verification_tokens (the single-use tokens behind magic-link sign-in).
The database activates on first use and self-migrates.

## Roles
Roles are stored as a LIST of strings, so one user can hold several at once. Three
are access tiers the platform enforces — guest, user, architect (the owner / top
tier). The rest are a ready business vocabulary: buyer, vip_user, subscriber_lite,
subscriber_standard, subscriber_max, manager, senior_manager, support_manager,
delivery_manager, finance, content_editor, admin. The very first person to sign in
becomes the architect automatically (through any provider), and the architect
cannot remove their own architect rights — only another architect can change
someone else's roles. From your own application layer you can read users and grant
or revoke roles, driving the permission model from your product code.

## Coverage and modes
The same identity covers every surface — the public site, the admin platform, each
coding agent, the LightRAG vector memory, the Hermes brain and the built-in web
chat — directly or through the reverse proxy. There are two modes: an open
onboarding mode on a bare IP, and a strict, role-gated secure mode once you attach
a custom domain with HTTPS (which also locks the host firewall to web ports only).

## Starting simple, and growing safely
The default email+password start has one honest limit: there is no built-in
lost-password recovery — fine for an early stage, and exactly why adding a
passwordless provider (Google or magic-link) early is recommended. Auth.js ships
80+ built-in providers (Google, GitHub, Apple, Microsoft Entra ID, Auth0, Okta,
Keycloak, Discord, Facebook, LinkedIn, Twitch, GitLab, Slack, Spotify, Reddit,
Yandex, VK, Kakao, Naver, LINE, Notion, Salesforce, Zoom and many more) and the
four-table schema scales to all of them without structural change. Rule of thumb:
add the providers you want early, while the codebase is small. If your app is
already large and in production with real customers, do NOT experiment with auth
on it — deploy a separate server, test new providers there, and have an AI agent
study how auth is wired in your specific project first; a botched change can leave
the app running but locked for sign-in.

===

# AI Draft Settings — where a workspace learns new skills

Reference page (news): https://www.fractera.ai/en/news/ai-draft-settings-evolutionary-pipeline
Canonical diagram: ![Fractera AI Draft Settings flow — drafts (a terminal and to-dos) become Next Step entries on the Development Steps page, and an AI generation pass writes them into each agent's files: Claude Code, Codex, Gemini CLI, Qwen Code, Kimi Code and Hermes](https://www.fractera.ai/news/fractera-ai-draft-settings/fractera-ai-draft-settings.jpg)

Every Next.js-based Fractera starter ships an AI Draft Settings page: the control
room for the AI side of a project. A normal admin panel manages business data; this
page manages what the AI agents know and may do — each agent's instruction files, its
skills, and the MCP tools it can call. It is the first link in a planned seven-stage
pipeline for evolving a workspace's own intelligence.

## Two ways to use it — by hand or by agent
In the interface, a dual-panel layout lists the six agents (Claude Code, Codex,
Gemini CLI, Qwen Code, Kimi Code, Hermes) on the left; selecting one shows its real
instructions, skills and registered tools on the right, read-only, exactly as they
sit on disk. A draft layer on top is the scratchpad: you write the change you want
and save it as a pending draft. Agents can do the same programmatically — any agent
can call the built-in HTTP skill "propose-new-agent-skill-or-mcp"; Hermes reaches the
same place through the owner_draft_create_record tool on the ai-draft-bridge server
(port 3221). Every agent carries its own copy of the skill, so it works even if the
project runs a single agent and nothing else — no shared brain, no single point of
failure.

## From a wish to a working skill (and why it is never automatic)
Writing a wish is NOT the technical work — it is a brief kept for later, in free form
or structured (a small terminal, or a to-do-style tool). Each draft marks its parent
container with an orange "req" badge. When you or an agent send the draft into work,
the AI clears the note and creates a "Next Step" entry on the Development Steps page,
where the real build is scheduled and run at the right time by an agent or a person.
Turning a draft into code is deliberately never automatic on creation: doing so could
crowd the agent's active context window, lower code quality in the main process, or
burn token limits earlier than planned. The lifecycle is three moves: create a draft,
move it into the queue (it becomes a Next Step), then turn it into the real skill,
instruction or connector and ship it.

## From semi-automatic today to fully automatic
Today the loop is semi-automatic and fast: describe it, send it, an agent builds and
ships it, often within the same session. As the remaining pipeline stages arrive
(automatic testing, regression detection, visual diffs, usage data, a self-tuning
feedback loop), each needs less human help, until the full loop runs end to end with
nobody pressing a button. The page ships with every Next.js-based starter today;
dedicated Agentic Engineering Infrastructure transports bring the same depth (a built-in database,
authentication, file storage, the full five-agent stack and one MCP architecture) to
other frameworks — React, Vue, Angular, SvelteKit, Nuxt, Astro, Remix, Django, Flask,
FastAPI, Laravel, Rails, Phoenix, NestJS and more — announced in News as they go live.

===

# Multilingual content architecture — publish in many languages by construction

Reference page (news): https://www.fractera.ai/en/news/multilingual-content-architecture
Raw living standard (download): https://www.fractera.ai/docs/multilingual-content.md

Fractera rebuilt how its own site — and every starter it ships — stores and translates
content (news, blog, documentation, any page copy) so it scales to dozens of languages
and thousands of pages without rewriting what exists and without hardcoded language
branches in code.

## Document = folder
Each content item is its own folder: a non-translatable meta file (slug, date, tags,
images), a FULL base-language file (en) that is required, and a PARTIAL override file per
extra language carrying only what differs. A new language = a new file dropped into the
folder; existing files are never touched. A new document = a new folder plus one line in
an explicit static-import registry (the bundler needs resolvable paths, not an fs scan).

## Translate per key, not all-or-nothing
The resolver and the i18n shell return a language as a recursive deep-merge of the base
with the override: a missing key falls back to English per key (not the whole object).
Arrays are replaced wholesale, never merged element-wise. The result: the 81st language
can ship with a single translated field and render correctly, English filling every gap.
Priority languages get a full translation; the long tail lives in base-fallback mode.

## No language branching in page code
Forbidden: language === 'xx' ? A : B and isXx = lang === 'xx' in the page layer. Instead:
a UI label is a key in the translation dictionary (a link-in-the-middle string is split
into Pre/Link/Post); a different component per language is chosen by a discriminator field
in the data plus a component registry; dates are passed straight to toLocaleDateString(lang)
(a bare ISO-639-1 code is a valid BCP-47 tag) — which also fixed a real bug where a Russian
page showed its date in English month names. A lint rule guards the line so the hack cannot
creep back as the site and its contributors (AI agents included) grow.

## SEO/GEO and static generation
Each language gets its own URL with hreflang and its own SEO surface (title, description,
keywords) written from its own angle, not a word-for-word copy, so engines see distinct
pages. AI discovery is a first-class channel: every update is reflected in machine-readable
indexes (llms.txt, llms-full.txt) and the sitemap. At small volume, full static generation
across existing languages; when languages x documents inflate the build, ISR without losing
static (dynamicParams = true for languages outside the list — the resolver already gives
base-fallback — plus revalidate = N).

## The create-multilingual-content-entry skill
The pattern ships as part of the starter's standard architecture, carried by a self-
sufficient agent skill, create-multilingual-content-entry: any agent (even a single one,
with no Hermes and no memory) can create a multilingual document the right way — the folder,
the full base, partial overrides, the registry line, and a check that no language hacks
slipped in. Especially relevant in Europe, where a project is rarely born in one language.

## Shipped in the starter
The starter ships this routing built in: it deploys bilingual by default (English + Spanish),
so the language switcher button is visible out of the box; leave a single language in the
NEXT_PUBLIC_SUPPORTED_LANGUAGES env and the button disappears and pages serve from the root
with no prefix. Service pages (Architecture, AI Core, …) always stay at the root, never
language-prefixed. Two self-sufficient agent skills ship with it — create-multilingual-content-entry
and install-language-switcher-dropdown (re-installs the language dropdown after you delete it) —
and both are readable in the AI Core page of the deployed workspace.

===

# Multilingual login & registration forms — the sign-in speaks the visitor's language

Reference page (news): https://www.fractera.ai/en/news/multilingual-auth-forms
Raw doc (download): https://www.fractera.ai/docs/multilingual-auth-forms.md

The login and registration forms shipped in every starter (rendered by the auth service,
the process on port 3001) are now localized into all 82 catalog languages. After you deploy,
you and your users see the form in your own language automatically — no setup.

## Automatic, by browser language
The form is a client component: on mount it reads the visitor's browser language
(navigator.language, reduced to its primary subtag, e.g. pt-BR to pt) and selects the matching
strings from a build-time dictionary (services/auth/lib/i18n/auth-strings.ts). Only the WORDS
are localized — the email/password input fields are unchanged. English is the fallback when a
browser asks for a language that is not present.

## Static, zero extra server load
Every language is compiled into the bundle ahead of time, so the /login and /register pages are
served as static HTML. There is no per-visitor request to detect a language and no runtime
generation — keeping server load minimal. The auth service is built once at full deploy
(bootstrap build_auth); the routine app deploy loop does not rebuild it.

## Trimming languages (planned)
By default all 82 languages are baked in, because at deploy time the admin's own language is
unknown — every language must be available for the first sign-up. A planned follow-up lets you
list the languages to keep in an environment variable; a build-time generator (the Turbopack-safe
parser-fs pattern) then emits a dictionary with only those languages plus English. Until it ships,
an agent can do the same today by editing auth-strings.ts directly (remove unwanted entries, keep
en) and rebuilding fractera-auth. The how-to doc loads into the workspace LightRAG so the Hermes
agent can act on it.

===

# Static-first rendering — the economics of a near-zero server bill

Reference page (documentation): https://www.fractera.ai/en/documentation/static-first-rendering-economics
Raw living standard (download): https://www.fractera.ai/docs/static-first-rendering.md

Fractera enforces static-first rendering with unusual rigor because the cost it
optimizes for is the business's monthly server bill — compute and database load — not
the developer's token budget. Tokens are spent once, while building; compute is spent
forever, on every visitor. A project that renders dynamically by default scales its
server cost linearly with traffic, which is exactly where small businesses fail to close
their unit economics.

## The canon
Creating a dynamic page is forbidden unless it is absolutely necessary, and only after the
architect's double confirmation — better to build nothing than to make a page dynamic where
it could have been static. The foundation is no-JavaScript: the App Router ships complete
server HTML, so a static page works with JavaScript disabled. The real no-JS killer is
client-side routing or a client component that owns a route, not server rendering itself.

## Five ways content reaches a page (cheapest to most expensive per visitor)
1. Static (SSG): data fixed at build; appears on redeploy; zero DB per visit; no JS; lowest cost.
2. Time-based ISR (revalidate = N): the default. Lazy and traffic-bound — a page re-renders only when requested after its N-second window, and only that page; with no traffic the server sleeps. Self-correcting, needs no wiring.
3. On-demand ISR (revalidate = false + revalidateTag on write): optional refinement for a page that needs instant, zero-delay freshness — purge it from the write handler. Requires discipline (call it on every write) or the page freezes.
4. Dynamic SSR (force-dynamic): rendered fresh every request, a DB hit every time; high cost; architect-only.
5. Client fetch: a client island queries the API on every view; always live but needs JS and hits the DB per view; fine for private panels, poor for public lists.

## How time-based ISR behaves (the default)
A page with revalidate = N is generated once and served from cache. While nobody visits, the server
sleeps. When a visitor arrives after the window, they get the cached page instantly and that one page
is regenerated in the background; the next visitor sees the fresh version. Only requested pages
regenerate — there is no clock rebuilding the whole site, and unvisited pages cost nothing. The only
redundant cost is a constantly-visited page that rarely changes: it rebuilds once per window even when
unchanged, a small traffic-bounded price. For zero-delay freshness on a specific page, opt into
on-demand revalidation (revalidate = false + revalidateTag on the write handler).

## Why the architect layer stays dynamic
The service cockpit (Architecture, AI Core, Development Steps, …) runs dynamically on purpose. A
single architect, on pages only they can open, cannot create harmful load; that compute is bounded
and necessary. The rule protects the public surface, where many visitors — careless, curious or
malicious — turn every dynamic render into multiplied cost. Dynamic rendering is allowed exactly
where it cannot hurt the bill: behind architect-only access.

## PPR is left to the developer
Partial Prerendering (a static shell with a dynamic hole) is a precise tool for a developer who
knows which fragment must be live and wants to balance freshness against server cost by hand.
Fractera does not automate it — that judgment is the developer's.

===

# The content engine — self-contained pages, auto-discovery, token economy

Reference page (documentation): https://www.fractera.ai/en/documentation/content-engine-architecture
Raw engineering standard (download): https://www.fractera.ai/docs/content-engine-en.md

Every content surface on the site — news, blog, documentation, the deployment pages — is built
from one shape. A content surface always does three jobs: hold data, render itself as a page, and
appear in a list. The naive way couples those to a central spine — one global registry, one dynamic
[slug] route, one shared "god" types file — and the spine becomes the bottleneck every new item
touches and every agent must load. The engine removes the spine. The rule is one sentence:
everything a page needs lives inside its own folder; everything shared lives once in the engine;
nothing in between.

## Every page is a folder (co-location)
A tab (a collection like the blog) is a folder with a thin router on top and post folders below.
Three service folders carry a strict split — _components is the view, _lib is the functions and
type contracts, _data is the data (including the localized UI strings) — and one generated file is
the auto-built list. Each post repeats the same shape: a thin page.tsx, a _components composition,
and a _data folder (meta.ts + en.ts + an optional <lang>.ts override + index.ts). Add a page by
adding a folder; delete it by deleting the folder, with zero orphans left behind. The shared engine
— the typed-block catalog, the per-key language resolver, the page factories and the one page
template — lives once, outside the tabs, reused by every one of them, never copied in.

## Why it saves tokens (the point)
The cost of an AI coding agent is dominated by how much it must read into context to act safely.
Co-location bounds that: editing one page loads one folder; there is no registry to read or
maintain (discovery happens at build time from the filesystem); the neutral block catalog removes
duplicate per-tab type definitions; the strict _lib/_data/_components split makes the right file
findable without exploration; and deleting is one folder with no orphan hunt. A registry design
pulls 3–5 files into context per edit plus greps to find them; here a page edit touches 1–2 files
in a known folder and a new page touches zero existing files. The savings compound with every page
and every agent.

## A design system you steer by structure
Content is authored as typed blocks (paragraph, heading, quote, list, figure, callout, founder
note, download card, container layouts). Each block kind has exactly one renderer, living once in
the shared catalog — so changing how a block looks in that one place restyles every page that uses
it at once, even across hundreds of pages. Presentation is managed by structure, in one place, and
propagates everywhere. That dynamically-managed design system is the second payoff of the same
architecture that saves the tokens. The document is bilingual (EN/RU).

===

# App Config automation — the MCP connector for managing project configuration

Reference page (documentation): https://www.fractera.ai/en/documentation/app-config-mcp-connector
Raw living standard (download): https://www.fractera.ai/docs/app-config-automation.md

A deployed app carries owner-editable settings that brand it and control how it appears
to visitors, search engines and PWA installs: name, description, canonical URL, SEO,
OpenGraph, PWA/theme, author, social profiles, JSON-LD, local business — and the language
set. The automated MCP connector for managing project configuration lets any of the six AI
agents read and change these by plain request, instead of clicking the admin panel.

The settings live in a plain JSON file on disk (app/APP-CONFIG/app-config.json), deep-merged
over the code defaults on every render. A file is chosen over a database (opaque to agents,
needs a query layer) and over env vars (flat, and NEXT_PUBLIC_* bakes into the build so it
would need a rebuild): the file is transparent, holds nested structure, and applies without a
rebuild. The distinction that matters is substrate vs write path — the file is the substrate,
but every write goes through a validated setter (the app-settings-bridge MCP, port 3218),
never raw hand-editing: it validates against a field catalog, writes atomically (temp file +
rename), and triggers on-demand revalidation so the change shows on the next page load while
the public pages stay static. Languages are the one build-time exception (they feed static
page generation), so changing them needs a rebuild and the agent says so.

The capability is duplicated into all six agents (Claude, Codex, Gemini, Qwen, Kimi, Hermes)
as both a skill (manage-app-settings) and the MCP connector, so a project running a single
agent with no orchestrator still has it. The same change runs directly on one coding agent or
through the Hermes orchestrator; the write mechanics are identical, Hermes only adds multi-step
orchestration. Access is constrained in depth: writing configuration is architect-only and
checked at every layer; the connector binds to localhost and is never exposed to the internet;
every call carries a per-deploy Bearer secret; and a mutating tool confirms the change before
writing. The document is English (TechArticle), written for a hybrid human + AI reader.

===

# Build-time environment variables & production redeploy — the bake contract

Reference page (documentation): https://www.fractera.ai/en/documentation/build-time-env-and-redeploy
Raw living standard (download): https://www.fractera.ai/docs/build-time-env-and-redeploy.md

A deployed app reads configuration two ways. Runtime values are read fresh on every
request. Build-time values are frozen into the app when it is built: every NEXT_PUBLIC_*
is inlined into the browser bundle, and anything read while pages are generated (the
language set, a Stripe publishable key, a feature flag, analytics IDs) is captured at
next build. Build-time values therefore change only by a rebuild — and the rebuild must
read the app slot's own .env.local. If it reads the wrong file, the saved value is baked
as missing while the build still reports success: a silent failure.

This was a whole class of bug, first seen as the language switcher disappearing after a
language was added — the same mechanism would have silently dropped Stripe keys, custom
API URLs or feature flags. Root cause: the workspace has two Next apps (the Admin cockpit
and the App slot); when the owner changes a setting, the Admin process spawns the slot
build and hands down its whole environment. Next's env loader sets a cross-process marker
(__NEXT_PROCESSED_ENV) on first run and then refuses to re-read .env files; the child
build inherited that marker and skipped loading the slot's own .env.local entirely, so
every declared value came back empty. A fresh wipe+bootstrap builds from a clean shell and
was fine on day one — the trap only bit on the owner's later change-a-setting path.

The fix is the slot-scoped bake contract: the slot's own .env.local is authoritative for
every key it declares, on every redeploy. The spawned build is given a clean, slot-scoped
environment — drop the marker so the loader reads the slot file fresh, drop every key the
slot declares so no inherited copy shadows it, keep everything else (PATH, HOME,
externally-provisioned vars). General by construction: languages, Stripe keys and product
ids, custom DB/API URLs, analytics and feature flags all behave the same. When a feature
needs a build-time variable: write it through the proper setter (never raw), trigger a
rebuild (a restart re-reads an already-built bundle and will not help), state the rebuild
cost honestly, and never reach for force-dynamic (build-time changes by rebuild; instant
text updates use on-demand revalidation — a different mechanism). The document is bilingual (EN/RU).

===

# Safe static generation: App Config by an AI agent and in the settings

Reference page (news): https://www.fractera.ai/en/news/static-safe-app-config-by-ai
Documentation: https://www.fractera.ai/en/documentation/app-config-mcp-connector
Raw standard (download): https://www.fractera.ai/docs/app-config-automation.md

Every deployed Fractera app ships an App Settings screen (in the Admin area) that manages
everything the app says about itself — branding, SEO, OpenGraph, PWA, author, social profiles,
structured data (JSON-LD), the language set, and images — in one place. A change applies on the
next page load with no rebuild, while the pages stay static (the language set is the build-time
exception). The same settings can be changed without the panel by simply asking any of the six AI
agents in plain words (the App Config MCP connector, :3218); a project with a single lone agent
still has the full capability.

## Why this matters: the dynamic-rendering trap
Metadata is usually left for last, and that is when the expensive mistake happens. If a shared,
top-level layout reads per-request data (calling headers() or cookies() in the root layout),
Next.js renders EVERYTHING beneath it per request — the whole site silently leaves the cheap
static path and rebuilds on every visit, including every bot. Under a traffic spike that is how
projects run up eye-watering hosting bills (the best-documented case, the art app Cara, hit
roughly $96k on its serverless host over one viral weekend). An AI agent is especially prone to
adding that call because it is often the easiest path. Fractera guards the app skeleton — routing,
generateMetadata, language handling — so an agent cannot flip the site dynamic, and settings apply
through revalidation, never by forcing dynamic rendering.

## The full field set
Brand & identity (name, short name, description, site URL, support email, chat brand); App icons &
PWA (theme/background colors, display, orientation, start URL, scope, light/dark browser-bar
colors); Author (name, email, URL, job title, bio, Twitter/LinkedIn/Facebook); Social profiles
(Twitter, GitHub, LinkedIn, Facebook — Organization sameAs); SEO (indexing, title template, robots
index/follow, keywords, canonical base, sitemap URL, Google/Yandex verification); OpenGraph (type,
site name, locale, image width/height); Analytics (enable GA, GA measurement ID); Structured data
(WebSite, Organization, LocalBusiness); Local business / address (street, city, country, postal
code, phone, latitude, longitude, opening hours). Images are uploaded via the panel and come in
light/dark pairs (home illustration, loading, chatbot, author photo, and custom 404/500 error
pages) — the site shows the right one for the visitor's theme automatically.

===

# Fractera moves to Open Code — a source-available license

Reference page (news): https://www.fractera.ai/en/news/open-code-license-agentic-engineering
Raw doc (download): https://www.fractera.ai/docs/open-code-license.md

Fractera is moving its core (the Agent-Engineering-Infrastructure repository) from the MIT
license to Open Code — the PolyForm Small Business license. The principle: you may copy, modify
and use the software commercially for free, with one exception — large corporations. The cut is by
company size: free for individuals and small businesses (fewer than 100 people AND under 1,000,000
USD annual revenue); companies above that threshold need a separate commercial license
(admin@fractera.ai). The restriction is permanent and the code stays fully public to read, audit,
fork and self-host.

## Open Code is source-available, not OSI "open source"
The Open Source Definition forbids discriminating against any person, group or field of use.
Because Open Code restricts large corporations, it is — by that strict definition — not open
source; it is source-available. Fractera uses the accurate term "Open Code" rather than borrow a
label it no longer fits. The ready-made starters (e.g. fractera-next-starter) remain MIT, so the
funnel for forking and building stays wide; only the core infrastructure moves to Open Code. The
L1 Easy Starter service stays closed (never published).

## Why now
A permissive license lets a large, well-funded company take the whole project, rebrand it and
resell it at scale without giving anything back. Ahead of revealing the technology behind
self-replicating MCP coding agents — which pushes development speed up by several orders of
magnitude — Fractera draws a clear commercial boundary so the largest players license commercial
use, while independent builders and small teams keep every freedom they had under MIT.

===

# Frozen archetypes — add a whole page group without code generation

Reference page (news): https://www.fractera.ai/en/news/frozen-archetypes-page-groups-without-code
Raw doc (download): https://www.fractera.ai/docs/frozen-template-constructor.md

This was the first prototype of "add a whole page group without code"; it has since matured into the
Frozen Template Constructor (see the next story). Adding a page group (a news section, a blog, a
documentation section) used to mean an AI coding agent writing about thirty files by hand — slow,
token-heavy, and prone to drifting from the standard. A frozen archetype replaced that with one
call. It is a "project in a box, frozen": an inert tree of template files with no fixed records,
where the specifics (which group, which languages, the label, how many examples) are parameters, not
content. An agent composes it into the site with those parameters.

## Composition is file copy, not code generation
Composition is deliberately dumb. The agent copies the vetted template files into the project and
fills in the blanks: it installs the shared content engine only if the slot lacks it (idempotent),
creates the section plus a couple of placeholder posts (Lorem body, placeholder image, but the full
ideal page structure — SEO metadata, breadcrumbs, table of contents, FAQ), and translates the single
section label into each configured language. No model writes code, so any model — the built-in brain
or any of the coding agents — produces an identical result in seconds, and the pages are static and
work with JavaScript off.

## The closed store and the two layers
The frozen brick lives in a closed store on the user's own server (the data service), served
read-only. It has two layers: an engine layer (the shared content engine, installed only when the
slot has none — it belongs to no single tab) and a tab layer (the parameterized section itself,
which refuses to overwrite an existing tab). The engine is distilled from the platform's mature
content engine and decoupled from anything project-specific, with brand and domain read from
environment variables, so it is portable to any starter.

## Honest refusal — match a real capability or decline
One frozen brick does not serve everything. It declares what it fits (news, blog, documentation,
announcements, changelog, guides) and what it does not serve (a cart/checkout, a graded course with
tests, an interactive app screen). The agent consults that declaration instead of guessing; asked
for something outside it, the agent says so honestly and offers to harvest a new brick — it will not
force a bad fit or invent fragile code. The current, fuller mechanism — the composer, its basis and
the matching rules — is the Frozen Template Constructor (next story).

===

# The Frozen Template Constructor — whole structures, composed not generated

Reference page (news): https://www.fractera.ai/en/news/frozen-template-constructor-compose-structures
Raw strategy (download): https://www.fractera.ai/docs/frozen-template-constructor.md

The clean evolution of "frozen archetypes". Adding a structure to a site has several independent
dimensions — how deep the hierarchy is, where the data comes from, who may see it, which languages.
A catalogue would need a finished template for every combination (hundreds). So instead of a
catalogue, a CONSTRUCTOR composes a structure to order from a small basis of vetted frozen bricks —
file copy plus token substitution, ZERO code generation, so the built-in brain and every coding
agent produce the identical result.

## Two slots, additive not combinatorial
Every property of a structure lives in exactly one of two slots and they never interact: a LIST
PROVIDER (where the children come from — a filesystem scan, or a database read AT BUILD TIME so the
output stays static) or a UNIFORM ASPECT (a rule applied identically at every level — languages,
or role-based access). Because an aspect is the same rule at any depth and any data source, the
cost is additive, not the N-squared explosion of a special case per combination. The base grid is
{files | DB-at-build} x {depth 1..4} = eight static skeletons, plus one dynamic descriptor for the
rare case where a structure genuinely cannot be static (it returns access rules, not pages).

## Envelope matching and honest refusal
Each brick declares an envelope — its position on every axis (source, depth, static/dynamic, roles,
languages). A request matches a brick only if it fits on EVERY axis; otherwise the agent refuses
naming the exact axis that fails (a live dashboard fails on rendering; a database catalogue fails on
source; a two-level tree fails on depth), then offers to harvest a new brick (only once the shape is
proven and repeats) or to use classic development. It never forces a bad fit and never generates
fragile code. This is capability-grounded selection at scale, in the content space.

## Grown by harvest, one proven brick at a time
The grid of possibilities is a map, not a build plan. A cell is frozen into a brick only once it has
proven itself in real work and repeats (rule-of-three); everything else is served by classic
development until it earns its brick. The constructor is Open/Closed: a new brick slots in through
the seams (list provider, uniform aspect) without touching the core. Today there is one reference
brick — flat, file-backed, multilingual (news / blog / docs feed); deeper trees and database-backed
catalogues are on the roadmap. Surfaces: the owner-tier template-constructor-bridge MCP (port 3224,
owner_template_list_primitives + owner_template_compose_structure with a confirm-first dry run) and
the self-sufficient compose-frozen-template skill shipped to every agent.

===

# Login is now optional — one switch, near-zero token cost

Reference page (news): https://www.fractera.ai/en/news/optional-authorization-one-switch
Raw standard (download): https://www.fractera.ai/docs/app-shell-authorization.md

Public authorization is now an opt-in switch, not a build job. Every workspace already contains
the authorization layer and an always-present admin login; this switch only decides whether the
PUBLIC, visitor-facing login renders in the app shell, controlled by one build-time key
(NEXT_PUBLIC_APP_SHELL_AUTH = off | left | right; left/right also sets the side the account drawer
opens from). Off by default, so a landing page, company page or portfolio ships lighter and
deploys faster — a login it never uses only adds page weight and deploy time. On in one move for a
store, subscription service or delivery app, where people sign in to track orders, keep a cart, or
manage a subscription.

## Roles, panel and voice
When on, access is role-based out of the box: every registered visitor starts as user, and by app
logic (a paid subscription, a completed purchase, a staff function) can hold any of ALL_ROLES
(guest, user, architect, buyer, vip_user, subscriber_lite/standard/max, manager, senior_manager,
support_manager, delivery_manager, finance, content_editor, admin) — granted automatically by
settings or by hand in the admin panel. You flip the switch from the panel (App Settings → App
Authorization) or by voice through the Hermes AI agent over MCP (owner_app_settings_set_app_shell_auth);
tell it what you are building and it decides whether to add a login by itself, asking only the
drawer side. The account buttons (sign in / account / sign out) ship pre-translated into 82
languages, idiomatically per language. Making this decision cost near-zero tokens is the building
block for expanding the starter-template library (an online store, a knowledge platform, more) at
minimal cost.



===

# A universal footer that builds itself — and already speaks 82 languages

Reference page (news): https://www.fractera.ai/en/news/universal-multilingual-footer
Raw standard (download): https://www.fractera.ai/docs/universal-footer.md

It is hard to imagine a page that does not need a footer, so every Fractera project ships one
universal, multilingual footer that fits a portfolio, a company page or a full app — and configures
itself almost entirely on its own. On most pages it has two horizontal sections; the home page adds
a third.

## The sections
1. Footer pages (top): links to the pages the owner chose to surface in the footer. Pages opt in via
their group manifest (the footer menu slot + an order), edited by voice through an AI agent over MCP —
the links form and reorder automatically, never hand-wired. 2. Home-section navigation (home page
only): in-page navigation between the sections of the home page (e.g. SITE CONTENTS); it renders only
on the home page on purpose, because the home page carries the bulk of the content that benefits from
in-page jumps while other pages are more compact. 3. Company block (bottom): pulled straight from app
config with no setup — company name and address from App Settings, social icons once the profiles are
set, a theme toggle (light/dark/system), and a language switcher that appears automatically, with a
searchable region-grouped dropdown, only when more than one language is configured (hidden in
single-language mode). The footer's built-in labels exist in 82 languages (English fallback). The
recurring word is "automatically": in most cases you never think about building the footer at all.



===

# Add any language to a site you already built — without blocking anything

Reference page (news): https://www.fractera.ai/en/news/add-any-language-to-an-existing-site
Raw docs (download): https://www.fractera.ai/docs/scale-site-language-expansion.md and https://www.fractera.ai/docs/translate-pending-runner.md

Speaking your reader's language is one of the cleanest, fully legitimate ways to grow audience and
search presence — Google itself documents it: give each language its own real URL and declare, in the
page markup, that those URLs are the same content in different languages (the alternate-language links,
hreflang). Done right, every language is a new honest door; done wrong — duplicate pages with the wrong
markup — it is punished as a doorway. So the job is not just "translate the words", it is "translate
the words AND keep the markup flawless", and the markup is treated as first-class.

Adding a NEW language to a site that ALREADY has content is now a single, calm, non-blocking move. In
one pass, an AI agent gives every section and every post a version in the new language, SEEDED with the
site's default language — so the site is complete and valid the instant the build finishes, with no
machine-translation bill and nothing broken. Every language-dependent link is rewritten to the new
language, and all four menus (header, footer, left drawer, right drawer) get the new language
automatically, because the architecture derives them from each section.

The Doorway guard: a freshly seeded page still shows the default language, so it is marked
"needs translation", which makes the engine serve it as robots:noindex — Google never indexes a
cross-language duplicate. The canonical and hreflang markup stay correct the whole time (built
automatically from the configured language set, self-canonical + a reciprocal hreflang per language +
x-default), so the moment a page is translated it flips to indexable and counts as a proper alternate.

Translation is a SEPARATE, non-blocking step, on purpose. The platform runs on a subscription with
per-period limits, and translating a whole site is one of the heaviest text jobs there is — welding it
onto the build could blow a budget and stall the work. So the structure is finished and deployed first;
the translations are done later, on a fresh budget, even with a different and cheaper model. The
expansion opens ONE tracked development step per language, listing every page that language is waiting
on, so nothing is ever forgotten — visible (and editable) on the Development Steps service page, where
you can add a per-language note (e.g. "for Spanish, focus on Spanish law and link the real statutes")
that the model honors when it generates that translation, turning a translation step into a place to add
regional value. A second tool — the runner — walks those pages, writes the real translation into the
frozen structure (strings only, never the block structure), clears the needs-translation mark, and does
NOT deploy: you press Deploy in the footer when you are ready to publish.

Two tools, served by the owner-tier language-expansion MCP bridge (:3228): owner_content_add_site_language
(the expansion) and owner_content_translate_pending (the non-blocking runner). A third, read-only tool —
owner_content_scan_broken_characters (and the project-root npm run check:encoding) — is the
encoding-integrity guard: a lossy step (voice dictation, copy-paste, a bad transform) can leave a control
byte or replacement character where an accented letter belonged, shipping silently so a visitor sees a box
where the "o" in "Documentacion" (with its accent) should be. The content tools refuse such characters on
write; the scanner sweeps every language and every file and reports exactly where one hides, to be fixed
by hand with the correct letter. Bottom line: prototype in one or two languages, then scale to the rest
safely — pages valid immediately, translation on your own schedule, menus for free, and markup Google
rewards rather than penalizes.



===

# MCP coding — one messy request becomes a development pipeline

Reference page (news): https://www.fractera.ai/en/news/mcp-coding-decompose-requests-into-pipeline
Raw skill (download): https://www.fractera.ai/docs/orchestrate-content-by-steps.md

Until recently you fed tasks to AI agents one at a time: add a news section, wait; add a
documentation section, wait; add a sign-in button, wait; make documentation members-only, wait.
Now the platform takes the whole order at once — long, unstructured, even error-ridden — and
decomposes it BY THE SITE'S ACTUAL STATE (does the section exist? is login enabled?) into an
ordered pipeline of development steps. Dependencies are understood as dependencies: "docs for
signed-in users only" implies enabling site login and gating one section by role, and the plan
shows this as an explicitly marked implied line.

## The order sheet and the approval token
The decomposed request becomes an order sheet: one resolved human line per section ("news —
visible to EVERYONE — appears in: top menu, footer"), the implied consequences, and an honest
content boundary — new pages come up as frozen placeholder stubs; real prose is a separate,
later request. Two questions per section are mandatory and never guessed (admin panel? dashboard?).
An explicit "yes" issues an approval token bound to exactly that plan; a changed or unconfirmed
plan cannot start. Every sub-step then runs the full lifecycle: open a development step -> execute ->
deploy -> RECORD the deployment (a hard gate — a step cannot close without a confirmed row in the
deployments table) -> close.

## Materialize-first and resume
On approval the orchestrator FIRST writes the entire queue to disk — every sub-step becomes its
own file on the Development Steps page carrying its full machine spec (order-sheet id, sequence,
kind, args, the page URL, the approved order line) — and only then executes. The plan history
exists on disk BEFORE any work, so a timeout, crash or lost session loses nothing: to resume,
even in a brand-new session, the agent calls the same tool with the same plan and the same
approval token — completed sub-steps are skipped, pending ones re-execute from their files.

## Two scenarios: flat MCP coding vs recursive development
Standing up new structure (sections, pages, menus, access) is MCP coding: assembly from vetted
frozen templates by file copy + token substitution, zero code generation — so any model produces
the identical result, and the whole flat pipeline is deliberately run by Hermes on inexpensive
models. MCP coding scales the architecture flat: it adds structure, never rewrites what exists.
When a task cannot be finished by MCP coding alone (real prose, a real feature, changing an
existing page), Hermes delegates it to an available coding agent — Claude Code, Codex, Gemini CLI,
Qwen Code or Kimi Code, whichever currently has tokens or an open session window within its
subscription; a coding agent's process may be recursive and more creative, at its own discretion.
If no coding agent is active, that is not a failure — the task is saved as a development step.

## Watching it live
While the pipeline runs the chat goes quiet, and two realtime service pages replace the black box:
Architecture shows new routes, pages and service components appear on the live map of the app;
Development Steps shows each step with a status badge (new / in progress / completed) and a
completion time down to the second. Both poll the filesystem and pulse the nodes that changed.
The direction: application development up to 100x faster and 100x cheaper than traditional
app-generation systems — final testing is near.

===

# Only the architect changes your workspace — a secure-mode mutation gate

Reference page (news): https://www.fractera.ai/en/news/only-the-architect-changes-your-workspace

When you self-host your own workspace, one question follows fast: who is allowed to CHANGE it —
not view it, but rewrite configuration, touch the database, redeploy the app? In secure mode the
answer is now precise and enforced: only you, the architect. This update closes the gap where
simply holding a session, or holding a shared secret, could be mistaken for permission.

## Logging in is not the same as permission
Most systems check one coarse thing before a sensitive action: are you logged in at all? A
workspace has many kinds of members — visitor, customer, subscriber — and none of them should
rewrite the site's configuration just because they hold a valid session. So the gate no longer
asks "is there a session?" It asks "is this the ARCHITECT?" A shared secret is treated the same
way: a key proves what you hold, not who you are, and for changing a system where a real human
owner exists we require the role, not merely the key. Machine-to-machine paths that legitimately
carry a secret still work; the human path is gated by role.

## The same rule at every door — not one central guard
A single central checkpoint is a single point of failure: bypass it, or run a project that does
not include it, and the protection is gone. So the rule lives at every door independently, on
three surfaces: (1) the AI tool bridges an agent uses to act require a valid credential on every
call — an anonymous request is refused; (2) the admin interface serving configuration, database
and deployment operations verifies the architect role before any change, not just a logged-in
session; (3) the data service storing products, media and records requires the architect role for
every write, while ordinary reads can stay broader. Because the rule is duplicated into each
surface rather than centralized, it survives even a minimal setup — a workspace running a single
AI agent with no central brain still enforces the same gate (the same self-sufficiency principle
behind one-switch optional authorization).

## Reads broad, writes locked — and onboarding stays open
Reading can stay broad and tiered by who is asking; only mutations — anything that writes to files
or the database — are restricted to the architect. And the tightening applies to SECURE mode only:
the fast open onboarding mode, where you first meet your workspace on a plain address, stays fully
open by design, so nothing about getting started becomes harder.

===

# Projects now decompose before they are built — the frozen process for private automations

Reference page (news): https://www.fractera.ai/en/news/project-decomposition-frozen-process
Raw skill (download): https://www.fractera.ai/docs/orchestrate-project-by-steps.md

A private automation ("summarize my YouTube channels to Telegram every morning") was the last
thing an AI agent still planned in its head — and a plan that lives only in a context window is
invisible, fragile and unverifiable: you cannot read or correct it, a crash or a subscription
limit erases it, and nobody gates whether each piece was actually specified before someone
started coding it. The platform now applies the same frozen, materialize-first discipline to
projects that already governs content — with one difference: content decomposes deterministically
by the state of the site, while a project graph is proposed by the model, and a frozen engine
then validates, gates, documents and materializes. The engine never writes the automation code.

## A validated graph of small nodes
Every node carries its own contract: a title, a kind (trigger / action / transform), an
exhaustive task description, the tools it uses, the environment keys it needs (never hardcoded —
set through the same rebuild-safe channel as every build-time setting), inputs and outputs, a
to-do list, and dependencies. The engine checks the DAG for cycles and broken links, then applies
the real gate — specification completeness: a node with an empty task or no to-do items is
refused with a precise list of what is missing, and nothing is written to disk until the graph
is complete. The resolved plan is shown to the owner verbatim as an order sheet; a real run
requires an approval token bound to exactly that plan. Graphs over ten nodes receive an MVP
recommendation — launch a ten-node MVP and grow each node by separate future tasks, so the owner
always understands exactly how the project works; a soft gate, the decision stays with the owner.

## Materialized queue: README + spec + coder handoff per node
On approval the first artifact is the project-root README, generated from the graph itself: why
the project exists, how it works (a table of every node in execution order), efficiency, reuse,
and the expected result. Every agent instruction on the platform requires reading that README
first when working on any project step. Then the whole queue lands in the Development Steps
system: one exhaustive specification step per node plus one separate coder-handoff step per node
(fixed first actions, deliverable, tools and keys, acceptance criteria, finish protocol). The
coding agent receives exactly one thing — a step number; handing over the number does not close
the node — the orchestrator watches for real completion (step closed, deployment recorded)
before opening any dependent node. A crash loses nothing: re-running with the same plan and the
same token, even in a new session, skips existing files and creates only the missing ones.

## Self-sufficient by design
The process ships as a self-sufficient skill in every agent entity — a lone agent with no central
brain runs the identical process directly — and as the owner-tier MCP tool
owner_projects_orchestrate_decomposition (same dry-run, same order sheet, same approval token).
Scope is deliberate: projects and automations only — public site pages keep their own frozen
pipeline, and the two never mix.

===

# Fractera is Product of the Day — Top 2 Daily Winner on Smol Rank

Reference page (news): https://www.fractera.ai/en/news/fractera-product-of-the-day-smol-rank
Listing: https://smolrank.com/projects/fractera

On 2026-07-08 Fractera launched on Smol Rank and closed the day as a Top 2 Daily Winner,
earning the "Smol Rank Top 2 Daily Winner" badge and the Product of the Day rank. The listing:
Web platform, free pricing, 5 upvotes, categories Artificial Intelligence and Developer Tools,
tech-stack tags Hermes, NGINX, Next.js, Coding agent, publisher Iuliia Kovalchuk. The listing
tagline: "One-Click Private AI Stack on your VPS. Deployed with a pre-built 50k-line Next.js
Aircraft Carrier (or any repo) & Zero-Agent Design System."

A short celebratory note, not a feature release. It states the facts of the ranking, thanks the
people who upvoted, and points a first-time visitor deeper into the platform behind the badge:
the Next.js Aircraft Carrier (the pre-built 50,000-line parallel-routing framework), the
autonomous development loop (one request becomes tested, deployed, recorded code), and the Open
Code license (copy, audit and self-host everything on your own VPS). Bilingual (EN/RU).