Bringing Linode Back Under GitHub Control

— Resolving Environment Drift and Establishing a Manual CI/CD Flow —

Background

• The frontend is hosted on Vercel.
• The CMS (Payload + MongoDB Atlas) runs on Linode in a Docker container.
• Over time, the production code on Linode diverged from the local repository.
• As a result, we ended up in a state where local development could no longer reproduce production — let’s call it the “Lost in Linode” problem.

This situation created risks:

• Debugging locally was impossible.
• No one was sure which version of the code was the “source of truth.”

Challenges

1. Environment Drift
2. • After the initial deployment, hotfixes and changes were applied directly on Linode without being synced back.
   • Config differences (Caddy, Payload) grew over time.
2. Partial Git Management
3. • The payload directory wasn’t fully committed or synced.
   • git pull didn’t restore the same state as production.
3. Confusing Environment Variables
4. • .env vs .env.local usage was inconsistent.
   • Docker Compose referenced .env.local, but production only had .env.

Steps Toward Resolution

1. Backing Up Production

• Used docker cp to copy the Payload code from the container back to the Linode host.
• Transferred it via scp to local, then replaced the local payload directory.
• Committed the production state to GitHub.
  → This reestablished GitHub as the single source of truth.

2. Switching Linode to Git Workflow

• Initialized the project on Linode as a Git repo.
• Standardized the deployment flow:
  git pull origin main
  docker compose build && docker compose up -d
  
• From now on, Linode no longer drifts: it always matches GitHub main.

3. Cleaning Up Environment Variables

• Decided:
• • Production → .env
  • Local development → .env.local
• Added docker-compose.override.yml to point to .env.local only in dev.
• Warnings remain, but prod and dev are now safely separated.

What We Learned (Framed in General IT Skills)

• Configuration Management
• • By treating GitHub as the single source of truth, we eliminated environment drift.
• Deployment Standardization
• • On Linode, deployment is always git pull → docker compose up.
  • Ensures reproducibility and reduces human error.
• Environment Variable Management
• • Clear separation between .env (prod) and .env.local (dev).
  • Early step toward proper Secrets Management.
• Manual CI/CD
• • Not automated yet, but we established a repeatable cycle:
    push → pull → build → up → test.
  • This is the first building block toward full CI/CD automation.

Conclusion

This work was essentially an exercise in DevOps fundamentals:

• Resolved code drift by re-syncing Linode with GitHub
• Standardized deployment workflows
• Organized environment variables properly

With this, the “Lost in Linode” issue is gone, and future deployments are much safer.