Forums

How much will PythonAnywhere cost?

I'm just a hobbyist and I'm worried that if I get too addicted to PythonAnywhere, I won't be able to justify the cost of using it when it ships or it will break the bank.

Will there be a hobbyist pay-tier? Or do you have some rough estimate of what it would cost per month?

Hi fionabunny,

It's good to hear that you think PythonAnywhere might be an addiction risk ;-)

We're planning to follow a pricing model a bit like Dropbox's or GitHub's, with a free tier that's enough for occasional use, a couple of cheap plans (say, $5-$10/mo) that cover people who (for example) want to host a non-trivial but not-high-traffic website, and then more expensive ones for heavy users (people who are doing whole-genome analysis, for example) based on the amount of CPU/disk they use.

Hope that's reassuring!

Giles

I like the sound of this pricing model. Can't wait to hear more details as they become available.

Well, here's what we're currently thinking (and the first version will go live as soon as we've managed to sort out some issues with PayPal):

We'll have three kinds of accounts: Free, Premium ($5/month) and Hosting ($10/month).

  • Consoles: Free accounts will allow up to five, Premium and Hosting will allow up to 100. All accounts will allow console sharing.
  • Disk space: Free and Premium will give you 500Mb, Hosting will give you 2Gb.
  • Scheduled tasks: Free accounts will support one or two daily tasks (we're still deciding on the exact number), Premium and Hosting accounts will support up to 10 hourly or daily tasks.
  • Web applications: Free and Premium accounts will support hosting at your-username.pythonanywhere.com, and Hosting accounts will let you use your own domain.

Obviously over time we'll add more features and there will be further differentiation between the kinds of accounts. However, we're aiming to continue to work on the basis that free accounts should support all -- or at least most -- of the features that paid-for ones do, but with limits that are enough to keep the cost to us low enough so that we can afford to offer them.

How does that sound? Are we looking to charge too little or too much? Any suggestions on how we could make it better?

For $10/month, how much bandwidth do you have ? Cause I got some websites that serves Gb of data. If feel cheap if you can handle that.

Will you accept bitoins as a payment ?

Hi Ksamuel,

We haven't decided on bandwidth yet, we are currently on AWS so if you have a look at their bandwidth charges you can get an idea of what we would need to charge at a minimum so that we weren't losing money. On the other hand as we grow we expect to start managing our own hardware and so those costs should shrink over time.

Bitcoins? Sure, there isn't really a downside but there are issues we would need to think about. Recurring payments? Maybe bitcoin payers would need to do a year up front? currency volatility? Probably not that much of an issue if we convert them out very quickly. Anything's got to be better than Paypal or Credit card companies...

What do you think?

Hi Ksamuel -- just a follow-up to Hansel's post -- how many Gb/month do your websites serve?

Depends of the Websites. My biggest website ouputs 300 Mbps, which is routhly 777600Gb/month.

I don't plan to create such a big site on something like pythonanywhere. I'm just raising the issue because I don't want you to go stuck with such a situation.

@giles

Reading the numbers above I realize they seems big. They are not made up, video streaming is an expensive business.

I do understand pythonanywhere does not target these kind of websites.

Still, you should think about your upper limit.

@hansel

I would perfectly understand that you need an entire year of payement for the recurring payment. Or you could do partnership with sites like mtgox. Or just forget about recurring, and force people to charge their account with "credit".

The bitcoin community usually understands the constraint adopting bitcoin is, and is happy enough that somebody is taking the time and energy to adopt it. Not to mention the risk.

As for currency volatility, yes, you probably want to convert is quickly. It's ok, you already provide others with a way to avoid converting their bitcoin by accepting it.

It's going to be a bit of work, and more constraints, for probably not much money at first, so here are some up sides:

  • no fees: all the money sent is for you.
  • no SAV to deal with, policies, or whatever. You can charge what you want, the way you want, for what you want.
  • visibility: bitcoin users are looking for oportunity to spend their bitcoins outside the speculative bubble, so if you play smart, you can get free advertising from the bitoin community as being one of the hosting service accepting bitcoin. There are sites listing services accepting bitcoins, so you would at least get some backlinks. Bitcoin users are usually geeks, so a potential customer.
  • it's fun :-)

To put the 300Mbps figure into perspective, iPlayer was peaking up to around 100Gbps a couple of years ago: Guardian blog article

These days I would have expected most people doing serious video delivery to use a CDN (Content Delivery Network) rather than rolling their own solution, however. The old players like Akamai and Limelight can be expensive, but the Telco-run CDN movement is gathering a lot of momentum and it seems likely that they'd be able to undercut the over-the-top players significantly since they already own all their own infrastructure.

Anyway, that's a little OT. In terms of limiting the bandwidth of individual accounts, I'd suggest that a combination of capping and throttling would be ideal if possible. So, there's a monthly traffic limit and once this is exceeded then all traffic to the instance is throttled for the remainder of that month. Only snag is that I'm not sure how much control of traffic-shaping the virtualised platforms give you, and throttling can be a subtle business.

This sort of plan allows low-traffic sites to be responsive and gives people the confidence that their website won't disappear if it gets slashdotted or similar, but at the same time allows you to budget for worst-case usages for accounts. The option for people to buy additional bandwidth allowance in cases where their services suddenly take off might be useful, but this doesn't seem too critical to me - in some ways it may be more commercially advantageous to instead require them to simply upgrade their account to one with higher limits.

Apologies if that overlaps with posts elsewhere, I'm just slowly browsing through the forum backlog having joined here recently. I'm certainly impressed with both the concept and implementation so far!

Yeah. We don't like limiting our users - we want you all to have all the bandwidth and processor, but that's just not possible. At the moment there isn't really a need for us to impose limits since there's enough for everyone, but we're approaching the point where we're going to have to give serious thought to limits.

Sure, I appreciate where you're coming from. Speaking from a certain amount of professional experience, however, you do have to be a bit mercenary when you're running a free service.

For example, my current employer ran a free online service where customers could pay extra for additional storage. They could configure their own storage quota and were billed at the end of each month for their configured quota. We had a number of customers who put enough effort in that they would remove the bulk of their assets at the end of each month and reduce the quota just for the 12 hour period around the month boundary and then push it back up and re-upload it. This was a major inconvenience for them and was service-impacting, and the cost they were avoiding was really quite negligible (a few dollars per month), but it just goes to show the lengths to which some will go to abuse free services.

(Of course the fault was really ours for basing our billing on the final quota of the month as opposed to the peak or 95th percentile, but we were still surprised at the lengths to which people went)

No doubt there will be people who complain about any limits - but hey, there are people that complain about having to pay for anything. At least if limits are imposed in a way which impairs performance but leaves things functional, and if there's a relatively quick way to "pay up" to a higher level of service, the reasonable majority of users can't really have any complaints.

Of course, there are times when it pays to make an exception. Also speaking from experience, providing free resources to selected high-profile open source projects can make an excellent advertising opportunity.

Anyway, I'm sure you're on the case - just wanted to share a bit of experience learned the hard way! (^_^)

Thanks! That's an interesting story -- and we've certainly seen a few people doing, um, interesting things to stay within the free account limitations.

In general, we're using a metric internally that tells us how many "active" users we have; our aim is to keep a reasonably stable ratio between that and the number of paying users. That's probably a decent-enough rule of thumb for the time being, we just need to make sure that it doesn't suddenly shift one way or the other when we add new features...

@Cartroo: Welcome aboard. I think you'll find the PA community a great place to rest your hat and enjoy the scenery.

The staff is amazingly accommodating and if I do say so, the community is pretty awesome as well...☺

Oh, and I forgot: +1 for BTC!!

Do you have a pan with unlimited diak space?

No, we don't -- disk space costs us money to provide, so we need to set the price of each subscription to cover that cost.