Middleware Architecture ("Branch Observer") for Batched Deployments & Optimized CI/CD Workflow

[alizaenazet]

Hi community,

I am opening this discussion to address a common scalability/workflow challenge inherent to Git-based CMSs and to propose an architectural solution (a middleware service) that I am planning to build. I would love to hear your thoughts, feedback, or existing solutions regarding this.

1. The Problem: "The CI/CD Spam" & Atomic Updates

In a Git-based CMS, the workflow is typically: Save Button -> Git Commit -> Push -> CI/CD Build -> Deploy.

While this works great for infrequent updates, it becomes problematic in real-world production scenarios, especially with non-technical editors:

• Wasted Resources: If an editor fixes typos in 5 different articles within 10 minutes, we trigger 5 separate CI/CD builds.
• Race Conditions: Multiple builds running concurrently or canceling each other can lead to deployment race conditions or corrupted states on the server.
• Lack of "Staging": Editors often want to save their work (draft) without immediately updating the live production site, but they don't know how to handle Pull Requests manually on GitHub.

2. Current Workarounds & Limitations

• Debouncing in CI (Github Actions): We can set concurrency: cancel-in-progress, but this is aggressive and can kill a deployment process at a critical stage (e.g., during file swapping), potentially causing downtime.
• Manual PR Merging: Asking non-technical clients to log into GitHub and merge a "draft" branch to "main" destroys the seamless CMS experience.

3. Proposed Solution: The "Branch Observer" Service

To solve this without switching to a heavy API-based CMS (like Strapi/Directus), I am proposing a lightweight middleware service (likely written in Go + SQLite) that acts as a traffic controller.

The Workflow:

1. Sveltia Configuration: The CMS is configured to commit everything to a draft branch (not main).
2. The Observer Service: A small Docker container running on the server listening to GitHub Webhooks.
3. Debounce Logic:

• When a commit hits draft, the service starts a Timer (e.g., 10 minutes).
• If another commit comes in within that window, the timer resets.
• Action: Once the timer expires (silence for 10 mins), the service automatically performs a git merge draft -> main and pushes, triggering one single Production Build.

4. Force Deploy (The "Emergency Button"):

• We can have a specific file (e.g., _trigger_deploy.json) in the repo.
• If the service detects a change in this specific file (via a toggle in Sveltia), it bypasses the timer and merges immediately.

Architecture Goals:

• Lightweight: A simple Go binary + SQLite (for state persistence). minimal RAM usage.
• Multi-tenant: One service instance can handle webhooks for multiple repositories/projects.
• Zero-Downtime: Allows the admin to "spam" save button without stressing the production server.

4. Questions for the Community

Before I start building this "Branch Observer" service:

1. Is this a common pattern? How do you currently handle "batch updates" or prevent CI/CD overload when editors are active?
2. Is there an existing tool? Does a tool like this already exist in the ecosystem that integrates well with Sveltia/Decap workflows?
3. Is it worth it? In your opinion, does adding this middleware layer justify staying with a Git-based CMS? Or at this point of complexity, would you usually recommend migrating to an API-based Headless CMS?

I believe this tool could bridge the gap between the simplicity of Git-based CMS and the robustness of dynamic CMSs, allowing us to keep the "Serverless/Static" benefits while improving the Editor UX.

Looking forward to you guys for insights!

[alizaenazet]

Hi @kyoshino, (apologies for the direct mention)

While waiting for feedback on the architecture above, I wanted to ask a more fundamental question about Sveltia's core behavior regarding data persistence:

Is strictly "1 Save button click = 1 Commit" the intended behavior for all scenarios?

In a production environment where editors might save frequent small changes (typos, drafts, image swaps), this triggers a massive amount of commits and CI/CD builds.

• Is there any built-in mechanism in Sveltia (or planned) to "batch" these saves?
• Or is the expectation that users should handle this strictly via Git provider settings (like GitHub Actions concurrency groups) or external workflows?

I just want to confirm I'm not missing a configuration option before I commit to building the external middleware solution I proposed above.

Thanks!

[kyoshino]

Sveltia CMS supports the [skip ci] commit message prefix. Does this work for you?

• Disabling Automatic Deployments

[alizaenazet]

Thank you so much for pointing this out, @kyoshino!

I completely overlooked this section in the documentation. This feature is exactly what I was looking for it solves the "commit spam" issue elegantly without needing any complex middleware infrastructure.

I will implement the [skip ci] configuration right away. Closing this discussion as resolved. Thanks again!