For Developers — Stack & Development Cycle
What a Totalum project is, how it moves from development to production, and how you own it.
A Totalum project is a real Next.js application with its own databases, written and maintained by Totalum's AI agent as you describe what you want — and yours to download, sync to GitHub and run anywhere.
#The stack
| Layer | What the project uses |
|---|---|
| Framework | Next.js (App Router), React, TypeScript |
| Styling | Tailwind CSS with a design-token theme, no UI kit |
| Runtime | Cloudflare Workers (one Worker per project and environment) |
| Database | SQL (SQLite) on Cloudflare D1, read through Drizzle ORM; Turso for databases past 10 GB |
| Sign-in | better-auth: e-mail and password, Google, password reset, sessions, rate-limited and captcha-protected. Built-in pages (/login, /register, /forgot-password, /verify-email, /account) are off until the app needs accounts (accounts: true in src/lib/site.ts); e-mail confirmation by 8-digit code only when asked (verifyEmail: true) |
| Browser icon | Automatic: the logo (site.logo), else the app's initials on its brand colour (/site-icon.svg) |
| AI | OpenRouter's API through Totalum's AI gateway (TOTALUM_AI_BASE_URL, the project key): any OpenRouter model for text, vision, images, video, text-to-speech, transcription, embeddings and rerank, plus decision models (POST /systemone: typed answers to yes/no, pick-one and score questions, for classifying, routing and moderating), billed in credits; the app calls it with the Vercel AI SDK or plain fetch |
| Built-in features | totalum-sdk: e-mail, files, document scan, web scraping, cloud browser, PDF, payments, real-time, scheduled jobs, vector search, logs, analytics |
| Mobile | Capacitor shell that opens the published site, built for Android and iOS by Totalum on paid plans; store uploads use your own Google Play and Apple developer accounts |
| Packages | Any npm package that runs on Workers |
Everything under src/ runs on Workers, not Node: no filesystem at runtime and no long-lived connections. Recurring work is a scheduled job; real-time is the SDK's real-time channels. The agent knows these rules and writes code that fits them. It logs each key step (console.log / console.error), checks its work in its own browser, and reads the logs (npm run logs -- --level error, or the Logs API) when something fails.
#Development and production
Each project has two environments, like two branches:
| Development | Production | |
|---|---|---|
| Address | The preview (…-dev-temporal-link-preview-….totalum-project.com), private, changes monthly | <projectId>.totalum-project.com and your custom domain |
| Database | The development database (with demo data) | The live database (real users and data) |
| Changed by | Every prompt, file edit, visual edit, GitHub pull, restore | Only Publish |
- Every change is a version. A prompt that changes code, a file saved through the API, a visual edit or a restore is saved as a version and deployed to the preview. Any version can be compared and restored.
- Database changes are migrations. The agent changes
src/db/schema.ts, generates a migration indrizzle/, and applies it to the development database at once. Publishing applies the pending migrations to the live database, then puts the new code live. Migrations only add (new tables, columns, indexes); a migration that would drop or overwrite live data runs only when you confirm it. - The agent works on development data. It writes production rows only when your prompt explicitly asks for it ("in production, mark order 42 as shipped").
- Publishing is safe. If the build or a migration fails, the agent tries to fix it; the live site keeps serving the previous version until a publish succeeds.
prompt ─▶ version ─▶ preview + dev database ─▶ … ─▶ Publish ─▶ migrations on live ─▶ new code live#Scaling and performance
Projects are server-rendered at the edge, close to every visitor, and scale from zero to millions of requests without servers to manage. Pages read the database in one round trip; reads go to the copy nearest the visitor. A busy public page can cache its reads for a few seconds. When a database outgrows 10 GB or needs more throughput, it can be moved to Turso.
#You own everything
- Code: download it or sync it to GitHub at any time. It runs locally with
npm ci && npm run dev— see Run Locally & Self-Host — and moves to any other host with its data: Move to Another Host. - Data: download a backup of either database as standard SQLite SQL, or read rows through the Database API.
- Files: every uploaded file is listed and downloadable.
#Lifecycle of an idle project
A project that is not used goes to sleep and wakes on its next prompt in seconds. On the free plan, a project idle for months is archived and, after warnings by e-mail, eventually removed; paid projects are never removed for inactivity.
#Limits
Every plan, project and database limit is on Limits; how code fits them is in Design for the Limits.