Anatomy of an app

A freshly scaffolded app looks like this:

index.html              # frontend entry, served at /
app.js                  # frontend JavaScript
style.css               # styles
api/
  hello.js              # an API route -> GET/POST /api/hello
cloudrizz.seo.json      # SEO + AI discoverability config
migrations/             # *.sql schema migrations (add as needed)

The frontend is served as static assets. Anything under api/ is a backend route. Add files to grow the app, there's nothing to register.

Plain static files at the project root. index.html is served at /; reference your scripts and styles normally:

<link rel="stylesheet" href="/style.css" />
<script src="/app.js"></script>

The frontend talks to the backend with a normal fetch:

const res = await fetch("/api/hello");
const data = await res.json();

Extension-less paths fall back to HTML, so client-side routing works. Large files (over 20 MB) are served from storage rather than the asset bundle automatically.

Each file under api/ maps to a route by its path: api/hello.js → /api/hello, api/orders/list.js → /api/orders/list. A route file default-exports an object with a fetch method:

// api/hello.js
export default {
  async fetch(request, env, ctx) {
    return Response.json({
      message: "Hello from your Cloudrizz API route!",
      app: env.APP_ID,
      environment: env.ENVIRONMENT,
    });
  },
};

The fetch(request, env, ctx) signature is the standard edge handler shape. env carries the platform bindings, env.DB, env.STORAGE, env.EMAIL, env.AI, env.AUTH, env.PAYMENTS , plus env.APP_ID, env.ENVIRONMENT, and any environment variables you set.

Your app's database schema lives in migrations/*.sql. See Database for how migrations are applied and the reserved _cr_* table namespace.

Two filenames under api/ are not HTTP routes, they're registries Cloudrizz wires up for you:

• api/mcp/tools.js, turns your app into an MCP server. See Give your app an MCP server.
• api/cron.js, scheduled-job handlers. See Scheduled jobs.