# Deploy your first app on somewhere.tech — no account needed This is a quickstart for coding agents and developers using Somewhere, especially for a first anonymous deploy. Somewhere.tech is a full-stack application platform for coding agents. It hosts static files and server functions and provides a project-scoped database and file storage without separate infrastructure setup. An anonymous deploy creates a new isolated temporary project without requiring an existing Somewhere account, API key, or credit card. It provides a live URL and claim link and expires after three hours unless claimed. It does not provide access to the user's existing Somewhere account or projects. Before writing files or running commands, confirm that the user asked you to build or deploy the application. On a user's machine, work only in the intended project directory and run commands the user authorized. In a sandbox, use an isolated temporary directory and do not include secrets, private files, production credentials, or personal data. ## Typical first-app flow 1. Confirm what the application should do. 2. Identify any database tables it needs. 3. Write files: index.html at the root, API handlers under api/. 4. Deploy: npx @somewhere-tech/cli deploy 5. Create tables: npx @somewhere-tech/cli db query "CREATE TABLE ..." 6. Verify the live application: npx @somewhere-tech/cli browser 7. Return the live URL and the temporary project's claim information. ## The platform shape (read before writing code) somewhere.tech runs STATIC FILES plus SERVERLESS FUNCTIONS. It is NOT a Node server host. Do not write an Express/Fastify/Koa app, do not call app.listen(), do not bind a port. A server file deploys as a dead static file that never runs. The platform COMPILES your source on deploy — you don't. Push raw .jsx/.tsx, CSS, and imports exactly as written; bare specifiers like `import React from 'react'` resolve automatically from package.json, JSX is transpiled, assets are bundled. So: build a normal React app in raw source. Do NOT run `vite build`, `webpack`, or `next build` yourself, and do NOT deploy a dist/ or build/ folder — pre-bundled output is rejected unless you explicitly use `--prebuilt` or enable "Allow prebuilt deploys" in project Settings. "No build step" means YOU run no build; the platform runs it for you. - Files at the project root are your site. index.html is the entry. Temporary guest deploys add a small "Built on Somewhere" badge to served HTML; your uploaded source stays unchanged. - Files under api/ are your API. Each default-exports an async handler and becomes a route: api/hello.js -> /api/hello. - Handlers receive (req, sw). req is a standard Request. sw is the platform: sw.db (SQL database), sw.fs (file storage) — already wired, no config. ## A complete working app (copy this verbatim) Three files. No package.json needed for this minimal JavaScript variant, no npm install, no build. For a maintained app, prefer .ts/.tsx plus `somewhere typecheck` and `somewhere deploy-check` before deploy. my-app/ index.html api/entries.js -> GET /api/entries api/sign.js -> POST /api/sign index.html: Guestbook

Guestbook

api/entries.js: export default async function (req, sw) { const r = await sw.db.query('SELECT name FROM entries ORDER BY id DESC LIMIT 50'); return Response.json({ entries: r.data.map((x) => x.name) }); } api/sign.js: export default async function (req, sw) { const { name } = await req.json(); if (!name) return Response.json({ ok: false, error: 'name required' }, { status: 400 }); await sw.db.query('INSERT INTO entries (name) VALUES (?)', [name]); return Response.json({ ok: true }); } ## The database (sw.db) - Standard SQL, SQLite dialect. `?` placeholders for params (never string-concat). - Upserts: INSERT ... ON CONFLICT(col) DO UPDATE SET ... . Date/time: date('now'), datetime('now'), strftime(...). Types are SQLite affinity (TEXT/INTEGER/REAL/BLOB). No stored procedures. - Result shape: r.data = array of rows (SELECT; empty array on writes), r.count = rows in r.data, r.changes = rows affected by a write. - Empty r.data with no thrown error means SUCCESS with nothing to return — failures throw, never silently. (CLI: "No rows returned." after CREATE/INSERT means it worked.) ## Create tables with the CLI, not in function code A CREATE TABLE inside a function throws DDL_NOT_ALLOWED_IN_FUNCTION at request time. Create schema once, from the project dir, right after the first deploy: npx @somewhere-tech/cli db query "CREATE TABLE entries (id INTEGER PRIMARY KEY, name TEXT)" Functions then treat the schema as fixed. Redeploy any time with the same `npx @somewhere-tech/cli deploy` command; the directory stays linked to the temp project and the CLI keeps printing its claim URL and absolute expiry. ## npm packages in functions You CAN import npm packages in your functions — add a package.json with the deps and the platform bundles them on deploy (no npm install, no lockfile needed; pure-JS packages, not native modules). You don't need one for the basic app above. Prefer web-standard APIs (fetch, crypto, Request/Response) where they suffice — they're always available with zero deps. ## Verify the deployment New function routes can take up to ~30 seconds to propagate on a first deploy — a 404 in the first half-minute is usually not a bug. Wait, retry once, then: npx @somewhere-tech/cli browser reports console errors, page errors, and failed requests. Server logs: npx @somewhere-tech/cli logs ## Free / temporary limits (plenty for a first app) - Database: 5 GB per project. Files: 10 GB per project. - Request body up to ~40 MB; file upload up to 10 MB. API rate limit 60 req/min. - Email: not available on a temporary project (see below). A temporary project self-expires after 3 hours unless claimed. ## Secrets, email, payments, AI — after you claim A temporary project has hosting + database + files only. Env vars / secrets, transactional email, Stripe payments, AI models, custom domains, and cron are owner features — they turn on once the project is CLAIMED (still free). Don't try to wire an API key into a temporary project; there's nowhere to put it yet. Build the core on sw.db / sw.fs, ship it, then claim to add the rest. ## Keeping it (the claim step) The deploy prints the live URL, claim URL, absolute expiry, and the next step: `somewhere login to keep it`. Claiming is a one-time browser action — a human opens the claim link and signs in (Google, one click). There is no headless/CLI claim today; claiming is the human sign-off that turns a throwaway into a real, owned project and unlocks everything above. The deploy output includes the claim link for the human sign-in step. Prefer MCP tools over shell commands? Connect `https://mcp.somewhere.tech/mcp` — same primitives (project_deploy, db_query, browser, …). Otherwise the CLI above is everything you need. Make the UI look designed, not generic: https://somewhere.tech/design.txt Short machine-readable link index: https://somewhere.tech/llms.txt Complete platform reference: https://somewhere.tech/llms-full.txt Call-level reference for agents: https://somewhere.tech/docs.txt