Dec 15, 2025 by PythonAnywhere Team

tl;dr

We’re restructuring our pricing for the first time since 2013. We’re combining the Hacker ($5/month or €5/month in the EU system) and Web Developer ($12/month or €12/month in the EU system) tiers into a new Developer tier ($10/month €10/month in the EU system).

These changes will start January 8 (EU) and January 15 (US). Free users who upgrade before the change will lock in the current Hacker rate of $5/month (€5/month in the EU system). This lets us invest in platform upgrades, better security, and the features you’ve been requesting.

Read about the broader changes to PythonAnywhere and guidance for free tier users here.

Dec 15, 2025 by PythonAnywhere Team

tl;dr

Starting in January 2026, all free accounts will shift to community-powered support instead of direct support and will have some reduced features. If you want to upgrade, you can lock in the current $5/month (€5/month in the EU system) Hacker plan rate before January 8 (EU) or January 15 (US). After that, the base paid tier will be $10/month (€10/month in the EU system).

If you’re currently a paying customer, you can learn more about the new pricing tiers and guidance for current customers here.

Jul 11, 2025 by fjl

tl;dr

Check out the instructions on GitHub and connect your Claude Desktop, GitHub Copilot, Cursor or any similar tool supporting MCP to PythonAnywhere directly.

Mar 27, 2025 by giles

If you signed up for an account on PythonAnywhere after 25 March 2025, you’ll have Python versions 3.11, 3.12 and 3.13 available. Additionally, the underlying operating system for your account will be Ubuntu 22.04, rather than the 20.04 used by older accounts.

If you signed up before that date, you’ll be on an older “system image” – essentially the version of the operating system and the set of installed packages that you have access to. You can switch to the new system image from the “Account” page, but you may need to make changes to your code and/or virtualenvs to make everything work – there’s more information on that page.

This post has more details on what’s new in the “innit” system image. There’s a lot!

Jan 10, 2025 by giles

Are you so keen on PythonAnywhere that you’d like to work with us? We have an open role, and the recruitment team at our parent company Anaconda are looking for great people.

We’re looking for a senior engineer with lots of experience in backend stuff, but an interest in working across the full stack from obscure kernel wrangling, custom Linux container-based virtualization, Django and Flask on the mid-tier, up to TypeScript and React on the front end. There’s even a (tiny) bit of Lua thrown in there.

We’re an Extreme Programming team so you’ll be pairing with other team members from day one. All work is remote (bar occasional team meetups), and we can currently hire people based in the UK.

There’s more detailed information about the role on the official Anaconda jobs board, and you can also apply there. If you do, drop us a line at [email protected] too so that we can tell the recruitment team to pull you to the front of the queue :-)

Oct 22, 2024 by pythonanywhere

UPDATE 2024-11-05

As of today, we have migrated all of our US storage systems over to newer infrastructure. We’ll post again with more details about this migration once everything has had a week or so to bed in, but since we did the equivalent migration on our EU systems a few months back, we have had no issues at all there. So (touch wood) we’re feeling quietly confident :-)

Original post

PythonAnywhere has been around for over 10 years, and as our platform continues to grow with tens of thousands of users, we’re committed to keeping it in top shape. Part of this involves upgrading some of the older parts of our infrastructure, with a special focus on our file storage servers – some of the oldest systems we have.

Oct 4, 2024 by pafk

Imagine there’s a PythonAnywhere user, homer8bc, with poetic inclinations. He wants to serve his newest poem (he believes it’s quite epic) as a static text page. He’s old school — he doesn’t believe in HTML, and as for CSS? Forget it! His friend, S. Yodos, lives in Cyme, while homer8bc resides on Ios island, so in-person communication is difficult…

Sep 10, 2024 by giles

tl;dr

On Thursday 5 September 2024 we performed some system maintenance. It appeared to have gone well, and was completed at the scheduled time (06:20 UTC), but unfortunately there were unexpected knock-on effects that caused issues later on in the day, and further problems on Saturday 7 September. This post gives the details of why we needed to perform the maintenance, what happened, and what we will do to prevent a recurrence.

Aug 21, 2024 by glenn

Here is a slightly delayed (and short) run-down of the new stuff that we deployed recently.

The main change for this update is that we have updated the underlying OS running PythonAnywhere to Ubuntu 22.04. This is an LTS release so it will be supported for some time to come. This will not affect user environments, but it is setting us up for a new user environment that should be coming soon.

We have also:

• Started the process of updating our file servers to be more robust
• Improved our alerting so that we are alerted to many new forms of failure on PythonAnywhere
• Made some improvements to the ASGI beta systems and their documentation
• Fixed a number of security issues
• Fixed various bugs

Aug 14, 2024 by giles

tl;dr

We recently started validating that the postal codes used for paid PythonAnywhere accounts match the ones that people’s banks have on file for the card used. This has led to some confusion, in particular because banks handle postal code validation in a complicated way – charges that fail because of this kind of error can show up in your bank app as a payment that then disappears later, or even as a charge followed by a refund. This blog post is to summarise why that is, so hopefully it will make things a bit less confusing!

The long version…

Card fraud is, sadly, a fact of life on the Internet. If you have a website that accepts payments, eventually someone will try to use a stolen card on it. If your site is online for some time, hackers might even start using you to test lists of stolen cards – that is, they don’t want to use your product in particular, they’re just trying each of the cards to find the ones that are valid, so that they can use them elsewhere.

We recently saw an uptick in the number of these “card probers” (as we call them internally) on PythonAnywhere. We have processes in place to identify them, so that we can refund all payments they get through, and report them as fraudulent to Stripe – our card processor – so that the cards in question are harder for them to use on other sites. But this takes time – time which we would much rather spend on building new features for PythonAnywhere.

Looking into the recent charges, we discovered that many of them were using the wrong postal code when testing the cards. The probers had the numbers, the expiry dates, the CVVs, but not the billing addresses. So we re-introduced something that had been disabled on our Stripe account for some time: postal code validation for payments. You may be wondering why it wasn’t enabled already, or why it might even be something that anyone would disable; this blog post is an introduction to why postal codes and card payments can be more complicated than you might think.