Well, our last "monthly" newsletter was in September 2017. We must have shifted the bits in the period left one, or something like that :-)
Anyway, welcome to the September 2018 PythonAnywhere newsletter :-) Here's what we've been up to.
We recently added support for Python 3.7. If you signed up since 28 August, you'll have it available on your account -- you can use it just like any other Python version.
If you signed up before then, it's a little more complicated, but we can update your account to provide it -- there's more information in this blog post.
We've also been working on making setting up HTTPS on your website a bit more streamlined. Previously you had to get the certificate and the private key, and then email us asking for them to be installed, which could take up to 24 hours. Now you can cut our support team out of the loop and install it all yourself. Check out this blog post for the details.
There will be more improvements to HTTPS support coming soon...
Another shiny new feature: built-in support for forcing people who visit your site to use HTTPS instead of non-secure HTTP, without the need to change your code! Once again, there's more info on the blog.
We're wondering if it would be interesting for you to hear a bit about some of the metrics we monitor internally to see what's happening in our systems. Here's a random grab-bag of some numbers for this month:
Let us know whether those are the metrics you'd like to see, whether you'd like to see more, or if you think it's completely uninteresting :-)
Like every tech business in the world, we spent a lot of time late last year and early this year working on ensuring that we were compliant with the GDPR. This was doubly-important to us -- most companies are "data controllers" in GDPR terminology, which means that they store data about people, but we are also "data processors", which means that we run computers and programs that other people use in their role as data controllers. Or, to make that a bit more concrete -- if you have personal data about people on a website that you host with us, you're a data controller, and you're delegating the data processing to us.
This of course, meant that it was more than twice as much work for us as it was for most people, but we got it all done a week before the deadline :-)
One interesting side-effect of all of this was that we realised that these newsletters sometime say things like "hey, we've added this cool new feature (for paid accounts only)" -- and when they do say something like that, it's not unreasonable to see them as marketing. We had to make super-sure that all marketing messages from us were opt-in only, so we unsubscribed everyone from the newsletter and put up a banner on login so that people would know about it.
That in turn means that this newsletter is going to about ten times fewer people than the one before -- so if you're reading it over email, thanks for choosing to receive it :-) Of course, you can always unsubscribe using the link at the bottom of the message, or from the email settings tab on the Account page.
Although you can install Python packages on PythonAnywhere yourself, we like to make sure that we have plenty of batteries included.
Everything got updated for the new system image that provides access to Python 3.7, so if you're using that image, you should have the most recent (or at least a very recent) version of everything :-)
Paying PythonAnywhere customers get unrestricted Internet access, but if you're a free PythonAnywhere user, you may have hit problems when writing code that tries to access sites elsewhere on the Internet. We have to restrict you to sites on a whitelist to stop hackers from creating dummy accounts to hide their identities when breaking into other people's websites.
But we really do encourage you to suggest new sites that should be on the whitelist. Our rule is, if it's got an official public API, which means that the site's owners are encouraging automated access to their server, then we'll whitelist it. Just drop us a line with a link to the API docs.
We've added too many sites to list since our last newsletter to list them all -- but please keep them coming!
That's all we've got this time around. We have some big new features in the pipeline, so keep tuned! Maybe we'll even get our next newsletter out in October 2018. Or at least sometime in 2018...
One smaller feature we added in our last system update was the ability to force HTTPS without needing to change your code. Here's a bit more information about why you might want to do that, and how it works.
If you're using your default yourusername
.pythonanywhere.com website on PythonAnywhere, people can access it using a non-secure connection via
http://yourusername.pythonanywhere.com, or using a secure connection via
https://yourusername.pythonanywhere.com. Likewise, if you have a paid account and are using a custom domain, they can access it non-securely via
http://www.yourdomain.com or -- if you've set up an HTTPS certificate -- they can access it securely via
Having two ways to access the site is fine, but these days there's a general move across the Internet to using HTTPS for everything. Newer versions of Chrome explicitly put the words "Not secure" in the browser's address bar when you access a non-HTTPS site, and Google also apparently rank HTTPS sites higher in search results.
So often, what you want to do is set things up so that people can only use HTTPS to access your site -- never simple non-secure HTTP. This is called "forcing HTTPS", and works by sending back a redirect when people try to access the non-secure URL. So if someone goes to
http://www.yourdomain.com, they're just bounced straight over to
https://www.yourdomain.com, and likewise if they go to
http://www.yourdomain.com/something they're redirected to
Because forcing HTTPS is a common requirement, most of the main Python web frameworks have support for it build in -- Django has a
SECURE_SSL_REDIRECT setting, for example, and there's a Flask extension called
flask-sslify. In the past, we suggested that people add the appropriate configuration to their code to use those features, and it all worked fine.
There were just two problems:
We made a bunch of changes to the way our loadbalancers work as part of our recent system update, primarily in order to improve the way we handle HTTPS certificates. Because we were working in that part of the code, it was easy for us to add the capability to force HTTPS to our own infrastructure. So now, in order to force HTTPS for your website, just go to the "Web" page inside PythonAnywhere, select the site on the left, scroll down to the "Security" section, and toggle it on:
You'll need to reload the site using the button at the top of the page to activate it.
There are a couple of things to keep in mind when using this feature.
POSTed data. This means that we can't do a force-HTTPS redirect in response to a POST request, because the data would get lost. (It also wouldn't be super-valuable -- if the user has POSTed data, then it's already gone across the Internet unencrypted, so sending it again in encrypted form wouldn't really help matters.)
Hopefully that was all pretty clear, but if you do have any questions, just drop us a line at email@example.com or leave a comment below.
If you signed up since 28 August, you'll have Python 3.7 available on your account -- you can use it just like any other Python version.
If you signed up before then, it's a little more complicated, because adding Python 3.7 to your account requires changing your system image. Each account has an associated system image, which determines which Python versions, Python packages, operating system packages, and so on are available. The new image is called "earlgrey" (after the previous system images, "classic" and "dangermouse").
What this means is that if we change your system image, the pre-installed Python packages will all get upgraded, which means that any code you have that depends on them might stop working if it's not compatible with the new versions.
For previous upgrades, from classic to dangermouse, we said that all was OK if you were using a virtualenv, which (of course) removes the dependency on the pre-installed Python packages. However, this new image not only adds Python 3.7 and upgrades packages, it also upgrades the older Python versions -- for example, from the antediluvian 2.7.6 to 2.7.12, and from 3.6.0 to 3.6.6. This can break virtualenvs in some cases.
So, long story short -- we can switch your account over to the new system image, but you may need to rebuild your virtualenvs afterwards if you're using them -- and you may need to update your code to handle newer pre-installed Python packages if you're not using virtualenvs.
There are more details about exactly which package versions are included in which system image on the batteries included page. And if you'd like to switch your account over to earlgrey, just drop us a line using the "Send feedback" button. (If you've read all of the above, and understand that you may have to make code/virtualenv changes, mention that you have in the feedback message as otherwise we'll respond by basically repeating all of the stuff we just said, and asking "are you sure?")
Our system update last week added on an API to let you install HTTP certificates yourself instead of having to email us. We've been beta-testing it over the last seven days, and it's now ready to go live :-)
You can either use it by accessing the API directly from your code, or by using our helper scripts
(which you can
This is the first step towards a much improved system for HTTPS -- watch this space for more information.
We supply an HTTPS certificate for all websites that are subdomains of
so your website at yourusername
.pythonanywhere.com handles HTTPS by default. But if you
create a website with a custom domain, you need to get a certificate. This is because only
the owner of a domain can create a certificate for it, to stop people from (say) creating
Luckily, it's easy enough to create a certificate for your site, either by using the excellent Let's Encrypt (for which we have detailed instructions here) or from one of the many commercial providers.
But once you've created your certificate, you need to get it installed. In the past, the way we asked you to do that was to store the certificate and the private key somewhere in your PythonAnywhere file storage, then email us. The system worked well, but it did have one problem -- you needed to wait for us to install the certificate, which meant that in the worst case you could wait for up to 24 hours for it to be installed -- maybe not a huge issue when you're just getting started, but a big deal if you accidentally let the certificate expire and need a renewed one installed ASAP.
The easiest way to install your certificate is to use the PythonAnywhere helper scripts. The first step to do that is to make sure you have an API token set up for your account; go to the "Account" page and then click the "API token" tab. If you see this:
...then you're all set. If, however, you see this:
...then you need to click the button to generate a key.
Once you've done that, start a new Bash console, and run this to install the PythonAnywhere helper scripts:
pip3.6 install --user --upgrade pythonanywhere
(If you're on our "classic" image and don't have Python 3.6 available, you can use
Now you can run the script to install the certificate. If you've used our instructions for Let's Encrypt then the certificate and the key are in a well-known place, so you can just do this:
If you've got a certificate from a different provider, you can specify the combined certificate and the key location by using a different command:
pa_install_webapp_ssl.py www.yourdomain.com /home/yourusername/something/combined-cert.pem /home/yourusername/something/private-key.pem
...adjusting the paths to point to the appropriate files.
If all goes well, you'll see output like this:
< Setting up SSL for www.yourdomain.com via API > \ ~<:>>>>>>>>> < Reloading www.yourdomain.com via API > \ ~<:>>>>>>>>> _________________________________________________________________ / \ | That's all set up now :-) Your new certificate will expire | | on 12 November 2018, so shortly before then you should | | renew it (see https://help.pythonanywhere.com/pages/LetsEncrypt/) | | and install the new certificate. | \ / ----------------------------------------------------------------- \ ~<:>>>>>>>>>
If you're not using Let's Encrypt, it will look slightly different, of course. If you get an error and can't work out what to do, please do email us at firstname.lastname@example.org.
There's one important thing to notice there -- the renewal date. You'll still need to renew the certificate and install a new one when it expires.
If you're an API kind of person, you can use the new
ssl endpoint under the
webapps URL to
directly set your SSL certificate and private key with a
POST request; you can also get SSL information (when the cert
will expire, who issued it, and so on) by using the
GET method. More information in
the API documentation.
An API and some command line scripts for this stuff is all very well, but we're far from done with improving the way SSL certs work on PythonAnywhere. Our long-term goal is to make this even easier -- watch this space for more information.
Hopefully all of that is pretty clear! But if you have any questions, please do let us know.
We deployed a new version of PythonAnywhere this morning. Everything went pretty smoothly; there were a few problems with some hosted websites shortly afterwards (an error in a load-distribution algorithm put too many websites on some servers, and not enough on others) but some sharp-eye customers spotted the problem and let us know, and we were able to rebalance things and fix the issue quickly.
There are a couple of great new features in the new system, but we're doing some last-minute testing before making them live -- watch this space for more information :-)
We've heard reports from some Russian users that PythonAnywhere, and sites that we host, are blocked by their ISPs. The specific error message that they get when visiting the sites in Chrome is ERR_CONNECTION_TIMED_OUT -- Firefox has a similar one.
This appears to be the fallout from the Russian government's ongoing attempts to block the use of the Telegram instant messaging app. Because Telegram use various cloud hosting providers, including AWS and Google, the government has responded by blocking very large ranges of IPs owned by those providers. We're included in those ranges.
Right now, the situation is developing quite rapidly; the government appears to be rethinking its large-scale bans and some people who previously couldn't see our site can see it again now. The system we use to monitor our IPs' block status (which ironically enough is a Telegram bot) is still saying that we're blocked, though.
We're monitoring the situation. We can reasonably easily move everything over to new IPs, but we're wary of doing that in a situation where the new ones might get blocked the next day. When things have settled down a bit, if we're still blocked, we'll fix that.
[update 2018-05-16] Things seem to be settling down now, with no new large IP ranges being blocked, but it looks like some ISPs in Russia still aren't allowing access to our site and hosted sites. We've put up a test server on an IP address that we don't think is blocked. If you're in Russia and still seeing problems, please let us know what you see if you click here.
Like a lot of companies, we're updating our terms and conditions and privacy and cookies policy in order to comply with the GDPR. The GDPR is a large regulatory change from the European Union, and is mostly about people's personal data and how it is shared.
The new T&Cs and PP will come into effect on 10 May 2018 and if you carry on using PythonAnywhere after that date, you'll be agreeing to them, so we figured it would be a good idea to post an explanation about the highlights of the changes.
If you just want to see what the new documents contain, here they are:
There are two ways the GDPR impacts PythonAnywhere: data that we collect about you so that you can have an account on our site, and data that you collect about other people and use PythonAnywhere to process (eg. if you collect email addresses or the like on a website you run on PythonAnywhere).
Like all websites that collect information about people from the EU, we now need to explain exactly what we do with any personal data we collect from you, and why we collect it. That's what our own privacy and cookies policy is about, though there are a few things in the terms and conditions too.
This is a pretty simple one for us. Because we don't make money from advertising, we don't collect any more data about you than we need to run the site -- your email address and so on, some payment-related stuff if you're a paying customer, etc., and standard website analytics. To be perfectly honest, the less we know, the happier we are -- it makes us a much less attractive target for data thieves :-)
Of course, you can provide us with more information -- maybe your name is Jane Smith and you chose the name "JaneSmith" as your username, or you posted something in the forums saying "My name is Jane Smith and this is my code", or you run a website that mentions your name, address, telephone number, and favourite colour.
Our new privacy and cookies policy covers all of this, along with mentions of the fact that we keep website access logs (that's 4.3, if you want to know how access logs are described in legal terms) and lots of stuff about cookies. So much stuff about cookies.
"Data controller" and "data processor" are terms used by the GDPR. They can mean different things in different circumstances, but relating to PythonAnywhere, if you're storing personal data about yourself or other people on our systems, you are a data controller and we are a data processor acting for you. Let's imagine that you're hosting a website with us, and on your website you collect personal information about people -- maybe email addresses or names. In the GDPR's terminology, this makes you a "data controller" because you control the data that you've collected. But because we're providing you with the computers that the data is being stored and manipulated on, we're a "data processor".
The GDPR requires data controllers and data processors to have a contract in place that essentially says "this is what we each do" -- a data processing agreement (DPA). It doesn't need to be super-specific, but it does need to meet certain legal criteria.
We've noticed that some companies are sending out separate DPA contracts to cover this in addition to their normal terms and conditions. But in our lawyers' opinion, that's not necessary. When you agree to our terms and conditions and we accept you as a user of our site, that is a contract being formed between you and us. And if that contract includes all the appropriate stuff for the contract between a data processor and a data controller, then all is well.
So, Appendix 1 in the new terms and conditions covers all of that; if you're working towards GDPR compliance yourself, and you need a copy of the DPA, just use that. It mentions the essential stuff -- what we will do and not do, who processes data as a subcontractor (Amazon AWS, who own the servers PythonAnywhere runs on), and whether or not data goes out of the EU (it does, but that's OK because AWS is covered under the EU-US Privacy Shield Framework).
There are also some other GDPR-related changes dotted around the terms and conditions -- basically, making it clear that you can't use PythonAnywhere to breach the GDPR (so no spamming, please) and so on.
That's about it for the GDPR changes!
While we were modifying the T&Cs to be GDPR compliant, our legal advisors took the time to put in a few other updates to make sure that we're doing everything properly. Most of these are pretty minor (things like moving the details of the company from the top of the document to the bottom, or replacing the legalese "natural person" with the more, um, natural word "individual"), but a few are worth noting:
That's all we though it was important to highlight in the new terms; if you have any questions then please leave a comment below. Thanks for reading!
Update 8 January 2018 -- the beta is temporarily on hold while we sort out some issues that cropped up in the first phase. We'll announce here when it's reopened for new users.
Today we're starting the beta for a new paid feature on PythonAnywhere: always-on tasks. If you have a paid account and would like to try them out, drop us a line at email@example.com.
With always-on tasks, you can keep a script constantly running. Once the feature's been switched on for your account, they can be set up in the "Tasks" tab -- you specify a bash command (eg. "python3.6 /home/username/myscript.py"), and the system will start running it. If it exits -- say, if it crashes, or if the server has a problem -- it will be restarted quickly.
We'd be really grateful for any and all feedback people have about this. We've been testing it internally for some months, and a private beta has been running for a while -- so we're reasonably certain it's solid and reliable, but please do remember that it is currently beta, and there may be bugs we don't know about.
We updated PythonAnywhere this morning :-)
The most visible change is that we've refreshed the look and feel -- we'd love to know what you think, especially about the new dashboard page that you get when you log in or click the PythonAnywhere logo. Is it useful? Is there other stuff we should add there, or are there things we should remove? Just drop us a line using the "Feedback" link.
There have also been some big changes under the hood. The most important ones are part of a project we're not quite ready to announce (coming soon, we promise!) but more visibly, we've improved scalability for Jupyter/IPython notebooks, so hopefully you'll notice a speedup if you using them.
We've also fixed a couple of minor bugs:
That's all for today's update. Any feedback much appreciated!
we deployed a new version this morning. Most of the work was on a sekrit hidden feature that we can't talk about yet (oooo) but there is one small thing we've added that we hope you find useful: we've added response times to your webapp access logs:
you can see them at the end of each line, in the format
We hope that you'll find these useful if you ever have to chase down performance issues. Let us know what you think!
Page 1 of 16.