Production Deployment Hell: Shopify CLI Edition

The "Just Change Dev to Prod" Disaster

My first prod deploy broke during a busy sales day. The client was pissed. Turns out you can't just run shopify app dev pointed at production - learned that after watching error logs for 4 straight hours.

Here's what broke when I tried the obvious approach:

What seemed logical:

## Seemed reasonable at 2am
shopify app dev --store=production-store.myshopify.com
## Spoiler: dev server != production deployment

What actually exploded:

• Development tunneling tried to connect to production URLs
• Interactive authentication prompts hung the deployment forever
• SQLite database got wiped on every restart
• Environment variables were mixed between dev and prod
• SSL certificates were completely fucked

TOML Files Will Ruin Your Day

Shopify CLI 3.x uses TOML files for configuration, and they're more finicky than the docs let on.

This breaks in production (learned the hard way):

## shopify.app.prod.toml - DON'T DO THIS
application_url = "http://localhost:3000"  # Whoops

This actually works:

## shopify.app.prod.toml 
name = "your-app"
client_id = "your_client_id"
application_url = "https://your-actual-domain.com"

[build]
  automatically_update_urls_on_dev = false  # CRITICAL for production

[app_proxy]
  url = "https://your-actual-domain.com/api/proxy"

The application_url has to match exactly. Burned 6 hours debugging auth loops because my TOML had https://app.example.com but I deployed to https://example-app.herokuapp.com. Shopify's TOML docs mention this but it's buried in paragraph 3.

Authentication Tokens: Expiry Hell at 2AM

Development uses interactive OAuth. Production needs CLI tokens. These tokens expire, and they'll do it at the worst possible moment.

Generate tokens in the Partner Dashboard under Settings > CLI Tokens. The CLI auth docs explain this but miss the expiry gotchas.

Token reality:

• They expire without warning (usually 60-90 days based on GitHub issues)
• Max 2 active tokens per Partner account
• Failed deploys just say "Authentication failed" - zero context
• No expiry date shown in the dashboard

Set this environment variable:

export SHOPIFY_CLI_PARTNERS_TOKEN="your_token_here"

Pro tip: Set up token expiry monitoring. I learned this after a deployment failed because the token expired at the worst possible moment.

The --force Flag Is Not Optional

The --force flag isn't a suggestion - it's mandatory for non-interactive deployments:

shopify app deploy --config=prod --force

Without --force, the CLI waits for interactive confirmation that'll never come in CI/CD. Your pipeline hangs for 10 minutes then times out. Yeah, I learned this the hard way at 11pm on a Friday.

The official Shopify CI/CD docs give you the basics, but miss the retry logic and timeout handling.

Here's what actually works:

name:

 Deploy to Production
on:
  push:
    branches: [main]
  workflow_dispatch:  # Manual trigger for emergencies

env:

  NODE_VERSION: 20

jobs:
  deploy:
    name:

 Deploy App
    runs-on: ubuntu-latest
    environment: production  # This is critical for approval gates
    timeout-minutes: 15      # Don't let it hang forever
    
    steps:

- name:

 Checkout
      uses: actions/checkout@v4
      
    
- name:

 Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: ${{ env.

NODE_VERSION }}
        cache: 'npm'
    
    
- name:

 Install dependencies
      run: npm ci --ignore-scripts  # Ignore scripts prevents malware
    
    
- name:

 Install Shopify CLI
      run: npm install -g @shopify/cli@3.84.1
    
    
- name:

 Deploy to Shopify with retry
      env:
        SHOPIFY_CLI_PARTNERS_TOKEN: ${{ secrets.

SHOPIFY_CLI_PARTNERS_TOKEN }}
        SHOPIFY_APP_URL: ${{ secrets.

SHOPIFY_APP_URL }}
      run: |
        # Retry logic added after Git

Hub Actions crapped out during a Friday deploy
        for attempt in 1 2 3; do
          if shopify app deploy --config=production --force --verbose; then
            echo "✅ Deployment successful on attempt $attempt"
            exit 0
          else
            echo "❌ Attempt $attempt failed, retrying in 30 seconds..."
            sleep 30
          fi
        done
        echo "💥 All deployment attempts failed"
        exit 1
    
    
- name:

 Notify on failure
      if: failure()
      uses: actions/github-script@v7
      with:
        script: |
          github.rest.issues.createComment({
            issue_number: context.issue.number,
            owner: context.repo.owner,
            repo: context.repo.repo,
            body: '🚨 Production deployment failed!

 Check the logs.'
          })

The Secrets That'll Make or Break Your Deployment

Required secrets in GitHub > Settings > Secrets and variables > Actions:

SHOPIFY_CLI_PARTNERS_TOKEN=shpca_abcd1234...

SHOPIFY_APP_URL=https://your-actual-domain.com
DATABASE_URL=postgresql://user:pass@host:5432/db
SESSION_SECRET=super-long-random-string-minimum-32-chars

Gotchas that cost me hours:

• Missing environment: production means every commit deploys (learned this during a late-night git rebase that deployed 15 commits at once)
• Dev/prod apps use different tokens
• Partner Dashboard shows which is which
• No timeout = hung deploys waste your 2000 free minutes fast
• The GitHub Actions documentation covers timeouts but examples don't use them

Environment Protection (Don't Skip This)

Go to Settings > Environments > production and set these up:

Required reviewers: Add at least one team member who can approve at 3am Wait timer: 10 minutes (gives you time to catch obvious fuckups) Branch protection: Only allow deployments from main

Saved my ass when I almost pushed broken code at 3am that would've fucked the checkout flow. GitHub environment protection docs explain the full setup.

When the CLI Randomly Breaks (And It Will)

Common CLI failures I've encountered in production:

Error: Authentication failed Fix: Token expired.

Generate a new one in Partner Dashboard.

Error: App not found
Fix: Wrong client_id in your TOML file or token is for wrong organization.

Error: Network request failed Fix: GitHub's network having issues.

The retry loop above handles this.

Error: Invalid configuration Fix: Your application_url doesn't match the actual deployed URL.

Error: Command hangs forever Fix: You forgot the --force flag, it's waiting for interactive input.

When Everything Goes to Shit (Rollback Process)

The CLI doesn't have a native rollback command, so you need this manual process:

1. Go to Partner Dashboard > Apps > [Your App] > App versions
2. Find the last working version and click "Make current"
3. Wait 2-5 minutes for propagation (users will see old version)
4. Fix the issue locally and deploy again

Pro tip: Tag your releases so you know which commit to revert to:

- name:

 Tag release
  run: git tag "release-$(date +%Y%m%d-%H%M%S)"