Secrets and Environments

In a professional MERN stack or Docusaurus project, your code needs to talk to external services like MongoDB Atlas, AWS, or Stripe. These services require "Keys" or "Passwords."

At CodeHarborHub, we have one golden rule: NEVER commit secrets to GitHub. If a password is in your code, it is no longer a secret.

Why Not Commit Secrets?

Even if you delete the secret from your code later, it still exists in the Git History. Anyone can go back and find it. This is a huge security risk. Instead, we use GitHub's built-in Secrets feature to store sensitive information safely. This way, your workflows can access the secrets without exposing them in the code or logs.

For example: If you have a MongoDB connection string, you would store it as a secret called MONGODB_URI and then reference it in your workflow without ever showing the actual value.

What are GitHub Secrets?

GitHub Secrets are encrypted environment variables that you create in your repository settings. They are only available to your GitHub Actions workflows and are never visible in the logs (GitHub will mask them with ***).

How to Create a Secret:

1. Navigate to your repository on GitHub.
2. Go to Settings > Secrets and variables > Actions.
3. Click New repository secret.
4. Name: MONGODB_URI | Value: mongodb+srv://username:password@cluster.mongodb.net/

Using Secrets in your Workflow

Once a secret is saved, you can "inject" it into your code using the ${{ secrets.NAME }} syntax.

deploy.yml

name: Production Deployment
on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Deploy to AWS
        run: ./deploy-script.sh
        env:
          # Injecting the secrets into the environment
          AWS_ACCESS_KEY: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          DB_CONNECTION: ${{ secrets.MONGODB_URI }}

Environments & Protection Rules

An Environment is a logical target for your deployment (e.g., Production, Staging, Development). This is an "Industrial Level" feature that adds a layer of safety.

Why use Environments?

• Manual Approvals: You can set a rule that says: "The code cannot deploy to Production until the Team Lead clicks 'Approve'."
• Environment Secrets: You can have a DATABASE_URL secret for Staging and a different DATABASE_URL for Production. This way, your staging environment can use a test database, while production uses the real one.

deploy.yml

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: Production # Connects this job to the Production rules
    steps:
      - run: echo "Deploying to the live CodeHarborHub site..."

The "Zero-Trust" Security Flow

Comparison: Secrets vs. Variables

Feature	GitHub Secrets	Configuration Variables
Visibility	Hidden (***) in logs.	Visible in logs.
Best For	Passwords, API Keys, SSH Keys.	App Ports, Themes, Feature Flags.
Editability	Cannot be viewed after saving.	Can be viewed and edited anytime.

Professional Security Rules

1. Least Privilege: Only give your GitHub Action the permissions it absolutely needs.
2. Rotation: Change your secrets every 90 days.
3. No Echo: Never try to echo ${{ secrets.MY_KEY }} into a file that is later uploaded as a public artifact.
4. Review: Always check which "Third-Party Actions" you are using. Do you trust them with your secrets?
5. Use Environments: For production deployments, always use an Environment with manual approval to add an extra layer of security.

Security Warning

If you accidentally commit a secret to your code, it is compromised. Changing the file and pushing again doesn't help because it stays in the Git History. You must Rotate (change) the key immediately on the provider's website (e.g., AWS or MongoDB).

Final Graduation Challenge

1. Go to your GitHub repo and create a secret called CODENAME with the value Goldfish.
2. Create a workflow that has one step: run: echo "The secret is ${{ secrets.CODENAME }}".
3. Run the workflow and check the logs. Notice how GitHub replaces Goldfish with ***.
4. Congratulations! You are now a DevOps-ready developer!