Is 3.13 an option for 3.10 EOL: Fresh 3.14 app returns 503 from SCM with no content deployed at all — while a fresh 3.10 app accepted a deploy immediately

Question

Is 3.13 an option for 3.10 EOL: Fresh 3.14 app returns 503 from SCM with no content deployed at all — while a fresh 3.10 app accepted a deploy immediately

Venkat Uppuluri 0

I am trying to migrate from 3.10 because of the EOL notice to 3.14.

Is 3.13 an option on Functions.

Both fresh apps are 503 pre-publish, so that state may just be normal for a new consumption app. Testing whether a publish actually lands on 3.13:

Published to the fresh 3.13 app

Both fresh apps refuse a publish immediately after creation — the 3.10 rehearsal app had several minutes of warm-up before I deployed to it. Waiting for activation, then publishing:

Waiting for activation then publishing to 3.14Waiting for activation then publishing to 3.14View live output

No, it didn't recover — and the rehearsal has been worth it, because three things I assumed are now disproven.

What's established:

The outage mechanism is confirmed. _cffi_backend.cpython-310-...so versus cpython-314-...so — a 3.14 interpreter can't load the cp310 extension, so cryptography → azure-identity fails and the worker dies.
The deadlock is real. Once the app is down, SCM serves 503 and no publish can land.
WEBSITE_RUN_FROM_PACKAGE from a blob URL doesn't rescue it on Linux Consumption — setting stored correctly, app restarted, stayed 503.
Deploy-then-flip doesn't work either — the cp314 package deployed while healthy on 3.10, then the runtime flipped, and it still went 503 with functions deregistered.

What I'm testing now: brand-new apps on 3.13 and 3.14 both refused a publish immediately after creation with the same 503 — but a fresh consumption app is "not active until content is published", and the 3.10 rehearsal app happened to get several minutes of warm-up before I deployed to it. So that 503 may be an activation artifact rather than a version problem. I'm waiting for activation and then publishing to 3.14 to separate the two.

That distinction matters a lot: if a fresh 3.14 app publishes cleanly, the production path is to recreate the function app on 3.14 in Terraform. If it doesn't, then 3.14 isn't usable on Linux Consumption here yet, and the answer is 3.13 — or moving the app to Flex Consumption.

Either way the deadline is workable: 3.13 gets you off 3.10 before 1 October just as well, and dev is stable on 3.10 in the meantime.

0 comments

2 answers

Your answer

Answer 1

Venkat Uppuluri 0

And 3.12 also works. Do you have EOL dates for 3.13 and 3.12?

0 comments

Answer 2

Allan Solomon Mejia 10,305

Hi @Venkat Uppuluri

Python 3.13 isn’t a supported option for a Function App running on the legacy Linux Consumption plan. Python 3.12 is the final Python version supported on this plan; newer versions won’t be added.

Python 3.13 and 3.14 are GA for Azure Functions, but you must use a supported hosting plan such as Flex Consumption, Premium, or Dedicated. For the existing Linux Consumption app, the supported migration path from Python 3.10 is therefore Python 3.12, not 3.13 or 3.14.

Terraform accepting linuxFxVersion doesn’t establish runtime support. The resulting 503 responses also don’t prove that the app only requires activation time. Both newly created apps were configured with Python versions unsupported by that hosting plan.

Recommended options:

Remain on Linux Consumption and recreate or migrate the app using Python 3.12.
Move to Flex Consumption if Python 3.13 or 3.14 is required. Microsoft recommends Flex Consumption for new serverless Function Apps.

The WEBSITE_RUN_FROM_PACKAGE and deploy-then-flip tests can’t make an unsupported language/hosting-plan combination valid. I cannot find verified Microsoft documentation confirming the SCM deadlock mechanism described here; if SCM remains unavailable after recreating the app with Python 3.12, investigate it separately through Azure Support.

References:

Azure Functions runtime and supported language versions

Supported languages in Azure Functions

Azure Functions Flex Consumption plan

Update language stack versions

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

Allan Solomon Mejia 10,305 Reputation points

2026-09-23T19:35:57.9733333+00:00
Yes. Microsoft currently lists these expected Azure Functions support dates:

Python 3.12: October 2028

Python 3.13: October 2029

However, Python 3.12 is the latest and final version supported on Linux Consumption. Python 3.13 requires Flex Consumption, Premium, or a Dedicated App Service plan.
Venkat Uppuluri 0 Reputation points

2026-09-23T20:12:21.0633333+00:00

So why does 3.13 and 3.14 return 503?
Allan Solomon Mejia 10,305 Reputation points

2026-09-23T20:32:45.74+00:00
The 503 occurs because those apps were created on the Linux Consumption plan. Python 3.12 is the final Python version supported on that plan; Python 3.13 and 3.14 aren’t. Therefore, waiting for activation won’t make those configurations deployable.

Python 3.13 requires Flex Consumption, Premium, or Dedicated hosting. Python 3.14 is GA, but Microsoft states that remote build for Python 3.14 isn’t currently supported on Flex Consumption.

For this test:

Use Python 3.12 on the existing Linux Consumption plan.

Recreate Python 3.13 on Flex Consumption, Premium, or Dedicated.

For Python 3.14, use Premium/Dedicated or follow a supported deployment method that doesn’t require Flex remote build.

The 503 alone doesn’t identify the precise internal failure, so I can’t confirm the exact SCM error path without platform logs. However, the 3.13/3.14 Linux Consumption configurations are outside Microsoft’s documented support matrix.
Allan Solomon Mejia 10,305 Reputation points

2026-09-23T21:31:32.6666667+00:00

Hi @Venkat Uppuluri

Please let me know if you need any further assistance. Otherwise, if the information provided helped/resolved your issue, please click “Accept Answer” to help others who may encounter the same problem.