Run a Node.js snippet on the project's compute VM (headless — no browser needed). The project's npm dependencies are importable; network access works, so you can call the project's /_api/* endpoints (get_preview_url → apiBaseUrl). ESM by default; bare require() snippets run as CJS. Returns stdout+stderr.

Calls to the project's /_api/* are rate-guarded exactly like the browser preview: more than 20 calls to one endpoint or 150 total within 5s rejects that fetch and every later /_api/* fetch in the snippet with 'Backend endpoint is called too frequently'. This is a hard guard, not a retry hint — do NOT loop fetch() over rows/ids or fire many parallel calls; batch into one endpoint call, or read/write the rows directly (query_database / execute_sql).

Runs in an ISOLATED temp dir, NOT the project root, with NO access to the project's environment: process.env carries none of the project's env vars or secrets (only PATH/HOME/NODE_ENV are set — anything like process.env.POSTHOG_API_KEY reads back undefined), and project source files are NOT importable by relative path (import './helpers/foo' fails with ERR_MODULE_NOT_FOUND — only npm dependencies resolve; contrast run_code_in_browser, which runs at the project root and CAN import project files). For anything that needs project secrets, env config, or DB access, use the _floot helpers below (they proxy to the project's server context) or fetch the project's /_api/* endpoints over the network — those run server-side WITH the full env; the VM snippet itself never sees it.

Plain SQL does not belong in a snippet: read data or inspect the schema (information_schema / pg_catalog, several statements per call) with query_database, read the typed schema with pull_database_schema, and run writes and DDL with execute_sql, where the user sees each statement. Use _floot.runSQLQuery only when the SQL is part of a program — a loop that seeds rows, or results the snippet goes on to process.

A _floot global is available with project-scoped server-data helpers (no DB creds needed, no HTTP wiring): await _floot.runSQLQuery({ query, resourceName?, reasonAndExplanationForNotReadOnly?, dryRun? }) (omit the reason for a read-only query; pass it to allow NON-DESTRUCTIVE writes — INSERT, CREATE TABLE, additive ALTER — e.g. programmatic seeding loops. DESTRUCTIVE statements — DELETE/UPDATE/TRUNCATE/DROP — are rejected here because the user never sees snippet SQL; run those through the execute_sql tool, where the statement appears in the tool call for approval. Resolves to {rows, rowCount, command, truncated?} — or {results: [...]} for multi-statement queries), getHostingUsage({days?}), getLambdaUsage({days?}), getPushHistory({subscription?,from?,to?,offset?}), getProdBackendLogs({filter?,from?,to?,nextToken?,limit?}) (the PUBLISHED app's backend CloudWatch logs; details: get_guides('prod-backend-logs')), storageList(prefix) (prefix MUST start with "public/" or "private/" — e.g. storageList("public/") to list everything public), storageGetUrl(key), storageGetFileSizes(visibility, continuationToken?), storageUpload({filename,sizeBytes,contentType}), storageDelete(key), and getFileById(id) (returns {url, fileName, contentType} — fetch the url for bytes). Same surface as runCodeInBrowser's _floot, minus the DOM/editor-only helpers.