Heroku IPs are 75.101.163.44, 75.101.145.87, and 174.129.212.2, if you want to update the script to make the distinction from raw Amazon EC2.

Yeah, I was confused by the lack of people using Heroku.

18 now. ;-)

For sub-hour scheduled or recurring tasks, most users prefer a scheduled background task with DJ, rather than old-school cron. There are a bunch of ways to do this, for example:

   Delayed::Job.enqueue(work, 0, Time.now + 5.minutes)

Docs: http://docs.heroku.com/delayed-job

Great! I posted that hoping that there would be a solution. I've looked around delauyed job trying to find some scheduling funciton but I didn't look close enough it seems. Thanx!

This article contains quite a bit of inaccurate information.

Despite the size of 22 double-XL instances, they were a small portion of our overall footprint in EC2; it takes well over that kind of capacity to run the platform.

Those instance types all happened to be in one availability zone for a variety of reasons. Our platform overall does not live in a single zone.

Losing machines is not a problem for us (we cycle them constantly, in fact). Normally losing even that many machines would not even be noticed by our customers; this was an unusual case in which several factors cascaded into a larger problem.

To be clear, this downtime (45 minutes or so, with full normal state by 90 minutes) was, unfortunately, our fault - not Amazon's. EC2 instances vaporizing is an expected part of using the service.

We've made a couple of operational changes that will prevent these issues in the future, and we sincerely apologize to any customers who were affected.

Transfer between S3 and your Heroku app (which lives inside EC2) is free.

We've seen a ton of Couch and Mongo apps lately - works very well with Heroku. Check out http://www.mongohq.com.

Storage limits are for database data only, they don't apply to assets like uploads. Assets should be stored in an asset store, like S3.

Correct, the editor is no longer supported. We hope to bring it back sometime in the future.

Now that will be specially interesting for people that want to develop using Chrome OS computers.

You could build on bespin, they have git and hg hook, I guess a heroku hook would be less work than supporting a whole editor.

Exactly. Most people use DelayedJob to do image processing in the background - also the correct/scalable way to do it. More here:

http://docs.heroku.com/background-jobs

http://docs.heroku.com/delayed-job

Thanks for the feedback.

=== ImageMagick

We have a couple thousand apps using ImageMagick/RMagick, and haven't had any reports of missing functions. We are running ImageMagick 6.2.4 (will be updated to 6.3 sometime soon), so you might check that, and also be sure you aren't trying to use custom-compiled options. If you still have trouble, open a ticket and we'll take care of it: http://support.heroku.com/tickets/new

=== Uploads

We also have thousands of apps doing large file uploads. They should be done as described here: http://docs.heroku.com/s3

Specifically, for larger uploads (we recommend for anything bigger than 4MB), it's wise not to run the upload direct to a dyno, tying up one of your app servers and risking a timeout - it's just not a scalable way to do it. A good pattern is to upload direct to S3 instead, as directed at the bottom of the page. We recommend the S3 SWF Upload plugin: http://github.com/GreenAsJade/s3-swf-upload-plugin/tree/mast...

Thanks James. I appreciate the info.

Right now, I prefer to upload to the local filesystem then process and store on S3 via DelayedJob. But I will give this a try.

Are there any plans for add-ons that allow EBS storage (or something along those lines)?

We aren't planning to provide any additional types of file storage, as we don't believe that the local file system should be used at all in a scalable app, as it creates state at the app server.

We do provide access to /tmp if you need scratch file space for processing (it is not persistent between requests). More info here:

http://docs.heroku.com/constraints#read-only-filesystem