It’s been a year since PythonAnywhere went all-remote, but it has not slowed us down, and today was the time to deploy an exciting set of changes to our system.
To be precise, we already deployed the same code to our EU-based system on February 10th, and we have observed it for some time on a smaller scale. We were happy with what we observed, hence the deployment today.
There’s one big change that we’re going to keep quiet about for a couple of weeks, as it’s currently hidden behind a feature flag, and is something we need to phase in on a per-account basis – so we don’t want to say anything until it’s fully in-place for everyone… more about that later.
So for now, the most user-visible feature that we enabled for you was ability to
update your system image
and also to change exactly which version of Python 3 was started when you run the python3 command in Bash.
Up until today people who wanted to have their system image updated had to ask support to do that for them.
That’s related to our plans to sunset older system images in the future.
A side effect of that is exposing those settings as a part of our public API with endpoints for the system image, the default python3, and the Python version that is used by default when you run a file in the editor.
Another visible change is the change to scheduled task log file names, so that they no longer contain the command and time, but just the ID, like always-on tasks logs already do. This means that if you change the command that you’ve scheduled, the log file will still have the same name – much less confusing.
Users who downgrade, meaning that their custom domain web app is disabled, now have a button to re-enable it as username.pythonanywhere.com. On the same page we have made disable web app button orange to be more warning-like.
Users who have Let’s encrypt auto-renew set for their custom domain web apps will now get an email warning them in case of being out of disk space (that makes auto-renewal of the cert impossible)
We were able to catch some minor bugs, so now our Files API is not exploding when it encounters a symlink and streaming works over HTTPS.
There were, as always, multiple changes that are not directly visible. Those were related to security, performance and efficiency of support.