coding-agent-template

Tasks run in a Vercel Sandbox. You can control the lifecycle of this sandbox using two settings:

Maximum Duration

Controls how long the sandbox stays alive from the moment it is created. Timeouts range from 5 minutes to 5 hours. The timeout begins at sandbox creation and includes all agent execution and dependency installation time.

Keep Alive Setting

Determines if the sandbox shuts down immediately after the task completes or stays active until the Maximum Duration is reached.

• Keep Alive OFF (Default): The sandbox shuts down immediately after the task completes. Use this for one-time changes where no further iteration or manual testing is needed.
• Keep Alive ON: The sandbox stays alive with all processes running (including background dev servers like npm run dev if available) until the Maximum Duration expires. Use this if you need to iterate with follow-up messages, test changes in the live environment, or manually inspect the sandbox.

You can deploy a managed version of the template to Vercel with one click. The deployment process includes:

1. Automatic Database Setup: A Neon Postgres database is automatically provisioned and connected.
2. Environment Configuration: You must provide required environment variables, including Vercel credentials and encryption keys.
3. OAuth Setup: After deployment, you must configure at least one OAuth provider (GitHub or Vercel) in your Vercel project settings to enable user authentication.

Required environment variables for deployment include SANDBOX_VERCEL_TEAM_ID, SANDBOX_VERCEL_PROJECT_ID, SANDBOX_VERCEL_TOKEN, JWE_SECRET, and ENCRYPTION_KEY.

[![Deploy with Vercel](https://vercel.com/button)](https://vercel.com/new/clone?repository-url=https%3A%2F%2Fgithub.com%2Fvercel-labs%2Fcoding-agent-template&env=SANDBOX_VERCEL_TEAM_ID,SANDBOX_VERCEL_PROJECT_ID,SANDBOX_VERCEL_TOKEN,JWE_SECRET,ENCRYPTION_KEY&envDescription=Required+environment+variables+for+the+coding+agent+template.+You+must+also+configure+at+least+one+OAuth+provider+(GitHub+or+Vercel)+after+deployment.+Optional+API+keys+can+be+added+later.&stores=%5B%7B%22type%22%3A%22postgres%22%7D%5D&project-name=coding-agent-template&repository-name=coding-agent-template)

To migrate an existing production database while preserving tasks and connectors, follow this sequence:

1. Create a system user: Insert a migration user into the users table to act as an owner for existing records.
2. Update existing records:
   • Add a user_id column to tasks and connectors.
   • Update existing rows to point to the system user.
   • Set user_id to NOT NULL and add foreign key constraints.
   • Note: You must manually encrypt existing connectors.env values using your ENCRYPTION_KEY as the type has changed from jsonb to encrypted text.
3. Run standard migrations: Use db:generate and db:push to finalize the schema.

-- 1. Create a system user
INSERT INTO users (id, provider, external_id, access_token, username, email, created_at, updated_at, last_login_at)
VALUES (
  'system-user-migration',
  'github',
  'system-migration',
  'encrypted-placeholder-token',
  'System Migration User',
  NULL,
  NOW(),
  NOW(),
  NOW()
);

-- 2. Update existing tasks
ALTER TABLE tasks ADD COLUMN user_id TEXT;
UPDATE tasks SET user_id = 'system-user-migration' WHERE user_id IS NULL;
ALTER TABLE tasks ALTER COLUMN user_id SET NOT NULL;
ALTER TABLE tasks ADD CONSTRAINT tasks_user_id_fkey FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;

-- 3. Update existing connectors
ALTER TABLE connectors ADD COLUMN user_id TEXT;
UPDATE connectors SET user_id = 'system-user-migration' WHERE user_id IS NULL;
ALTER TABLE connectors ALTER COLUMN user_id SET NOT NULL;
ALTER TABLE connectors ADD CONSTRAINT connectors_user_id_fkey FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;

Upgrading to v2.0.0 introduces breaking changes including user authentication, mandatory userId for tasks and connectors, and encrypted storage for sensitive data. Follow these steps to migrate your deployment:

1. Backup your database: Use pg_dump to create a backup of your current state.
2. Add required environment variables: Configure JWE_SECRET, ENCRYPTION_KEY, and NEXT_PUBLIC_AUTH_PROVIDERS.
3. Set up OAuth applications: Configure GitHub or Vercel OAuth credentials.
4. Handle database migration: Choose either a 'Fresh Start' (dropping tables) or 'Preserve Existing Data' (manually assigning existing records to a system user).
5. Update code: Pull the latest changes and install dependencies.
6. Verify: Test authentication and ensure user-scoped resource access works as expected.

# Create a backup of your existing database
pg_dump $POSTGRES_URL > backup-before-v2-migration.sql