API Environment Variables
The API package (packages/api/) requires environment variables for database connections, AWS service integration, and runtime configuration.
Local Development (.env file)
For local development, create a.env file in packages/api/:
API Variables Reference
Runtime Configuration
Database
Local Development: Point to your local PostgreSQL instance.Production: The Lambda’s
DATABASE_URL is constructed automatically by CloudFormation using Secrets Manager for the password.AWS Cognito
Get these values from the AWS Console → Cognito → User Pools after deploying infrastructure.
CORS Configuration
S3 File Storage
The bucket is created by the CloudFormation stack. Reference the bucket name from the stack outputs.
Worker Lambda
The API Lambda invokes the Worker Lambda asynchronously for long-running Bedrock operations. The function name is set by CloudFormation.
Complete API .env Example
Web Environment Variables
The Web package (packages/web/) uses Next.js and supports environment variables prefixed with NEXT_PUBLIC_ for client-side access.
Web Variables Reference
API Configuration
Client-Side Access: Variables prefixed with
NEXT_PUBLIC_ are embedded in the browser bundle. Do NOT use this prefix for sensitive credentials.Complete Web .env Example
The Web package has minimal environment configuration since it’s a static export deployed to S3. Most configuration happens on the API side.
Lambda Environment Variables (Production)
In production, Lambda functions receive environment variables through CloudFormation. You don’t need to set these manually—they’re configured in the infrastructure stack.API Lambda Environment
Worker Lambda Environment
Environment-Specific Configuration
Development
- Local PostgreSQL database
- API on
http://localhost:3001 - Web on
http://localhost:3000 - Mock AWS services or use dev AWS account
Staging
- RDS PostgreSQL in private VPC
- API Lambda behind API Gateway
- Web static export on S3 + CloudFront
- Separate Cognito User Pool
- AWS Bedrock with dev model access
Production
- Production RDS instance
- High-performance Lambda configurations
- Production Cognito User Pool
- CloudFront with custom domain
- Production Bedrock access
Security Best Practices
What NOT to commit:
.env(actual environment variables)- Database passwords
- AWS access keys
- Cognito client secrets
- API keys or tokens
What IS safe to commit:
.env.example(template with placeholder values)- CloudFormation templates (use
!Suband Secrets Manager) - Variable names and descriptions (this documentation)
Validation
Check API Configuration
Verify the API can connect to services:Check Web Configuration
Verify the Web app can reach the API:Check Database Connection
Test Prisma connection:Troubleshooting
”Prisma Client could not find your DATABASE_URL”
Cause:DATABASE_URL is not set in your .env file.
Solution:
“Cannot connect to Cognito”
Cause: InvalidCOGNITO_USER_POOL_ID or COGNITO_CLIENT_ID.
Solution: Get correct values from AWS Console → Cognito → User Pools.
”CORS error in browser”
Cause:CORS_ORIGIN doesn’t match the frontend URL.
Solution: Update CORS_ORIGIN in packages/api/.env:
Lambda “Connection timeout” in production
Cause: Lambda can’t reach RDS due to missingDATABASE_URL or VPC configuration.
Solution: Check CloudWatch logs and verify:
DATABASE_URLis set in Lambda environment- Lambda is in the same VPC as RDS
- Security groups allow traffic on port 5432
Next Steps
- Set up local development environment
- Deploy infrastructure using CloudFormation
- Configure AWS services (Cognito, RDS, Bedrock)
- Deploy API and Web packages to AWS