Hacker News Reader

Comment by callmeed | Hacker News Reader

Perhaps this isn't the best place to say this, but since Heroku is a YC company, maybe someone is listening:

I want to use Heroku for some upcoming projects, however they require the uploading of high-res images. Every time I've tested things on their free plan:

- Uploads over 5mb cause errors 50% of the time

- Some ImageMagick functions don't seem to be available

Are these limitations that paying plans don't experience? Or are my needs simply out of the scope of Heroku's target market?

I want to give you my money :) ... (BTW, congrats on all the growth)

View on HN

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

I use direct uploads to S3 to get around this. It works much better as a long term solution and you can easily do image processing somewhere else in the background.

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

Right, but doesn't this effectively double or triple your bandwidth usage on S3? (since you're uploading, downloading, then re-uploading)

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

> - Uploads over 5mb cause errors 50% of the time

the free plan only has 5mb of storage

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.

Reply on news.ycombinator.com