Web Deployment

Web Deployment

Description

Deploy websites to the internet and create databases. Supports Vercel (static/fast APIs), Railway (long-running operations), and Supabase (database).

Triggers

• deploy
• website
• hosting
• vercel
• railway
• supabase
• go live
• put online
• launch
• production
• make it live

Instructions

Provider Decision Framework

Pick the right hosting provider based on what the project does:

Critical: Vercel has a 10-second serverless function timeout on free tier (60s on Pro). Any API route that calls OpenAI/Anthropic, does heavy processing, or streams data will fail on Vercel. Always use Railway for those projects.

The deploy_website tool with provider: "auto" detects this automatically by scanning API routes and package.json dependencies.

Deployment Workflow

1. Scaffold the project (Next.js, etc.) and get it building locally
2. Create database with create_database if the project needs persistence — just pass a project name. The tool returns url, anon_key, service_role_key, and db_url automatically. Never ask the user for these keys.
3. Wire env vars — pass the credentials from the create_database result to deploy_website via env_vars:

   env_vars: {
     "NEXT_PUBLIC_SUPABASE_URL": <url from create_database>,
     "NEXT_PUBLIC_SUPABASE_ANON_KEY": <anon_key from create_database>,
     "SUPABASE_SERVICE_ROLE_KEY": <service_role_key from create_database>,
     "DATABASE_URL": <db_url from create_database>
   }
   

4. Build locally — always run npm run build before deploying to catch errors
5. Deploy with deploy_website
6. Verify — check the returned URL in the browser

Important: The only token the user sets up is the Supabase access token in the vault (vault_set key=supabase_access_token value=...). All per-project keys are auto-generated by create_database. Do not ask the user for anon keys, service role keys, or database URLs.

Provider-Specific Notes

Vercel:

• Uses vercel --yes --token $TOKEN --prod (non-interactive)
• Env vars set via vercel env add
• Token stored in vault as vercel_token
• Free tier: unlimited static sites, 10s function timeout

Railway:

• Uses RAILWAY_TOKEN=$TOKEN railway up --detach
• Env vars set via railway variables set KEY=VALUE
• Token stored in vault as railway_token
• Free tier: $5/month credit, no timeout limits

Supabase:

• Created via Management API (no CLI needed)
• Token stored in vault as supabase_access_token
• Free tier: 2 projects, 500MB database, 1GB file storage
• Includes Postgres, Auth, Storage, Realtime out of the box

Anti-Patterns

• Don't deploy to Vercel if any API route calls an LLM — it will timeout. The auto-detect catches most cases but double-check manually.
• Don't hardcode API keys — use env_vars parameter on deploy_website to inject them into the platform's environment.
• Don't skip npm run build — deploying broken code wastes time and deploy minutes. Build locally first, fix errors, then deploy.
• Don't create multiple Supabase projects for the same app — one project gives you database + auth + storage + realtime. Use tables, not projects, to separate concerns.
• Don't forget to pass database credentials — the most common deployment failure is the app trying to connect to Supabase without the URL/key env vars.

Verify

• The deploy command was actually run and the build/log output (or deploy URL) is captured
• The deployed URL was opened and returned a 2xx; key routes were sampled, not just the index
• Environment variables required by the app are present in the target environment; missing-var failures were ruled out
• A rollback plan (previous deployment ID, git SHA, or one-line revert command) is documented before promoting to production
• Health/observability check (logs, error tracker, status page) was inspected post-deploy; baseline error rate is recorded
• DNS / domain / SSL configuration was confirmed, not assumed to carry over from previous deploys