Getting started
Install Trylane with your coding agent
Paste one prompt into Claude Code, Cursor, Codex or another coding agent. It integrates Trylane into your app, checks its own work with doctor and the effect scanner, then stops for your review. Publishing stays your decision.
Hand the integration to your coding agent
It makes the changes in your app, checks them with doctor and the effect scanner, then stops for your review. You decide when to publish.
Which agent do you use?
- 1
Open a terminal in your app’s folder and start Claude Code.
$claude - 2
Paste the prompt.
Contains no keys or secrets.
Read the prompt first
Integrate Trylane into this app so website visitors can try a disposable copy of it without signing up.
Read https://trylane.app/llms-full.txt first; it has the full integration guide. Work in this order and stop where told.
0. Check fit. Trylane needs TypeScript on PostgreSQL, with every query scoped to a tenant (an org, workspace, team or account). If either isn't true, stop and tell me.
1. Find, and list with file paths: the tenant table and its id column; the function that resolves the signed-in user or tenant; sign-up, sign-in, invite, password-reset and admin or cross-tenant routes and server actions.
2. Run `npx trylane scan . --json` to list outside effects (email, payments, AI and other paid APIs, webhooks, storage, queues).
3. Make the guide's changes: the demo migration, the recipe, the agent, lib/trylane.ts, /enter, the auth swap and milestone tracking. Mark every line you adapted with // CHANGE:. Nothing may change unless TRYLANE_DEMO=1.
4. Recipe: small, realistic sample data for one visitor. seed() returns the exact number of rows it inserts. cleanup() deletes the tenant, letting ON DELETE CASCADE remove its rows; delete rows in tables with no foreign key first.
5. In demo mode, refuse sign-up, invites, password reset and admin in the handler or server action, not only on the page. Guard every scan finding with denyExternalEffect() or an early return. Rerun the scan until nothing is unguarded, or explain each one left.
6. Run doctor with --json. Fix each failing check using its "fix" field and rerun until "ok" is true.
7. Never print, paste or commit TRYLANE_PROJECT_KEY, COOKIE_SECRET, TRANSFER_KEY or database URLs. Put placeholders in .env.example only.
8. Stop. Don't publish the demo or deploy anything. Report the files you changed, doctor's result, the scan's result, and the review checklist below, with the file and line that covers each item.
Review checklist for me:
- The auth swap returns a demo identity only when TRYLANE_DEMO=1.
- Sign-up, invite, password reset and admin refuse demo visitors in their handlers.
- Every outside effect is blocked in demo mode, and the demo deployment holds no production email, payment, webhook or AI keys.
- The demo database is separate from production and owned by an ordinary role.
- After publishing, `npx trylane probe --url https://trylane.app --slug <demo>` passes.What the agent does
It finds your tenant table, your auth lookup, your account and admin routes, and every outside effect. Then it writes the demo migration, the sample-data recipe, the agent, the visitor entry route and the demo-mode guards, marking each adapted line with // CHANGE:. Nothing changes outside demo mode.
How it checks itself
Doctor with --json returns one machine-readable report: a stable code per check, pass, fail or warn, and a fix for each failure. `npx trylane scan` lists likely email, payment, AI, webhook, storage and queue calls, and whether each file mentions a demo guard. The agent reruns both until they pass.
What you review before publishing
The agent stops with a checklist and the file and line that covers each item: the auth swap only applies in demo mode; sign-up, invites, password reset and admin refuse visitors in their handlers; every outside effect is blocked; the demo database is separate. A passing doctor doesn't prove these, so read the diff.
After you publish
Run `npx trylane probe --url <your Trylane> --slug <demo>`. It enters your demo as two real visitors, crawls each one's pages and requests them with the other's cookie and with none. Any record page that answers is reported. It sends only GET requests, so cross-visitor writes still need your app's own tests.
Limits
The scanner matches known packages and literal URLs. It can miss wrappers, variable URLs and unlisted SDKs. The probe only reaches records linked from your pages. Both reduce risk; neither proves your app is isolated.