Python 3.10 Reaches End of Life on October 31. Your Cloud Provider Starts Pulling the Plug Sooner.

What Actually Ends in October?

Python versions follow a published five-year lifecycle, and 3.10's is nearly over. PEP 619, the Python 3.10 release schedule, states that source-only security updates will be released until five years after the release of 3.10 final, so until approximately October 2026. The same PEP lists 3.10.21, released on August 12, 2026, as the most recent security release. After end of life, there is no 3.10.22 coming for the next vulnerability in the interpreter or the standard library.

The Python developer guide's version table puts the date at 2026-10 and shows the full sequence around it: 3.9 ended on October 31, 2025, 3.11 is scheduled to end in October 2027, and 3.12 in October 2028. The table marks these dates as scheduled rather than fixed. In a Python discussion thread on the exact date, core developer Brett Cannon wrote that PEP 619 gives a scheduled date that is not in stone and could slip, and advised against planning around a specific day.

That advice is the right way to read the deadline. Nothing stops working on November 1. What changes is that a Python 3.10 service has become an unpatched runtime, and the cost of that shows up later: in a security questionnaire from a customer, in a vulnerability scanner that flags the base image, or in a CVE in a C extension or the standard library that nobody will fix on your branch.

It also lands in a very different regulatory climate from earlier end-of-life dates. In Europe, the Cyber Resilience Act's vulnerability reporting obligations are already in force, as we covered in our article on the CRA's September deadline. A manufacturer that has to handle and report exploited vulnerabilities in its products will find it hard to explain why the runtime underneath them stopped receiving fixes, and it knew the date for five years.

The Cloud Deadlines Arrive First

For teams running Python on managed serverless platforms, the relevant date is not the upstream one. It is whenever the provider stops patching its runtime, and all three major clouds have picked October.

Microsoft's supported languages page for Azure Functions lists Python 3.10 with an expected end-of-support date of October 2026. Google's Cloud Run functions runtime support schedule deprecates the python310 runtime on October 4, 2026, one week from today, and decommissions it on April 4, 2027. Both dates arrive before the upstream end of life.

AWS publishes the most detailed timeline. The AWS Lambda runtimes documentation deprecates python3.10 on October 31, 2026, blocks creating new functions on it from February 1, 2027, and blocks updating existing ones from March 3, 2027. After deprecation, AWS says it may no longer apply security patches and that affected functions are no longer eligible for technical support. The same page notes that the Python 3.10 runtime sits on Amazon Linux 2, which reached end of life on June 30, 2026 and is only receiving critical and selected important patches until the runtime is deprecated.

The block-update date is the one that hurts. A function on a deprecated runtime keeps running, but after March 3, 2027 you can no longer push a code or configuration change to it without also moving it to a supported runtime. The first urgent bug fix after that date becomes a forced runtime upgrade, done under pressure, which is exactly the situation a planned upgrade avoids.

How Many Teams Are Still on It?

More than most engineering leaders assume. The State of Python 2025 analysis of the Python Developers Survey, run by the Python Software Foundation and JetBrains with more than 30,000 responses, found 27% of respondents still on Python 3.10 or older, and 83% on a version at least a year old.

Download data points the same way. Stepto pulled PyPI Stats download data for the requests package, one of the most installed libraries on PyPI, for March 29 to September 25, 2026. Python 3.10 accounted for 13.9% of those downloads, more than Python 3.13 at 12.2%. Adding 3.9 and everything older brings the total to about 25%. Download counts are dominated by CI pipelines and container builds rather than people, which is precisely why they matter here: they show how much automated infrastructure is still being built on runtimes that are about to lose support.

The reasons are rarely negligence. Python 3.10 is the default interpreter on Ubuntu 22.04, which was the standard server and container base for years. It was the version many teams standardised on when they last did an upgrade, and upgrades of the interpreter tend to happen only when something forces them. In outsourced and inherited codebases the pattern is stronger still: a service built by a previous vendor, deployed once and left alone, keeps whatever runtime it shipped with until a scanner or an auditor asks about it.

The Libraries Left Before the Interpreter Did

Upstream end of life is the last step, not the first. Most of the important libraries dropped Python 3.10 long before October, and that is the more practical reason to move.

The scientific Python ecosystem coordinates this through SPEC 0, its minimum supported versions policy, which recommends dropping support for a Python version three years after its initial release. For 3.10, released in October 2021, that point came in late 2024. The effects are visible in the release notes. The NumPy 2.3.0 release notes state that the release supports Python 3.11 to 3.13, and the pandas 3.0.0 release notes, published January 21, 2026, state that pandas 3.0.0 supports Python 3.11 and higher.

Web frameworks moved too. The Django 6.0 release notes say Django 6.0 supports Python 3.12, 3.13 and 3.14, and that the Django 5.2 series is the last to support Python 3.10 and 3.11. A Django application on 3.10 therefore cannot adopt 6.0's features, including built-in background tasks and native Content Security Policy support, without first upgrading the interpreter.

This is where the real exposure sits. A team on 3.10 is not just running an unpatched interpreter; it is gradually being pinned to library versions that their maintainers have stopped fixing. When a security issue lands in a data or web library, the fix ships in a release your interpreter cannot install. We described the wider version of this problem in our article on open source maintainer burnout: maintainers already have too little capacity, and backporting fixes to a Python version they dropped two years ago is the first thing they cut.

Why Ubuntu Pro Does Not Solve This

The most common reason teams give for staying put is Ubuntu. Python 3.10 is the system interpreter on Ubuntu 22.04 LTS, and according to Canonical's Ubuntu release cycle page, 22.04 receives standard security maintenance into 2027, and Ubuntu Pro's Expanded Security Maintenance extends that to 2032. Canonical does backport security fixes to the python3.10 package it ships.

