1. You're not caching dependencies and it's costing you minutes per run.

2. You're pushing to Docker Hub when GHCR is sitting right there.

3. Your production deploy is one accidental push away from triggering.

4. You're putting everything in secrets when half of it should be in vars.

5. You're pinning actions/checkout@v4 but running on ubuntu-latest. Most GitHub Actions tutorials get you to a green checkmark. Very few of them help you understand why your pipeline takes 8 minutes when it should take 2, or why your production deploy triggered from a feature branch PR at 11pm on a Friday. After working with a lot of engineering teams setting up CI/CD from scratch, these are the patterns that come up again and again. The single fastest win in any GitHub Actions pipeline is dependency caching. Most people skip it because the pipeline "works." It does work. It's just running npm install or pip install from scratch on every single run. The hashFiles key is the part that matters: the cache invalidates automatically when your lockfile changes, so you always get fresh deps when you actually update something. When it hits, you skip the install entirely. On a mid-size Node project, this typically cuts 2–4 minutes per run. GitHub Container Registry (GHCR) is built into GitHub and works with the GITHUB_TOKEN that already exists in every workflow. No extra secrets, no separate account, no rate limiting surprises. The catch that trips people up: you need to explicitly grant the packages: write permission in your job definition. Without it, the push will fail with a misleading auth error. Then authenticate like this: No secrets to rotate, no third-party dependency, and images are scoped to your repo automatically. If your workflow deploys to production on every push to main, that's fine until someone force-pushes a fix, a bot commits a version bump, or a merge goes sideways. The pattern that solves this is a separate deploy job with an if condition and needs chaining: The environment: production line is the one most people miss. If you've configured environment protection rules in GitHub (Settings → Environments), this gates the deploy behind required reviewers or a manual approval. It's free on public repos and included in Team plans for private ones. This means: automated deploys from main, but with a human checkpoint before anything touches production. GitHub has two distinct places for pipeline configuration: Secrets (encrypted, write-only, for credentials) and Variables (plaintext, readable in UI, for config values). Most teams put everything in secrets. That means your APP_ENV=production or LOG_LEVEL=info is encrypted and invisible in the GitHub UI, which makes debugging and auditing unnecessarily painful. Variables are accessed with the vars context: Practical rule: if the value isn't a credential, a token, or a key, it belongs in vars. This is a subtle one. Pinning action versions (e.g., actions/checkout@v4) is good practice, it prevents upstream changes from breaking your pipeline without warning. But then running runs-on: ubuntu-latest undoes some of that stability. ubuntu-latest is an alias that GitHub updates periodically (currently ubuntu-24.04, soon to rotate again), and those updates can change pre-installed tool versions, breaking pipelines that depend on system-level tools. If stability matters more than getting the latest runner features: You'll need to update it manually when the version reaches end-of-life, but you control when that happens, not GitHub's release schedule. These are the patterns that separate a "it works" pipeline from one that's actually reliable in production. The full step-by-step guide covering the complete pipeline structure, including Kubernetes deploy jobs, multi-environment promotion workflows, and secrets management at scale, is at thegoodshell.com. Happy to answer questions in the comments if you are working through any of these. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse