- Replace community Deno runtime with @vercel/sandbox SDK
- Next.js API routes create ephemeral sandbox VMs per execution
- Each tool execution: create VM → npm install → run → cleanup
- node22 runtime in sandbox handles npm packages natively
- Region pinned to iad1 (only region with Sandbox support)
- Proper authentication support via EXECUTOR_API_KEY
This provides true isolation - each tool runs in its own VM that's
destroyed after execution. More secure than shared serverless.
- Replace Next.js app router with pure Deno API functions
- Use vercel-deno@3.0.0 community runtime for native HTTP imports
- Deno natively supports importing from esm.sh URLs
- Simplified template: just api/health.ts and api/execute-tool.ts
- Remove unnecessary React/Next.js dependencies
- Update README with new architecture documentation
This matches the Railway executor's Deno-based approach but runs on
the user's own Vercel account. The Deno runtime enables dynamic
imports from esm.sh without any special setup.
- Add executor configuration to Collection and Agent models in Prisma schema
- Create ExecutorConfigPanel component for selecting default or custom executors
- Add executor resolution logic with cascade (Agent → Collection → System Default)
- Create /api/executors/verify endpoint to test custom executor connectivity
- Add executor documentation page at /docs/executors with API specification
- Create deployable Vercel executor template in templates/vercel-executor/
- Update MCP handlers and agent tool execution to use configurable executors
- Add executor types and schemas to @tpmjs/types package
Users can now deploy their own executor instances and configure collections
or agents to use custom executors instead of the TPMJS default executor.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
