fix(apikeys): pinned api key to track API key a workflow is deployed with

[icecrasher321]

Summary

Two separate bugs:

1. Deploy Modal always displayed the default key as being used -- i.e. the first one created.
2. All keys made by the user would work right now -- not just the one the workflow was deployed with [latter should be the behavior]

This PR fixes both these issues.

Type of Change

• Bug fix

Testing

Tested manually by making multiple keys and deploying. Then I curled with the one the workflow was deployed with versus the other ones on the list. Only the deployed one (i.e. pinned) works.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sim	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 9, 2025 6:37am

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
docs	⬜️ Skipped (Inspect)			Aug 9, 2025 6:37am

[greptile-apps]

Greptile Summary

This PR implements API key pinning for workflow deployments to fix two critical bugs in the deployment system. The changes introduce a pinnedApiKey field to the workflow schema that stores which specific API key a workflow was deployed with, ensuring proper isolation and security.

The core changes include:

1. Database Schema Updates: Added a nullable pinned_api_key text column to the workflow table via migration 0071, allowing workflows to store their associated API key

2. API Key Selection Logic: Modified the deployment route (/api/workflows/[id]/deploy) to intelligently select API keys - preferring pinned keys when available, falling back to the most recently used key, and allowing explicit key selection during deployment

3. Authentication Middleware: Updated workflow middleware to enforce API key restrictions - if a workflow has a pinned key, only that specific key is accepted for execution; otherwise it falls back to validating any user-owned key

4. UI Improvements: Enhanced the Deploy Modal to correctly display the pinned API key instead of always showing the first created key, and improved form handling by switching from button clicks to proper form submission

5. Backward Compatibility: Existing workflows without pinned keys continue to work with any user-owned API key, while new deployments can explicitly pin keys for tighter security

The implementation maintains the existing user experience while adding proper API key isolation per deployment. When a workflow is deployed with a specific API key, that key becomes "pinned" to the workflow, and subsequent API calls must use that exact key. This provides better security control and clearer user feedback about which API key is actively being used for each deployment.

Confidence score: 4/5

• This PR addresses a legitimate security concern with a well-architected solution that maintains backward compatibility
• The implementation follows established patterns and includes proper database migrations with comprehensive schema updates
• Pay close attention to the middleware authentication logic and ensure the pinned key validation doesn't break existing deployed workflows

_{9 files reviewed, 2 comments}

_{Edit Code Review Bot Settings | Greptile}