Lot

Data Seeding

Most apps need seed data to be useful during development. Here are three approaches depending on your database setup.

Local database with a seed script

If your project runs a local database (SQLite, PostgreSQL via Docker, etc.), provide a seed script and have the setup agent run it during initial setup.

During project setup

The setup agent is interactive — you can chat with it while it's setting up your project. If you have a seed script, ask the agent to run it during setup:

please also run npm run db:seed to populate the database with test data

The agent will include the seed script as part of the setup command. Since the setup command runs only once and is baked into the snapshot, your seed data will be present in every new session without re-running the script.

After project creation

If you forgot to seed during setup or need to update the seed data, you have two options:

  1. Update environment — go to project settings and click Update Environment. This runs the setup agent again on top of your existing snapshot. Tell it to run the seed script, and a new snapshot will be created.
  2. Per-session seeding — ask the agent in any coding session to run your seed script. This only affects that session (not the snapshot).

Example setup

// package.json
{
  "scripts": {
    "db:seed": "tsx prisma/seed.ts",
    "db:reset": "prisma migrate reset --force"
  }
}

During setup, the agent will run something like:

npx prisma migrate dev
npm run db:seed

Shared remote database

If your team shares a remote development database (e.g., a staging database on RDS, Supabase, or PlanetScale), you can point your Lot sessions at it via environment variables.

Setup

  1. Add your DATABASE_URL (or equivalent) as an environment variable in the Env tab
  2. The agent and your app will connect to the remote database automatically

Caution for teams

Using a shared remote database with multiple Lot sessions can be tricky:

  • Migration conflicts — if the agent runs migrations in one session, it can break other sessions or team members working against the same database.
  • Data conflicts — multiple agents writing to the same database can cause unexpected state. Each session may seed or modify data independently.
  • Cleanup burden — test data from agent sessions can accumulate in the shared database.

For teams, consider using Neon database branches (see below) for isolated per-session databases, or use a local database within each sandbox.

Neon database branches

Neon supports instant database branching — creating a copy-on-write fork of your database in seconds. This gives each session its own isolated database with real data, without the cost of a full copy.

How it works

Add a branch creation script to your dev command so that each session gets a fresh database branch. Since the dev command runs at the start of every session, each session will automatically get its own branch.

Setup

  1. Add your NEON_API_KEY and NEON_PROJECT_ID as environment variables
  2. Create a branch script in your repo (e.g., scripts/create-branch.sh):
#!/bin/bash
# scripts/create-branch.sh
# Creates a Neon branch and exports DATABASE_URL

BRANCH_NAME="lot-session-$(date +%s)"

# Create branch via Neon API
BRANCH=$(curl -s -X POST \
  "https://console.neon.tech/api/v2/projects/$NEON_PROJECT_ID/branches" \
  -H "Authorization: Bearer $NEON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"branch": {"name": "'"$BRANCH_NAME"'"}}')

# Extract connection string
DATABASE_URL=$(echo $BRANCH | jq -r '.connection_uris[0].connection_uri')

# Update .env with the branch URL
sed -i "s|DATABASE_URL=.*|DATABASE_URL=$DATABASE_URL|" /workspace/repo/.env
echo "Created Neon branch: $BRANCH_NAME"
  1. Set your dev command to run the branch script before starting the dev server. In project settings, update the dev command to:
bash scripts/create-branch.sh && npm run dev

Benefits

  • Instant — Neon branches are created in under a second
  • Isolated — each session gets its own database, no conflicts
  • Real data — branches are copy-on-write from your main database
  • Free cleanup — branches are ephemeral and can be deleted automatically