I’d love an update on experiences too!
Looks pretty good!
Java 7 required for CLI?.. interesting choice
@neglexis and @jononomo My experience has been pleasant so far. To deploy an app is really simple and quick. It’s impressive. I run into a bit of issue deploying an app based on Meteor 1.3. When I contacted them about it, they quickly fixed it. Give it a try and also share your experience.
it’d be great to see a few benchmarks to demonstrate if these database views actually do remove CPU work from the Meteor app
Anyone else have any feedback using NodeChef?
I haven’t deployed yet (like I did on Modulus.io) but the process seems more complicated to me (I’m not a Linux expert). First it asks to download a CLI which requires Java7. That’s a hurdle that other PaaS companies don’t offer.
Secondly the configuration seems difficult through parameters you have to set when you deploy (like size of database, number of containers, memory). If it’s all about hosting Meteor apps which is great in building a UI in a couple of minutes I wonder why NodeChef is focused so much on Linux style command line.
Their prices are lower than the competition for the entry offers. How that holds up when you have to go with a larger amount of memory or more space for your DB is another point.
There is no possibility to not pay for pay for 100MB of database when your DB is hosted somewhere else (eg like in my case with Compose.io).
There is no process where again an UI is guiding you through creating a configuration file. Again, you’re been forced by writing such a file on your own. This has turned me off so much (as I don’t want to spend hours on figuring out what I might did wrong) that I haven’t tried to deploy my app yet.
The hero message of “One command deploy” isn’t true. I have to do 11 steps (see https://www.nodechef.com/deploy) to deploy, this is far away from the promise of “One command deploy” or I’m to harsh on that marketing slogan.
The website itself has logical errors. I’m logged in and it shows me “Sign up” at the end of the Meteor page. It looks more like a project of a couple of enthusiastic coders than a serious company that is there to help you when things go bad. In short, it doesn’t look and feel professional to me (please note you might feel different about it, this is my personal opinion and feeling).
As I haven’t deployed (and probably won’t if I run into problems quickly) I can’t say anything about benchmarks or comparison vs my current provider Modulus.io
1 Like
Actually most PaaS allow you to deploy using cli or git. Modulus allows git or web upload. NodeChef allows cli and thinking of potentially adding a web upload and git.
Actually, when you deploy your app, you don’t have to set the database size and memory and number of containers. All apps are deployed with one 256 MB app container and the 100 MB database container. There is already a UI in place to scale the number of containers, memory and storage.
We do understand that some prefer a UI and so we are gradually moving many parts to give developers the option of configuring using UI. For example, now you can set up routing and custom domains using a simple UI.
When your data grows, you will still be saving a lot with NodeChef. With query tailing to solve all scalability issues, you won’t be needing lots of containers to scale your app. High data compression and efficient memory usage all save you money. Something you’ll hardly get with other providers.
One of the reasons NodeChef has become very popular is that we offer a one stop shop to host your app and database. That’s great value for many developers.
We are gradually moving many aspects of the deploy process to utilise UI. And I must add that you don’t have to spend hours figuring out stuff if you did something wrong. Our Support team will gladly assist you if you encounter any difficulties.
To deploy your app without setting any custom environment variables. Use the below command
deploy -i simple-todos
Most of the steps are just guides to help you understand the process. After you deploy your first app, you won’t need many of the steps you see. Many appreciate these steps.
The website and platform is not perfect. We are constantly looking for ways to make things better.
We want you to deploy with NodeChef. We will guide you if you need it. Go ahead and give it a try and you can report back with performance etc etc…
Thanks for your time.
3 Likes
26 days later. Hmmh, I assume you guys were hopefully busy developing your NodeChef further otherwise such a long response time isn’t really top notch (and yes, answering in forums like these is part of your marketing efforts, as I see you constantly pointing out that NodeChef exists as well).
You didn’t get my first point. None of your competitors requires me to download Java 7. I don’t want to download software or install Java on my computer. There is no need for that.
As for all the other answers I stick to what my opinion back then was. I don’t need your DBm I have Compose.io and not only I’m very happy with them but these guys are way beyond anyone in terms of service and response time on request (hear that Modulus? So much about you reach us outside of our very minimal business hours).
So unless you want to follow my feedback and make it a lot easier (again, like your competitors do offer) to deploy to NodeChef I’m not going to become your customer or switch away from Modulus where I can deploy with one statement (and not just a sample ToDo app but my app). No JSON file needs to be hand written or some other weird stuff only the geekiest of Meteor devs are able to do.
Seems to me that’s your target group but then again if I would have those skills then I could deploy myself to DigitalOcean or AWS and again there would be no need for NodeChef.
Seriously check where you guys want to position yourself in the existing market and come up with a positive USP. Right now I only see a negative USP (aiming at geeks which can and will deploy rather themselves than configuring your system).
Unless you’re making it extra hard by your UI to deploy to distinguish from the Modulus, Compose and Galaxy competition. Than your plan actually works, for once.
I suggest to go back to the drawing board and pivot, come up with a different approach. Not pivot entirely but become unique. Copying and doing worse than the existing ones is not disrupting a market, it’s a recipe for bankruptcy.
Oh and just to add a bit of background to my statements, I was SVP of Marketing for a large Telco and thus being responsible for its 15+ million customers in my last job. I’m coding just for fun 
Hope this feedback helps. I don’t want you guys to fail, hence my two cents worth of advice.
1 Like
So… is anyone running critical production app on Nodechef currently?
I have been evaluating the Nodechef service and am quite positive but personally I will wait a while for their documentation and tools to become more mature. With the knowledge I have now I could deploy my app first time within a few minutes and it would be running very smoothly I think. I have not stress-tested my app but the Nodechefs setup feels real good.
The deployment-tool is written in Java which I think does not give confidence when you aim to be a big player in the Javascript/Node/Meteor/Parse world. But, I must admit, they are quick to incorporate feedback, very quick with email replies and the tool works ok.
A little sidetrack about the Mongo hosting they provide. I was only succesful in using it remotely from a mongo version 3+ shell and not from a Meteor project (which I think uses Mongo 2.6.7) so beware of that. I think I read somewhere that Nodechef is able to provide a mongo_url/mongo setting that is compatible with lower Mongo version but I can not remember where I saw it and if it is true.
The Nodechef trial I got was for the $15/256MB version while my app only used around 100MB. So I would have preferred to be able to test the $9/128MB version instead.
2 Likes
2 more cents:
I’m currently working on an app that’s about to go live (er… in a couple weeks…). I’m the sole developer on it and need a good deployment option that’s as easy and headache-free as possible, and so far I’ve been floundering. If I’ve learned anything about this one-man-show type of work it’s that devops of any kind make me feel like I’m suffocating.
So straight AWS or GCE were out of the question (though not until after some serious, drawn-out, self-inflicted pain involved in trying to get a basic deployment working…), and I needed to find a platform instead. Heroku is by far the most mature platform I’ve come into contact with, but they have much bigger customers to cater to than any Meteor developer that I’m aware of. As such, it feels pretty second-class hosting a Meteor app on heroku, third-party buildpacks seem janky, and I’ve heard horror stories about SSL and scaling on it.
Then I tried Modulus, and was happy (no, extremely happy) with the simplicity of deploying, the dashboard, the autoscaling, everything. I would have stuck around until I started digging into the docs on setting up SSL. They don’t offer LetsEncrypt, so you have to pay for your own. Fine, but the idea of manually setting up my own certificate brought me back to the drowning-sensation that anything devops seems to induce. They also offer an ExpeditedSSL addon, which promises to bear some of that pain for me, but quite honestly it doesn’t feel trustworthy (their latest social media and web copy updates are from fall 2015), and the additional $15/month/subdomain isn’t too attractive.
Then I saw a promotion for Nodechef, which offers LetsEncrypt via a single terminal command. Sold. I signed up and got a Meteor app running, after a few hiccups that support tickets resolved. I shouldn’t have had to make the tickets at all, and wouldn’t have needed to if the docs had been clearer, but I was happy with their email response time nonetheless. The process of actually deploying is, I would estimate, about as dev-oppy as deploying to Heroku was. Not insurmountable, but not delightful like Modulus. Nodechef’s docs and general website design are clearly unpolished, and I think they would do well to fix those things — coming from my perspective, someone who needs his hand held through the entire deploy process, this is very important. Their integrated “MongoRocks” database is intriguing (and it’s really key that they offer the alternative of using an external Mongo database such as mLab if you’d like to), but it’s not a huge selling point for me at the moment. It’s a cheaper option than mLab, but I’d like to see a third-party performance/cost/ease-of-use test before being sold on it. Still, if they exploit that feature and convince me of why it’s a good database option, that’s another distinguishing factor they could have over competitors.
Since I got something running on Nodechef currently, with SSL working, I’m going to stick with it for the time being until I get my app launched and some of that initial pressure off my back. The other option that I have in the back of my mind is Galaxy. They have the obvious clout of being supported by MDG, and deployment looks Modulus-level simple. But to me (the non-devops guy), the process for using LetsEncrypt with Galaxy looks absolutely hellish, and is a non-starter. I know they’re working on making it easier, but until such a time I can’t justify going through that process myself.
Galaxy (publicly) and Nodechef (in an email response to me) have both said they are working on implementing autoscaling rules. This would be a huge feature, and my bet is that if Nodechef accomplishes this first (along with more professional-looking docs and web UI), they’ll offer a serious advantage to Meteor developers (especially the wide base of small-time ones). An improved CLI/deployment process would certainly help in that regard too (e.g. it feels pretty ridiculous to meteor build .. --architecture blah blah blah first, before deploying to Nodechef, and not having to do things like that would remove a barrier for people with even a slightly weaker stomach than mine). But if Galaxy beats them to the punch, adding autoscaling and and easy way to use LetsEncrypt first, then I’ll more than likely switch to them as Nodechef will offer no real advantage for me.
TL;DR: A good + easy + cheap Meteor deployment trifecta doesn’t exist yet, and Nodechef hasn’t — but still has a chance to — taken advantage of this opportunity.
4 Likes
My experience using nodechef is here:
it’s been good so far and it definitely feels a lot faster than my previous MUP DO deployments. Although I have yet to run into any scaling challenges, it will be interesting to see how it handles that.
To me it’s really important that there are at least 2/3 competitors to Galaxy that support Meteor as a first class platform. Despite all the great work, I do feel like the framework is a little too dependent on MDG sometimes…
@pauljohncleary, that blog post was actually one of the things that convinced me to give it a try. Reading about someone else’s experiences with it lends a lot of credibility to the platform (one of the things that Nodechef does a less-than-stellar job of for themselves).
My own test app definitely feels fast on Nodechef, although at the moment I’m the only user 
But that’s why autoscaling, even very basic autoscaling, is a really great selling point. It’s not that I personally, as a small-time developer, thing I’m going to get super popular. Rather, it’s the “what if I get mentioned off-handedly in some blog post somewhere and my only shot at an influx of users is ruined because I was taking a whiz when it got posted and the new visitors were left with a blank loading screen because I wasn’t there to manually scale up the instances” anxiety that’s alleviated by having autoscaling rules in place. I tend to think I’m not alone in that fear.
1 Like
Hey @alexpete thanks for sharing your experience!
It’s been 2 months now since your last message. Are you still using NodeChef? I am considering joining it, would like to hear how things are going up till now
Please don’t use these scammers. They just charged me $290 at the beginning of the month. I’m trying to cancel my service with them now, but they won’t refund the money.