The state of Meteor and AWS S3 file upload?

I’m working on a file-upload heavy app, and for the past few weeks I’ve tried a couple times to set that part of the app up, without success. I will say I am a novice with files and AWS alike, so maybe I’m just making bad calls, but it seems like this is excessively complicated and/or unsupported at the moment.

I will be handling very sensitive data from our clients, and I’d like to have high security along with performance and reliability, hence my choice for AWS S3, which also keeps the cost down, compared to pricey mongoDB storage.

I’ve looked at the following packages:

  • CollectionFS: has an s3 adapter, that hasn’t been updated since 2014
  • Meteor Slingshot: No update since May 2016
  • Veliov/Meteor Files: Uses knox for the upload, which is outdated and no longer maintained.

Veliov’s package is probably the most promising, as they are planning to use EvaporateJS to replace knox. After several days of playing with a super basic file upload from EvaporateJS, I’m still failing, I have no clue where to start.

Is anyone successfully uploading files to S3 in their apps, and can help me out with this? Or is there another good production-ready solution?

1 Like

We do all the time with Slingshot. Go with slingshot. There’s not been many updates because it’s mature and stable, and does what it needs to do. There are pretty good examples scattered around the internet; and we’ve gotten it to work on both desktop and mobile, with camera and photo library, movie files, etc…


It is such a critical part of my app, I’m hesitant to use packages that seem to not be maintained, even the issue tracker of meteor-slingshot looks dead, and the company’s website is down.

With meteor changing so much in the past months, I’m not sure it’s wise to rely on it?

I recently used, it worked well and was integrated in our app in under an hour.


Thanks for your suggestion, Lepozepo’s package doesn’t seem to have much security built-in, to manage file access for each user, or various roles, such as admin users. Plus, it’s built on knox, which as I mentioned, is no maintained anymore.

But if my only worry was to simply get files up on amazon S3, I’d have achieved it already :slight_smile:

I’m using Slingshot without any troubles and can recommend it. I’m still on Meteor 1.2, though, so I don’t know if everything still works in Meteor 1.4. But I doubt things have changed that much.

CollectionFS has been abandoned by the dev team long ago. It was a nice concept, but probably a bit over-engineered. So they dropped it.

You could also use an npm based standard S3 connector, that may be the safe path. But Slingshot is quite nice since it does not require server roundtrips. Data is sent directly from the client to S3.

1 Like

I’m also using Slingshot for quite some time without any problem. If you need to process files after they are uploaded, use amazon lambda with a hook on s3 PUT.


+1 for Slingshot, and I have tried all the previous solutions :stuck_out_tongue:

Since it’s quite stable, I just copied the package to my local code and modified a few small things to meet my needs.

1 Like

+1 for slingshot. Using it on both mobile and web for photo uploading in 1.4

It still does work normally, I use it in my app.

Meteor 1.4+ and using Slingshot in two apps.

If you look at the source code for Slingshot, it doesn’t do anything too magical; it uses standard javascript APIs. The only “complexity” is getting the tokens from the server, which don’t inherently have anything to do with slingshot itself, but more so the service you are using (AWS, Cloudinary, whatever).

I only mention this because I had the same worry: using an outdated/unmaintained package. I looked at the sourcecode… it would be very easy to move off of it and roll your own. When I had to do a custom implementation to upload to Cloudinary, I was really apprehensive and worried about it, but was able to do it in an hour or so with Slingshot. And I promise you I am by no means a wizard.

Thanks @moberegger, that’s the information I was hoping for! I didn’t dig in the source code to check it out, which I should’ve done.

Slingshot seems to be used by most here, so I’m much more confident about this decision, thanks !

@M4v3R, sadly knox doesn’t support new AWS servers, so no love for Frankfurt, which is the one I need to use!

Meteor-Files could be another option that seems solid.

1 Like

I ended up using Meteor-Files but you have to write the AWS integration yourself. I wanted to crop/scale client-side before uploading and I couldn’t get slingshot to work with the edited files. Meteor-files is “simply upload/store/serve files to/from server” and everything else, like upload to third-party storage is diy. They have a dated example which actually worked for me. I had also tried a variety of different NPM image/file manipulation packages with no luck for my use case.

1 Like

Anybody can explain to less experiences how Slingshot image API talks to AWS in terms of encryption?

  1. Do we need to have our app page served from HTTPS?

  2. Is there an encryption with public key that encrypt messages from our app server to AWS (for tokens) and from client to AWS (for files), so no need to have a secure connection?

  3. About when we use files (such as images displayed in our app) (from AWS to our app): Do we just need to declare the URL (from another domain) in our Browser rules, but if our app is HTTPS, I suppose AWS should be HTTPS too, no? But it is not of the same session, same server. I do not know how security can work.

  4. Same thing for simply downloading files from the app, not displaying it.


1 Like

I did not try them, but there are also some Youtube videos about Slingshot.

Yep, we’re using Slingshot in our production app as well. Works very well with no issues!

We are getting ready to migrate our app from CFS:gridFS to Slingshot. Glad to hear all of the success stories.

1 Like

Structural question for those of you using Slingshot:

In a typical file structure like this:

  • server/
  • client/
  • imports/
  • api/
  • startup/
  • ui/

Where do you write the Directives, so that it’s accessible on both sides, and where do you add the file restrictions in a DRY way?


I have my app set up like this:

  • imports/startup
  • client
    • S3.config.js (with file restrictions)
  • server
    • S3.config.js (with Directives - directive contains file restrictions as well as per documentation)

I guess it does repeat the two lines for the restrictions… but I’m not losing sleep over it.

1 Like