← Nuxt setup guides

Pick the right branch

When you connect a Nuxt site to 42flows, you tell us two things: which repo to write to, and which branch to commit to. That branch decision is the difference between "publish = live" and "publish = waiting for a human."

How the flow actually works

  1. You hit Publish in 42flows.
  2. 42flows writes a .md file into your repo's content/ directory and pushes a commit to the branch you configured.
  3. From that moment on, your repo's CI/CD takes over. 42flows does not deploy anything — it just delivers the file.

So the answer to "why isn't my article live yet?" is almost always: the commit landed on a branch your deploy pipeline doesn't watch.

The two setups we see

Point 42flows at the branch your production auto-deploys from. On most Nuxt repos that's main.

  • Target branch in 42flows: main
  • What happens on publish: article commit → main → CI/CD → production
  • Human steps: zero
  • Best for: solo founders, small teams, sites where editorial review happens inside 42flows before hitting Publish

Setup B — Publish = staged, ship on merge

Point 42flows at a staging branch (often develop). Articles collect there until a human merges develop → main.

  • Target branch in 42flows: develop (or staging, content-staging, etc.)
  • What happens on publish: article commit → develop → sits until someone opens a develop → main PR → merge → production
  • Human steps: one PR merge per batch
  • Best for: teams that want a second set of eyes on published content, or repos where develop is already the collaboration branch for other work

How to pick

Ask: once I click Publish in 42flows, do I want anyone else to approve it before it's live?

  • No → Setup A. Use main.
  • Yes → Setup B. Use a staging branch.

Don't pick Setup B "just in case" — it adds a step that gets forgotten. The most common complaint we hear is "I published but it never went live" — and it's nearly always a Setup B user who forgot to merge.

Gotchas once it's live

Even with Setup A, an article may not appear instantly on every page. The article's own URL renders fresh on first hit, but:

  • Nuxt ISR caches list/hub pages (category indexes, tag pages, the blog home). If you have isr: 3600 on a hub route, that list can show the old content for up to an hour after publish. Options: shorten the ISR window on hubs, or hit the new article URL once to warm it and wait out the hub cache.
  • Cloudflare / CDN edge cache may hold the old HTML on long-cached paths. If a page doesn't update after a deploy, check cf-cache-status and purge if needed.
  • Service worker caching on your own site can serve stale HTML to returning visitors. Make sure your SW cache key is tied to your build/version so deploys bust it automatically.

Changing the target later

You can change the target branch at any time in your 42flows site settings. New publishes go to the new branch; articles already delivered stay where they were. No backfill — if you need old articles on a different branch, merge or cherry-pick them yourself.