Hi Jonghun!
Great question. You’ve touched on some important aspects of Vercel’s environment handling. Let me clarify a few points and suggest a workable solution:
- The Pro plan limitation you mentioned applies to custom environment variables, not system ones like
original_environmentandenvironment. These system variables are internal to Vercel and can’t be directly overridden, regardless of the plan. - You’re correct that the API modifies
original_environmentandenvironment. This is by design and part of Vercel’s deployment process. - Instead of trying to override these system values, you should:
a) Use Vercel’s built-in environment detection
b) Structure your application to handle environment-specific logic based on other available environment variables
Here’s an example of how you can achieve this in your GitHub Actions workflow:
name: Deploy to Vercel
on:
push:
branches: [main, staging]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Deploy to Vercel
env:
VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
run: |
npx vercel --token ${VERCEL_TOKEN} \
--env APP_ENV=${GITHUB_REF##*/} \
--prod
This approach:
- Uses the GitHub ref to set a custom
APP_ENVvariable - Deploys to Vercel using their CLI, which respects the automatic branch detection
- Allows you to use
APP_ENVin your application to determine the environment, rather than relying on Vercel’s system variables
In your application code, you can then use APP_ENV (or VERCEL_ENV if you prefer Vercel’s built-in variable) to handle environment-specific logic.
Let us know how you get on!