Force HTTPS on your website
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.
Read more…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.
Read more…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.
Read more…This blog post is out-of-date – we can now manage all of your Let’s Encrypt certificates automatically, and have a UI to upload custom certificates. See this help page for details.
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 pip install
).
This is the first step towards a much improved system for HTTPS – watch this space for more information.
Read more…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.
Read more…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.
Read more…Update 24 October 2018 – always-on tasks has now been released to paying 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 support@pythonanywhere.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 response_time=N.NNN
.
We hope that you’ll find these useful if you ever have to chase down performance issues. Let us know what you think!
Welcome to the second part in our tutorial for getting started with Flask development on PythonAnywhere! This is a continuation of our previous tutorial, so if you haven’t been through it, you should do that first. In particular, this tutorial will assume that you’re starting with the code that you had at the end of the last one: a simple website that allowed you to post comments on a page, all of those comments being stored in a database:
It was made up of two files; a Python file which controlled what it did, and a template file that controlled how it was displayed. All of our code was under source-code control, and it was running as a website on PythonAnywhere.
Obviously this was a rather limited website! It would be nice if we could add some features – and in this tutorial, that’s exactly what we’ll do. Our original site used the slightly ugly password protection built in to PythonAnywhere; this means that in order for people to post on it, they had to enter a username and password – but it was the same username and password for everyone, which isn’t terribly secure. We’re going to add our own login page – which means that we can also store a record of who posted what, and when.
Here’s what it will look like:
Adding these new features will require us to do a bit of work in the background; our existing site works fine for what it is, but it’s not very extensible, and we’ll fix that as we go. You’ll learn about the Flask-Login extension, database migrations, and virtualenvs – all very useful stuff.
Let’s get started!
Read more…