How Fullstack Agent Coding works
Fullstack Agent Coding isn't a template generator — every app is a real, isolated full-stack application that the agent writes, tests, and deploys to its own URL. This page explains what's actually running under the hood, so you can trust where your app lives and what it can do.
The app, end to end
| Layer | What it is | Where it lives |
|---|---|---|
| Frontend | Static HTML/CSS/JS — plain, or built from React/Vite and served as static assets | Inlined into the app's Worker and served from its own URL |
| Backend | One API server the agent writes and tests (server.js) | A single Cloudflare Worker |
| Database | A relational schema the agent designs and migrates as the app grows | Cloudflare D1 (SQLite, via env.DB) |
| Storage / cache | Files, blobs, key-value data | Cloudflare R2 (env.STORAGE) and KV (env.KV) |
| URL | A live https:// subdomain the moment a build finishes | Cloudflare, per-app |
There's no server you rent and configure — the platform provisions an isolated Worker, database, and storage per app, so "deploy" is instant and each app is sealed off from every other app and from your Nexrall account.
How a build actually runs
- You describe the app. The agent turns your request into a plan and asks a clarifying question if something important is ambiguous.
- It writes files. Frontend, backend, and any seed data — using real file tools (
write_file,edit_file,multi_edit) the same way a coding agent edits a repo. - It runs commands. Installing dependencies, linting, type-checking, and any small script it needs — in a sandboxed shell.
- It verifies its own work. This is the step most builders skip. The agent calls
verify(), which deploys the current files to the live preview and runs a smoke test in Cloudflare's actual runtime — checking for startup, JavaScript, and console errors, not just "does it compile." It can then run API tests, UI click-through tests, or a custom test script against the real deployed app. - It deploys. Once the app loads cleanly, it goes live at its own URL. Your next message is another turn of the same agent on the same app.
Nothing is "live" until the agent calls verify() and it passes — the build can't finish on a broken app.
Where data lives
Each app gets its own scoped database, so there's no shared schema to break and no cross-app data leakage:
- D1 — the relational database (
env.DB). The agent writes and runs migrations as your data model evolves, so you can keep adding fields and tables by chatting. - KV — key-value storage (
env.KV) for fast lookups, counters, sessions. - R2 — object storage (
env.STORAGE) for uploaded files, images, exports.
For anything external, the agent can call third-party APIs directly with fetch() from the backend, or wire a connector (see Tools & limits) so a service's credentials are stored as app secrets rather than in code.
Background work
Apps aren't limited to request/response. The agent can add:
- Scheduled tasks (cron) that run on a recurring schedule.
- Queue-backed jobs for work that should run asynchronously.
Both run inside Cloudflare, so they keep working without you keeping a browser tab open.
The tech stack, plainly
| Concern | Technology |
|---|---|
| Runtime | Cloudflare Workers (one Worker per app) |
| Database | Cloudflare D1 (SQLite) |
| Storage | Cloudflare R2 + KV |
| Frontend | Static HTML/CSS/JS (plain or React/Vite) |
| Backend | JavaScript/TypeScript (server.js) |
| Deploy | Per-app subdomain + optional custom domain (Cloudflare for SaaS) |
| Model | Multi-provider — see Models |
Next steps
- What the agent can do & limits — the tool set and its guardrails.
- Security & sandboxing — how apps stay isolated.
- Troubleshooting — common issues and fixes.