State of Meteor?


No, this is a commercial application which we sell to high schools and colleges/universities that teach business courses. I’ve been the principal developer since the start and we have gradually added a couple more engineers on the team. For such a complex application is is amazing what we have been able to accomplish with so few developers, and it has a lot to do with Meteor. We crank out features like there is no tomorrow, which is so easy in Meteor.

While we are not yet up in the thousands of concurrent users, I am quite confident we can handle it once the time comes.


We have been using MeteorJS for over 3 years now. We currently have 7 website from our business running through meteor and it has worked flawlessly. Our biggest website manages around 50,000 concurrent users and we get to some points where this even gets higher. I have worked with Meteor for a very long time and its thanks to this that are company is where it is right now.


50k ccu - fantastic! Could you please tell us a bit more about the server configuration – how many, what size, etc., and the web host?


wow, 50k is huge number.


Currently we are using Meteor Galaxy for this. Even though its a little bit expensive over other solutions like Digital Ocean, it takes form our hands the whole devops tasks. We currently have 3 double containers (2GB RAM, 2.0 ECU) and this handles everything perfectly, we are even hitting only 60% of the CPU and 75% of RAM.

We are looking for a devOps so we want to change to a more personalized server configuration made with nginx and digitalocean (this way we can reduce our costs for more than half of the price).


50K ccu is a huge thumbs-up for Meteor and Galaxy!