The limitation is scope. As HeroDevs' Python 3.10 end-of-life guide points out, that coverage applies to the CPython interpreter package, not to PyPI packages, frameworks or other libraries installed with pip. In a typical application, the interpreter is a small fraction of the code that runs. The dependencies in your requirements file or lock file are most of it, and those are exactly the packages whose maintainers have already moved to 3.11 or 3.12.

There are also two quieter gaps. Many teams do not use the Ubuntu system Python at all; they build containers from an upstream Python 3.10 image or install the interpreter with pyenv, uv or conda, and none of those receive Canonical's backports. And the official Python container images and build tools follow the upstream lifecycle, so once 3.10 is end of life, new images and fixes for it stop.

Extended support has its place, particularly for appliances and embedded systems that cannot be changed quickly. For an actively developed web service, data pipeline or API, it is a way to delay the upgrade while the gap between your pinned dependencies and the maintained ones keeps widening.

Skip 3.11. Target 3.12 or 3.13.

Once a team decides to upgrade, the instinct is to move one version at a time. For 3.10 that is the wrong call. The developer guide schedules Python 3.11's end of life for October 2027, and the Lambda runtimes page deprecates python3.11 on June 30, 2027, because it also runs on Amazon Linux 2. An upgrade to 3.11 buys less than a year before the same exercise starts again.

Python 3.12 is supported upstream until October 2028 and 3.13 until October 2029, and both run on Amazon Linux 2023 in Lambda. Libraries have had time to support them: NumPy 2.3 and pandas 3.0 both support 3.12 and 3.13, and Django 6.0 supports both. For most production services, 3.12 is the conservative choice and 3.13 the better default. Python 3.14 is a reasonable target for new projects, and it is also where the free-threaded, no-GIL build became officially supported under PEP 779, although it remains an optional build rather than the default.

The upgrade also pays for itself in performance, which is rare for maintenance work. The Python 3.11 release notes report that CPython 3.11 is an average of 25% faster than 3.10 on the pyperformance benchmark suite, with speedups of 10 to 60% depending on workload. In the JetBrains analysis cited above, author Michael Kennedy estimates that moving from 3.10 or older to 3.13 gives around a 42% speed increase and 20 to 30% lower memory use without code changes. Treat those as benchmark figures, not a guarantee for your workload, but for CPU-bound services and Lambda functions billed by duration they turn a compliance task into a cost reduction.

What Actually Breaks in a 3.10 to 3.13 Upgrade

Jumping several versions means absorbing several rounds of standard library removals at once. The Python 3.12 release notes remove distutils under PEP 632, remove the asynchat, asyncore and imp modules, and stop pre-installing setuptools in virtual environments created with venv. Old build scripts, setup.py files and legacy packaging that relied on any of those will fail on 3.12 before a single test runs.

Python 3.13 goes further. Its release notes remove 19 legacy standard library modules under PEP 594, including cgi, cgitb, crypt, imghdr, pipes, telnetlib and uu, and remove the 2to3 tool and lib2to3. The cgi module is the one that most often turns up in older web code, usually for parsing form data or headers, and imghdr is a common surprise in image upload handlers.

Most of the pain, though, is in dependencies rather than your own code. An upgrade usually means moving several pinned libraries across a major version at once: NumPy 1.x to 2.x, pandas 2.x to 3.0, an old ORM or HTTP client, packages with compiled extensions that need new wheels. Those upgrades carry behavioural changes that tests may not catch, especially around data types, time zones and default settings. Even infrastructure details move; the Azure Functions documentation notes that Python 3.10 apps pair with ODBC Driver 17, while 3.11 and newer use ODBC Driver 18, which changes encryption defaults for SQL Server connections.

None of this is exotic. It is the ordinary work of a well-run upgrade: read the removal lists, run the test suite under the new interpreter with deprecation warnings turned into errors, upgrade dependencies in small steps, and put tests around the behaviour that matters most before touching it. AI coding agents are genuinely useful here for the mechanical part, such as rewriting syntax and replacing removed modules, provided a senior engineer owns the plan and reviews what changes, a point we made in our article on agent-ready codebases.

A Practical Upgrade Plan, and Where a Nearshore Team Fits

Start with an inventory, because most companies do not know where all their Python runs. List every service, scheduled job, serverless function, notebook environment and container base image, and record the interpreter version each one uses. For Lambda, AWS lists affected functions in the Health Dashboard and in Trusted Advisor's deprecated runtimes check; the other clouds have equivalent views. Pay special attention to anything a previous vendor built, because that is where forgotten runtimes live.

Then prioritise by exposure rather than size. Internet-facing services and anything on a serverless runtime with a block-update date come first, followed by services with the most dependencies stuck on old versions. Add the target interpreter to your CI matrix now, so every service shows what fails before anyone touches production, and roll upgrades out one service at a time with the ability to switch back.

For a typical service with reasonable test coverage, this is weeks of work, not quarters. The teams that struggle are the ones where the Python code was written by people who have since left, test coverage is thin, and senior engineers are already committed to the roadmap. That is the same pattern we saw with the .NET 8 and .NET 9 end of support in November: the upgrade is well understood, but nobody has time to own it.

This is bounded, well-specified work that suits a dedicated development team working alongside your own engineers. Stepto's nearshore Python developers in Serbia work in European hours, overlap with US East Coast mornings, and have taken Django, FastAPI and data pipeline codebases across several interpreter versions at once. We start with the inventory and a written upgrade plan, put tests around the risky paths, move services onto 3.12 or 3.13 and hand back a CI setup that makes the 2028 upgrade routine, so your own team stays on the roadmap.