Meteor and AWS Elastic Beanstalk

Hi guys,

I am aware, that there are some other threads out there regarding this combination, but most of them a pretty old and I just want to check the current situation, before I throw myself into the AWS world.

Current situation:
One Big DigitialOcean Droplet running my main app and mongo. This droplet has 8GB of RAM and 4 CPUs - so should be kinda okay. Thing is, that we are expecting a soon-to-come pretty substantial user bump and thus way more load.

–> I am thinking of switching to AWS with Elastic Beanstalk, as I really want something which properly autoscales.

I am currently already using mup and I am aware, that there is a plugin out there:
BUT: I also read, that the deployment times are pretty bad - some say around 45mins. This is not really acceptable for me.
Then I also found some blogposts out there like this one:
Again, this blog post is pretty outdated, uses a couple of “ugly” workarounds and all that.

So I guess my question is: is AWS Elastic Beanstalk suitable for meteor? If yes, which method of deployment do you recommend? I really need something which works reliably and as fast as possible!

I also already thought of doing the following:

  • Create/define a “base image” for my EC2 instances which run in my Elastic Beanstalk, which already has everything installed it needs except my meteor app itself
  • create a simple build script, which builds my app and uploads the bundle.tar.gz file to AWS S3
  • find some way (I am totally new to AWS!) to tell Elastic Beanstalk to begin updating my EC2 instances from this new bundle I just uploaded one by one
  • if EBS needs to scale up, just spin up a new instance from my base image, load the current bundle from AWS, unpack, npm install and go.

I really need some way which does not stop my main development Mac for like 45mins, because it needs to mup deploy!

Thanks for your input in advance,
best, Patrick

1 Like

The 45min deploy time only applies if you have a fairly large app, and used the default deployment setting, which is RollingWithAdditionalBatch. There are tradeoffs to using this, you get a fresh instance and you have no downtime, but it takes time to spin up and gradually transition your clients to the new batches. We have currently changed this to AllAtOnce, which simply replaces the app in-place, and you get 1-5 minutes of downtime, but the overall deployment time is faster 10 min in total usually with our large app. This is using our fork of mup-aws-beanstalk, which allows changing this setting. It has worked really well for us.

Hi @jorgeer thanks for your reply!
Unfortunately I can’t have a downtime that big, even like 30 seconds would be a problem. Besides that, is AWS / EBeanstalk, mup etc. working fine for you?
How do you host your mongodb? self managed EC2 or are you using something like MongoDB Atlas?

Another option is “Rolling”, which takes out a percent of your servers at a time, leaving you with lower capacity but without downtime, and doesn’t take that much longer than AllAtOnce.

It is working perfectly well for us with the cusomizations we have made.

For Mongo, we use Scalegrid, which manages EC2 containers on our accont for us in the same region as we have EB, so we have everything in once place.

Okay thank you very much for the input!
I am thinking of using MongoDB Atlas, which also provides AWS instances, so I would also have everything in one place.
And thanks for the tip regarding the “Rolling” option!
Any other input you can give a fellow Meteorfan like me who switches from a normal root (digitalOcean Droplet) to AWS? Was it difficult for you to spin up your first Elastic Beanstalk?

Not really, no. It was very easy to get up and running, I have 6 active applications running it at the moment, and monitor them using The default monitoring on EB / EC2 is so barebones.

Let me know if you need help with configuration, or finding the fork that allows changing deployment policy.

1 Like

I really need some way which does not stop my main development Mac for like 45mins, because it needs to mup deploy!

You don’t really have to wait for it… After mup completes the build and upload it to AWS, the rolling begins… You can actually disconnect then. The rolling process is handled by AWS beanstalk not the mup script.
Regarding the rolling options, I don’t think a long transition should bother you, the platform would be busy but no downtime and you can continue your work and check a while later that all is fine.