Super Simple and Free Meteor Deployments using ZEIT ▲now

announce
21

Turning off automatic scaling might potentially solve the issue making your solution the best choice for small mvps!

In that case data should actually persist even though only Zeit’s guys know the actual answer :slight_smile:

2 Likes
22

@mostafiz93 try this. Free meteor app deployment. We used have it from MDG before. You could just do meteor deploy and it would deploy it to a yourAppName.meteor.com for free. Tons of atmosphere packages homepage used to live there. But the amount of useless todo Apps got way too bigger and mdg was bleeding money. So they stopped it.

Now this service looks promising for your needs.

Good luck. Let me know if this has solved your issue.

2 Likes
23

@purplecones Following up from my workshop. Students had a great time with it, with two notable exceptions:

  • Lack of Windows support; there was an error with splitting paths if I recall correctly. It would be nice to print an error if run on Windows for now.

  • Some students had trouble installing it, and had to install with sudo. This might’ve just been a bad npm installation though.

2 Likes
24

Glad the workshop went well @athyuttamre! We are planning to support Windows very soon and will keep you updated when that happens.

4 Likes
25

@athyuttamre we merged in PR that adds windows support to meteor-now.

Update with npm install -g meteor-now to update to version 0.2.0 and give it a try now.

6 Likes
26

Great, thanks so much!

27

Thank you! Thoroughly enjoying how easy deploying is with this.

A problem I had at first was figuring out what to set the ROOT_URL to so that I could get my google authentication to work, since you don’t know what the actual URL is going to be until it’s deployed. The workaround I found was that you can just choose a https://some-name-that-is-not-taken.now.sh, use that for your ROOT_URL, and then, after it’s deployed, run now alias (the actual URL that Now gave you) https://some-name-that-is-not-taken.now.sh

1 Like
28

I can’t tell how much ram and CPU they provide even for paid plans.

29

Love ease of deployment with Now, and love Meteor.

This seems perfect. Going to dig in to see if now alias, now scale et al are supported!

1 Like
30

I’m only just learning about using ZEIT with Meteor. A couple of quick questions regarding using it for production (this thread seemed the best place to post the questions):

  • What happens to existing active users when you now a new version (deployment) of your app and update your alias to that new deployment? Does ZEIT gracefully reload your existing active users with a refresh similar to how Galaxy does? Supporting sticky-sessions successfully?
  • Galaxy uses all the most optimal packages and softwares via it’s docker images that are setup by MDG (I assume) to work optimally with the specific version of Meteor you’re deploying with. They also bundle common tools like GraphicsMagick, etc. How is this done/accomplished with ZEIT?
  • How long does it take for a typical instance to spin up? Just curious about this. As with Galaxy it’s usually a few minutes (at least with my app).
  • Is ZEIT’s 1 “CPU” per instance roughly equivalent to 1 ECU? (As in how Galaxy’s Standard containers have 1 ECU.)
  • What cloud(s) are they on?
  • If I understand correctly, on the Pro Plan if I max everything out with scaling settings, I can get 25GB RAM and 25ECUs to split up between my app, micro-services, and Meteor APM instance for $50/month? Seems too good to be true.

The pricing on an initial read-through seems amazing compared to Galaxy. And with all those instances you could deploy your own Meteor APM, all the micro-services you need, etc. Anyone having good Meteor success in production?

31

Sounds like it is too good to be true. According to this thread, on ZEIT’s latest v2 version of their cloud, you can’t set the min instances to anything above zero on a deployment. So all apps, services, APMs will eventually scale down to zero and be “frozen” upon lack of activity. Not necessarily a bad thing if they can be unfrozen in less than 200ms (and self-heal at the same time). But this explains the pricing - resources get reused from inactive apps. And it actually seems like a smart idea and business model. Most of these types of apps probably don’t have a ton of traffic.

But this then begs the question:

What about a service that needs to do cleanup, updates, maintenance at some point in the future - e.g. thirty days after a user signs up, end their free trial? Etc.