Coygo ( is built w/Meteor, Vue and meteor-desktop to bundle an Electron-based desktop client from the same codebase as our website.

We’re hosted on AWS using Fargate for a managed docker container service without any complaints so far, but our user count isn’t anything crazy. Also since we’re a desktop application, we offload almost all of the work to the user’s machine when possible so our server’s load is extremely light and used mostly just for authentication, logging and analytics. Coygo is for cryptocurrency traders and requires users to enter their exchange account API keys, so we kept it as a desktop application so that their API keys never have to leave their machine and all trades can be executed from their machine instead of our servers, for security reasons.

Meteor has definitely dropped in popularity over the years, but it’s still a great option for smaller dev teams. It’s extremely stable, you know what you’re getting and it doesn’t really need lots of updates/changes anymore. Hosting is a bit of a pain but once you get it set up you shouldn’t have to mess with it too much again. The built-in user system (accounts-password), the zero-config build tool, ValidatedMethods for RPC communication, and reactive pub/sub are still great and work well as long as you’re careful about how much reactive data you publish. Meteor + Vue remains my favorite stack.


Wow. ~94kb(2GB* 3 * 0.7/50k ccu) RAM per user, fantastic :face_with_raised_eyebrow:
Do you use subscription?


I hate to be the jerk to rain on someone else’s parade, but the only way I’d believe 50K ccu on 3 doubles is with a screenshot from the galaxy control panel. I would be surprised if you can handle 3K ccu.


+1… 50K CCU on 3 Galaxy Double’s!!!.. c’mon dude. Prove it please @juanpmd #NoPhotoshopEither


We have a growing Meteor app in production for 3 or 4 years now. Pre-Galaxy using MUP on AWS EC2, then switched to Galaxy. We’re behind a few versions on Meteor. Still on Blaze. We’re more focused on the app than the version of the framework - so we haven’t fixed it since it hasn’t broke (yet).

Our app handles huge bursts of users (often thousands) at live events all descending on the app at the time time. So it’s had some unique challenges. A couple of notes:

  • We learned very quickly to deliver the app-bundle through a CDN and not the Meteor server - doh! I have a really long post about figuring that one out.
  • The micro-service that handles all those user bursts had to be stripped of all pub-sub. All client-consumed data is delivered using cached Meteor Methods and thus heavily debounced off the database (this was a huge breakthrough). Anything real-time is updated with laser-focus for bare minimum overhead via redis-oplog’s manual Vent tool.
  • All client responses are also handled very carefully using caches and special update techniques to the database to minimize pressure. We basically “round up” groups of responses versus sending them one-for-one to the database (another huge breakthrough)
  • On the admin UI’s we use pub-sub with redis-oplog. Any graphical element (e.g. a chart, graph, etc.) that is representing all that response data in real-time using Blaze and Meteor’s default real-time “magic” will grind a user’s browser to a smoking halt as thousands of responses flood in within seconds of each other. I think this is more Blaze than anything. Had to turn all that off and switch to publishes with polling and/or more intelligent updating in certain situations.
  • We use redis-oplog. Every now and then there seems to be some quirks we’re still working on but for the most part it’s solid. And can handle a lot of traffic.

Overall though, we’d be nowhere without Meteor. I’ve wondered where we’d go if Meteor slows down enough and gets left behind. Maybe next.js? Not sure. Glad to hear @veered’s comments.

I also wouldn’t mind getting off Galaxy if there’s a home-grown solution that handles container scaling and rolling updates as well - with the user’s browser just refreshing to the new version.

Starting a new project on eCommerce platform, and confused on which JS stack to use? Between MeteorJs and AWS Amplify, which one should we choose and why?

I just have wonderful things to say about meteor
I have a few web apps running smooth for 1 or 2 years, related to IoT

I just have one single complain, which I really want to overcome
I can’t make a form that can upload an image along with other kinds of inserts (tried autoforms, uniforms, no success)
Other than that, I’ve never had a problem, but anything that requires that image upload form, I just can’t do it on meteor, and I had to migrate those to something else

But that’s me being too noob I guess


What’s stopping you? We use slingshot with autoform, in the before submit callback we trigger the upload, then add the S3 key to the inserted/updated document


Another option is to use ostrio:files
With it you can self host or integrate with file hosting services.

I developed 3 production web apps using meteor.
First one is a panel for large sellers control deliveries and requests. Second was a book companion which recorded your reading data and progress.
Working now with a GeoSpatial data viewer, using some data to generate reports and graphs.

I believe that Meteor help me achieve a lot of things that I had to spent a lot of time figuring out in other frameworks.


gonna give that a try, I’ve tried all sort of methods, even tried other people’s developments on the subject, but none worked on my side, even clonning their demos, the uploads never worked inside a form, and the ones that worked didn’t use autoforms/uniforms, they used simple non reactive forms. I just hope this is what I’m looking for.

I tried ostrio:files, and Indeed managed to upload images, the problem is, I never got to make it work inside autoforms or uniforms, but again I think I’m missing the right knowledge there, some people say I just need a wraper to make it work, but I don’t know how to make one, and I can’t find documentation about using both things together :frowning: .

If I ever manage to do that, there’s no project I wouldn’t be able to make in meteor, it’s pretty much my dream right now.


I see - I think I misunderstood you, I don’t know of any way to do it with a simple autoForm, we use something like this for the HTML:

       <img src="{{logo}}" class="col-md-3" id="logoPreview" />
       {{> afFieldInput name='branding.logoKey' id="logo" type='file' value=""}}

then in the before.submit hook we do something like this:

    doc.$set["branding.logoKey"] =;

Its a bit more complicated as it’s async, but basically uploadWithSlingshot returns the key of the upload in an S3 bucket.


I am currently co-maintaining ostrio:autoform-files so let me know if anything is not working. Just leave an issue on gh even if it’s just for seeing more examples / better documentation.


We could probably extract this into a package if it was of interest/use to people


We initially used ostrio:files, but had problems (not related to autoform) so ditched it in favour of a roll-your-own solution using slingshot, it took a lot of the load off of our servers and improved our reliability significantly


I think this would be actually of huge interest to the average joe like me

@jkuester thanks, I actually read the ostrio wiki and found a lot of usefull info, but sadly coudln’t get enough to make a form work with it. I’ll leave an issue on gh as you suggested and hopefully get a small example using files in a form, thanks a lot!