Plans and pricing

With every PythonAnywhere account, you get a number of CPU-seconds included each day. This applies to all code run through our in-browser consoles, in your scheduled tasks and in your always-on tasks, but does not apply to your web apps.

A CPU-second is one second of full-power usage on a High Frequency Intel Xeon E5-2670 v2 (Ivy Bridge) Processor (one CPU core on an Amazon AWS m5.xlarge instance). Your code only uses up CPU seconds while it's actually busy. If your code isn't using any CPU power (maybe it's not running, or it's waiting for input or for a web request to return) then it's not using any CPU seconds.

If you use up all of your included CPU seconds, don't worry! You can always buy more — and even if you don't, your processes will still run, in the tarpit.

Tarpitted processes run at a lower priority than users who haven't hit their limit yet, but they get any spare capacity that we have on our server cluster, unless they're using gigabytes of RAM.

Here's more info about the tarpit.

We guarantee a certain amount of computing capacity for your web app, but how many hits/day you can get out of that depends on you. If you write a website that does tons of calculations for every request then you won't be able to handle as many hits per day as our estimate. If you write a super-efficient one using a lightweight framework, you'll be able to handle more.

Our estimates are based on real-world websites that we host, like web2py.com, so we're confident that they're a good indicator of what a typical website will be able to handle.

How it works, under the hood

The web app compute capacity is defined by the number of web workers associated with your app. Each web worker is an independent process capable of serving up your entire app, so if you have more than one, while one is busy handling one request another can take over. If you only have one worker (or if all of your workers are busy) then requests are queued up and served when a worker becomes available.

For sites without a lot of traffic — even if they have a lot of users accessing pages occasionally — one web worker is enough. But when things get busy, if two people happen to hit your app at exactly the same time, it's useful to have more than one.

Making things faster with static files

Static files (that is, stuff that doesn't change frequently and that you store in simple files on the disk, rather than creating dynamically with your Python code — like CSS files or JavaScript) can be configured to be served separately, without tying up your web workers, using the "Static files" section of the web app configuration page.

All paid plans support custom domains for all of your web apps.