SvelteKit SSR deploy fails with "Failed to replace Run service" - ALREADY_EXISTS revision conflict

[BBream]

[REQUIRED] Environment info

• firebase-tools: 15.11.0 (also reproduced with 15.10.1)
• Platform: macOS (local) / Ubuntu (GitHub Actions)
• Node.js: 22.22.1 (also reproduced with 20.19.3)
• Framework: SvelteKit 2 + @sveltejs/adapter-node

First observed: March 19, 2026 at approximately 12:00 UTC (9 PM KST). The same deployment pipeline last succeeded at approximately 09:00 UTC (6 PM KST) on the same day — no project or CI configuration changes were made between the two runs.

[REQUIRED] Test case

SvelteKit project deployed to Firebase Hosting with webframeworks experiment enabled. firebase.json:

{
  "hosting": {
    "target": "app",
    "source": "./",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "frameworksBackend": {
      "region": "asia-northeast3"
    }
  }
}

[REQUIRED] Steps to reproduce

1. Enable FIREBASE_CLI_EXPERIMENTS=webframeworks
2. Run npx firebase-tools hosting:channel:deploy <channel> --only app --expires 7d --project <project-id>
3. Also fails with firebase deploy --only hosting (live channel)

[REQUIRED] Expected behavior

Hosting deployment succeeds, Cloud Run service is updated with the new revision and traffic tag.

[REQUIRED] Actual behavior

Cloud Functions create/update succeeds, but immediately after, hosting: finalizing version fails:

✔ functions[...<ssr-function-name>(<region>)] Successful create operation.
i hosting[<site-name>]: finalizing version...
Error: Failed to replace Run service projects/<project-number>/locations/<region>/services/<ssr-function-name>

Debug log shows:

PUT https://run.googleapis.com/v1/projects/<project-number>/locations/<region>/services/<ssr-function-name>
HTTP 409: Revision named '<ssr-function-name>-00002-xxx' with different configuration already exists.

Root cause analysis

• Cloud Functions deployment creates revision 00001 with a specific configuration
• Hosting finalize then calls ReplaceService (PUT) to add a traffic tag (fh-xxxx) to the same service
• This PUT request tries to create revision 00002 but with a different image digest/configuration than what Cloud Functions just built
• Result: 409 ALREADY_EXISTS

Reproduction rate

100% — fails on every attempt across:

• Local CLI and GitHub Actions
• Node.js 20 and 22
• firebase-tools 15.10.1 and 15.11.0
• asia-east1 and asia-northeast3 regions
• Both hosting:channel:deploy and firebase deploy --only hosting
• Both fresh function creation and existing function update

[QtnRBT]

Hi there, exact same issue with NextJS, also using firebase tools, also using Hosting. It only fails with hosting though, my SSR seems to be deployed and serving traffic in Cloud Run.
I had multiple deploy fails and these fails corresponded to versions not being push on Hosting, fine on Cloud Run...

[service-paradis]

Same issue here.

Environment:

• firebase-tools: 15.11.0 (via npx firebase-tools@latest in GitHub Actions)
• Framework: Next.js 16 (App Router, SSR)
• Platform: Ubuntu / GitHub Actions
• Node.js: 22.22.1
• Region: northamerica-northeast1

The deployment always fails at hosting: finalizing version with 409 ALREADY_EXISTS. Retrying the workflow 3+ times produces the exact same error each time. Fails 100% of the time. The Cloud Run revision is visible in Google Cloud Console immediately before the error occurs.

[QtnRBT]

I can report it has worked once with my local setup on 15.7.0, however, second push and the next ones it fails now, even locally.

[QtnRBT]

@service-paradis do you have any update on this ? Is it still failing on your side ? Could it be a google related issue rather than a lib issue ?

[aalej]

Hey folks, I'm currently able to reproduce the issue when deploying to asia-east1. From what I can gather, this may be affecting certain regions since when I tried deploying to us-central1, no errors were raised. I'll check this with our engineering team.

[vladimes]

Same issue here.

Environment:

• firebase-tools: 15.11.0
• Framework: SvelteKit 2 + @sveltejs/adapter-node
• Platform: macOS / Windows 11
• Node.js: 22
• Region: europe-west3

The deployment always fails at hosting: 409, Revision named '-0000Y-xxx' with different configuration already exists. Retrying the deploy in multiple projects multiple times and it produces the exact same error each time. Fails 100% of the attempts.

The Cloud Run revision is visible in Google Cloud Console. I tried to add the Revision tag manually via UI but it fails as well - "Failed to save revision tags. Details: Revision named '-0000Y-xxx' with different configuration already exists."

[VytasKan]

same issue can report firebase-tools: 15.11.0 europe-west2
Revision named 'ssrca-00001-nuc' with different configuration already exists.

[ThatOneByte]

Failed to replace Run service - same issue, Don't know what to do. It worked ok yesterday.

[NathanNoye]

Same issue here, stopped working randomly a few hours ago

[yhs0329]

I resolved the issue by running 'firebase experiments:disable pintags' before proceeding with the deployment.
I learned that in the process of reading the Cloud Run service and tagging the latest revision, firebase-tools attempts to replace the entire service using a PUT request instead of a PATCH. This conflict with Cloud Run's revision immutability can cause "Failed to replace Run service" or revision conflict errors. After running 'firebase experiments:disable pintags' and then 'firebase deploy', the deployment succeeded immediately.

Specifically, I followed these steps:

1. Deleted the existing revision service in GCP Cloud Run.
2. Cleared the local cache using 'remove-Item -Recurse -Force .firebase'.
3. Executed 'firebase experiments:disable pintags'.
4. Executed 'firebase deploy'.

I hope this helps.
I used this as a temporary workaround because the client's homepage was down.
Please note that according to the Firebase documentation, pinTag: true is a feature that pins Hosting's static assets and the dynamic backend (Functions 2nd gen or Cloud Run revision) to the same deployment version. Therefore, you should be aware that disabling this will stop ensuring version synchronization and rollback consistency between Hosting and the SSR backend.

[MinSeungHyun]

@yhs0329's workaround works for me. Thanks! 감사합니다.

[NathanNoye]

Another not-so-pleasant option is to switch to App Hosting. I just switched mine over since it avoids the issue entirely. Still working through a few changes on my end but seems to be working.

[ThatOneByte]

@yhs0329's workaround works for me as well. Thanks you so much! I don't really know what I did but it worked :D

[hstemplewski]

I have the same problem using the GH Actions https://github.com/FirebaseExtended/action-hosting-deploy/tree/v0/ with Next.js and the work around is not working for preview channels