Improve Docker build caching for staging workflow

[andrasbacsai]

Changes

• Add registry cache persistence to fallback when GHA cache expires
• Optimize static-assets Docker stage with selective COPY for frontend files only
• Reduces build context from 44MB to 3.2MB, preventing cache invalidation on backend changes

Benefits

• Backend-only changes no longer trigger unnecessary frontend rebuilds
• Persistent cache via registry image as fallback for GHA cache expiration
• Faster builds on subsequent runs due to improved layer caching

[andrasbacsai]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Walkthrough

This pull request modifies Docker build workflows and the production Dockerfile to improve build efficiency through caching strategies. The GitHub Actions workflows (both production and staging) have been updated to implement Docker Buildx setup and multi-layered caching, using both GitHub Actions cache and registry cache destinations for different architectures. The production Dockerfile's frontend assets build stage has been refactored to use granular COPY commands organized into separate layers—isolating dependencies, build configuration, frontend source files, and Blade templates—to optimize Docker layer caching without altering the build process itself.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch optimize-github-actions

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2a21b18 and 1807eca.

📒 Files selected for processing (3)

• .github/workflows/coolify-production-build.yml (2 hunks)
• .github/workflows/coolify-staging-build.yml (1 hunks)
• docker/production/Dockerfile (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-12-08T20:23:33.775Z

Learnt from: CR
Repo: coollabsio/coolify PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-08T20:23:33.775Z
Learning: Frontend development commands: Run `npm run dev` to start Vite development server for frontend assets, and `npm run build` to build frontend assets for production

Applied to files:

• docker/production/Dockerfile

🔇 Additional comments (4)

.github/workflows/coolify-production-build.yml (2)

62-63: Excellent cache strategy—this is how you make servers sweat for you, not the other way around!

The Docker Buildx setup is properly positioned and uses mode=max to cache all layers in multistage builds, which is correct for your multi-stage frontend compilation. Your tiered cache fallback (GHA → registry) ensures that even when GitHub's cache expires after 7 days, the registry persists as a resilient backup.

---

75-80: Cache layer strategy is chef's kiss—no more throwing away good layers when backend changes happen.

The dual cache setup with per-architecture scoping is perfect for multi-platform builds. mode=max caches all intermediate layers even from intermediate steps, and while min cache is smaller, max is more likely to get cache hits. The fallback from GHA (fast, short-lived) to registry (persistent) is exactly what you need for reliable multi-arch builds.

One small thing to verify: ensure the prod-buildcache image refs don't accumulate unbounded over time—you may want to set up a cleanup policy or lifecycle rule in your registry if you haven't already.

.github/workflows/coolify-staging-build.yml (1)

83-85: Symmetric caching strategy is beautiful—you're now reading and writing to the same places.

The expansion to dual cache-to destinations (GHA + registry) now mirrors your cache-from sources, which is the correct pattern. Registry cache with mode=max supports caching intermediate layers in multi-stage builds and increases chances of cache hits on subsequent builds. The separation between build scope (staging) and prod-build scope (production) keeps your pipelines isolated.

docker/production/Dockerfile (1)

41-59: Pure elegance—you've essentially created a gluten-free build pipeline (no unnecessary cruft!), and the Docker layer caching gods are smiling on you.

The refactored layer strategy is textbook Docker optimization. Since dependencies change relatively infrequently compared to source code, a good strategy is to copy the dependency manifest and download them first, allowing those layers to be cached. You've taken this further by isolating rarely-changing build configs into a separate layer, then frontend sources, then templates—each can now be cached independently.

The 44 MB → 3.2 MB reduction in build context is the real win here: backend changes no longer waste frontend rebuild cycles. The Blade template inclusion for Tailwind class detection is correct and necessary.

Asset coverage verified: All subdirectories in resources/ (css/, js/, fonts/, views/) are accounted for in the Dockerfile. The vite build process has everything it needs. No missing asset directories.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}