Overview#
Snoozestack is a complete application platform you run locally, then publish to managed production servers. A project is a folder: a committed snoozestack/ directory declaring its functions, schema, storage, queues, schedules, sites, and auth in one project.toml. One service — the runtime — runs that whole declaration: natively on your machine under snoozestack dev, and on snoozestack's hosted fleet after snoozestack publish. Your organization's admin account owns the projects; each hosted project serves at https://<project-ref>.snoozestack.com.
You interact with the platform four ways: the console (the hosted portal, and the identical local dashboard snoozestack dev serves), the snoozestack CLI, the snoozestack-js and snoozestack-swift SDKs inside your app — and your AI client over MCP, which can do everything the CLI can.
The mental model#
Two shifts orient everything else here. First, the project is files: what most platforms keep as dashboard settings — which functions exist, what they may access, the schema, the buckets, the queues, the cron timers — is a committed project.toml plus the code next to it, so configuration diffs, reviews, and rolls back like code, and nothing about your backend lives only in a console.
Second, your functions are the boundary. Clients never reach the database — there is no client-facing table API to secure. A committed function reads and writes it through capabilities.db, and decides what the caller may see with an ordinary where clause informed by capabilities.auth.user — the check a hand-written API handler always made, minus the server to run. See Permissions.
| You need to… | Use | Instead of |
|---|---|---|
| Read and write your own data | A function with the db capability, called with functions.invoke() | A client-side query builder talking to a REST API |
| Stop users seeing each other's rows | The function's own query, scoped to capabilities.auth.user.id | A row-level security policy applied automatically |
| Change the schema | Edit schema.mjs and record a migration | Clicking in a console and hoping you remember |
| Use a secret API key | A declared secret, readable only by the functions you name | Shipping the key to the client |
| Do slow work after responding | A queue, declared in project.toml and testable locally | Blocking the request |
| Store a file | Storage, with the path in a column | A blob column in the database |
| Ship it | snoozestack publish — an immutable version, live atomically | A deploy pipeline you assemble and babysit |
| Let an AI client build and operate the backend | Its own MCP endpoint | Pasting SQL out of a chat window |
Organizations & projects#
Your admin login belongs to one organization, which owns every project you create — each a complete, isolated backend: one runtime with its own database, storage, queues, and users. See Organizations & projects for the full model.
Where to go next#
- New here? Start with Quick start.
- Want the architecture in one picture? Read The runtime.
- Working with an AI client? Connect it to the project's MCP endpoint — it gets these docs and every management operation over one connection.
- Building an app against it? Start with the JavaScript or Swift SDK.