PythonAnywhere vs Heroku

Heroku was originally a Platform as a service that helped Ruby developers deploy their Rails applications. Recently they branched out into supporting other interpreted languages like Python. So now that Heroku are stepping directly on our toes we thought it would be good to compare us directly to them and maybe help people decide, depending on their needs, who they should go with.

Read more…

The story of brer programmer and the tar-pit

We’re experimenting with different ways of balancing resource usage between our users. One problem we’ve been experiencing is that individual users could quite easily suck up almost all of the CPU power on a console server.

Read more…

Using PythonAnywhere in Chrome's App mode

Using Vim inside a PythonAnywhere console could be a bit annoying. A number of keyboard shortcuts are caught by the browser before they ever hit our site. Notably for Vim these include Ctrl-W and Ctrl-T.

But there is a better way! And it involves making Chrome open PythonAnywhere in it’s special application mode. In this mode absolutely none of the keyboard shortcuts are captured. It’s neat. Which is my reserved way of saying that it fixes EVERY problem I’ve had with PythonAnywhere and Vim.

I also imagine that those intrepid Emacs users will be happy to be able to send all those torturous escape sequences as well. Bless them.

Read more…

Loads more packages, AsciiDoc, plus paginated forums, finally!

We’ve got several infrastructure stability + reliability improvements in this release, but more visible are some of the new binaries and packages.

Someone (I wonder who?) demanded a whole AsciiDoc toolchain to be able to write books with. Aside from that, you’ll find:

You’ll also find Twitter’s Bower browser / front-end web-dev package management tool.

Other minor fixes include:

  • fixing an issue with restricted internet access in SSH
  • the “reload” button for web apps is now clearly labeled with the domain it reloads
  • Trailing spaces no longer break static files mappings
  • And the forums are finally paginated!

Let us know if everything looks OK!

How do I serve static files using django & PythonAnywhere?

[update 2014-08-27] – this guide is out of date. Please refer to the help page on static files instead.]

Static files are the bits of your web site/application that are not created on the fly by Python. They might be images you want to embed, css files for styling, or even a PDF that you want people to be able to download.

If you use PythonAnywhere’s Django quickstart then we already provide some sensible defaults which will get things working without you having to do anything. If however you are migrating an existing site or want to set things up manually then I will walk you through the process.

Read more…

New release - fileserver fixes and a couple of tweaks

London sunrise by A nosa disco necesítanos, on Flickr

Giles and I are just winding down following our early morning deploy – it was a 3AM start for the two of us. Our best case was 20 minutes of downtime, our worst case prediction was about 3.5 hours. We came in at just under an hour and a half in the end. Definitely glad we did it so early in the morning.

The main reason for the deploy was an infrastructure upgrade, the fileserver has been upgraded from Debian to Ubuntu. It’s been in testing for 3 weeks, and it should fix an intermittent issue with user quotas. Will follow up with more highly nerdy technical detail about XFS and NFS, later.

We still managed to slip in a couple of tiny improvements:

  • envsubst now works in chroot jails, which was otherwise causing some worrying messages for anyone trying a git rebase. But, to be honest, git rebase is terrifying at the best of times.
  • a small bugfix to the PythonAnywhere static files UI, where users with multiple webapps had duplicate “Add new entry” elements
  • And a fix to our Bottle.py quick-deploy wizard, which means templates now work out of the box

Anyone else had some fun with early starts recently? I don’t think Giles even went to bed to be honest…

Image credit: London sunrise by A nosa disco necesítanos, on Flickr

The Python trademark in Europe

Last Thursday, the Python Software Foundation announced that a UK-based company had applied for the exclusive European-wide trademark on the word Python as applied to software, web hosting, computer services, and so on.

Obviously we’re a little concerned about this, and we recommend that anyone else who’s using Python in a business in the EU should go to the PSF post linked above and see if there’s anything they can do to help.

Read more…

A kickstarter book project

We’re proud to be sponsoring some of the rewards for Michael Herman’s Kickstarter book project: Real Python for Web Development, featuring web2py. Michael has a great plan and solid experience, and web2py creator Massimo Di Pierro and Fletcher Heisler, the author of Real Python, are helping out as co-editors.

Read more…

Static files -- finally!

The big news for this release is proper static files support. Until now users either had to serve files via Python, using their web app framework, or use an undocumented and unsupported feature of hacking things into /var/www/static. Slightly embarassing.

So, we’re pleased to present to you our first attempt at proper support for static files. Check out the Web Tab, and you’ll find a new section allowing you to map URLs to folders in your patch – these can be anywhere you like, they don’t have to be in /var/www.

Let us know how you like it!

Screenshot of static files UI

Bonus, secret update – check out the editor. If you don’t see anything new, that’s probably good news, but if you do notice anything, it’s probably a little warning message from PyFlakes, which should automatically detect some potential problems with your Python code, like syntax errors, unused imports and so on. Hope you find it helpful! (we all use it).

Thanks to everyone that’s been chasing us to get static files in, including njr, x, econpy, kgullion, sterling312 and little_dood.

Outage report; or, the perils of using 502s to trigger web application initialisation

Last weekend, we had two outages, both in the early hours (UK time) of the morning; we were finding it hard to diagnose the cause, because our outage alert system had failed and we only discovered it in each case when someone happened to check their email. On Monday we fixed the outage alert system.

Yesterday we had another, every phone in the office started beeping loudly, and we logged in right away – so we know what made it happen. While we’re not 100% sure that the cause of this problem was the same as the one on the weekend, the symptoms were similar enough that we’re pretty sure that it was.

The symptom in all of these cases was that the main PythonAnywhere website was down, giving “502 Bad Gateway” errors. Over the weekend, all of the customer websites we checked were OK, but when it happened yesterday, we noticed that one specific customer website was extremely busy, and getting the same 502 error. Further investigation showed that it had been linked from the front page of Reddit and was getting about 100 hits/second. So that would explain why it was so busy – and the site’s author hadn’t expected so much traffic so soon, so it was not super-optimised, which would explain why it couldn’t handle the load.

But the question was, how was it affecting the main PythonAnywhere site? We have a lot of stuff in place to stop web applications from affecting each other, which is why the other user websites on the same server were up and running.

Explaining what happened requires a little background, both about how nginx works and about how we use it and uwsgi to serve large numbers of Python web applications.

Read more…