Tiny acquired Meteor because they want to build a profitable business. Their core monetization strategy is Galaxy. What changes to Galaxy pricing or additional functionality would increase the probability of you or your company using Galaxy?
For example, I think the best thing Galaxy could do is expand their offering from solely offering fully managed solutions to also offering an APM/tooling solution that can run on existing Meteor applications. This software would be a superset of the Kadira functionality but with extra things like:
Huge facelift on Kadira (but rebuilt into the Galaxy UI)
Proper server side CPU and memory profiling (similar to this)
Built-in monitoring, alerting, logging, and error tracking (even just a native integration with Loggly + Bugsnag + PagerDuty (or similar) would be great)
Automatic diagnosis of common Meteor specific perf problems, along with recommendations
Automatic diagnosis of potential sources of Mongo perf problems, along with recommendations
Admin panel with functionality for managing users and collections in general
The list of these sorts of things goes on and on. This version of Galaxy could be added to an existing Meteor project by just doing meteor add galaxy and providing an API key. I think people would pay a lot of money for this sort of thing (Qualia would).
This would allow partial adoption of Galaxy. Ideally it would help people gradually adopt the fully-hosted Galaxy service (which, IMO, also needs to be able to integrate with customer managed Kubernetes clusters and should also offer optional hosted Mongo).
Anyways, being profitable is Tiny’s number one concern and hearing from the community about how to increase Galaxy adoption would be extremely helpful for them.
So let’s hear it!
Edit: Also they need to add back free meteor deploy. Removing that was a large strategic miscalculation. It’s a great customer acquisition channel since there can be a painless migration from that hosting to Galaxy hosting.
Cheaper options, definitely. You want interest in meteor, and in order for that to happen, people need to be able to play with apps, and know it’s built with meteor.
A free tier would be beneficial for creating prototypes and sharing them. Attaching them to the meteor brand helps exposure.
A not-free, and cheaper option for low usage apps would be beneficial for hobby developers creating things for small amounts of users. Passion projects, things they’re not looking to make a living off of.
I don’t use galaxy because it’s so expensive. I’m not making a living off of any of the things I make on my spare time. It’s infinitely cheaper to host them myself.
+1 for meteor deploy. I use Heroku to deploy all of my hobbyist projects. It’d be even nicer if MongoDB management can be handled by Galaxy too, but I know it’s kinda far-fetched idea.
If Galaxy had a managed MongoDB, we never would have even considered other hosting options.
(Given that it would have had a good track record regarding performance and reliability. And somewhat sensible pricing)
Also, when we were beginning our journey with Meteor, we were pretty short on money (and users), so a cheaper tier for would have been great - otherwise it would have been very expensive when comparing the money paid to cpu cycles used.
I think @veered’s idea about APM is great and we would definitely be interested in paying for that now.
I agree. The free meteor deploy was a killer feature. The community was so much more vibrant, with all those working samples at your fingertips, like Codepen on steroids.
Thanks for starting this topic and I agree this should be the focus of conversation.
Decoupling APM for extra revenue
Lower starting price to at least match DO
Allow free tier with some limitation for hobbyist projects
I recall that many people were asking for auto scaling
Focus on appealing to Indie hacker and PHP converts and try to reduce the FUD around Meteor (especially the misconceptions around scaling, I think a scaling guide would be great addition) because ultimately that would be the source of growth.
In addition to Galaxy, other sources of revenue can be explored as well such as feature requests page with ranking influenced by purchased sponsor points, donation channel and also premium support services.
For us APM independent of Galaxy Hosting would be great. Like Kadira once was.
Another important feature for new users is to provide a mongodb with zero configuration. Just run meteor deploy and it runs, without the need to setup environment variables or setting up a db somewhere else.
I already do! It find it’s a bit slower than alternative though (especially pub/sub) - and I find that I’m looking for an alternative for a couple of apps I host due to price (these are either hobby or other less mission critical apps). It’d be great to have some kind of less expensive options.
Yes. The price point to beat is actually around ~10€ per month.
It’s not that hard to install Meteor and Mongo on your own virtual root server and create a build process which fires off every time you set a certain milestone in your Git repository.
Please, please, please: Allow changing the METEOR_SETTINGS environment variable of a deployed app.
This is a super standard feature of virtual infrastructure providers that support 12 Factor Apps, and you can find it in AWS, Azure, Rackspace, Docker, etc. etc.
The standard process is to Stop the running app, Change the environment variable by copy/pasting/editing, and then Start the app again. We don’t even need a full editor. Just an input or textarea that accepts copy/paste like Azure, and we can handle the editing and serialization in other tools. A full editor with code editing would be great, but we’d much rather have a minimal copy/paste solution in the near-term than wait for a more full-featured version.
Right now, in order to redeploy METEOR_SETTINGS, we have to edit the Meteor.settings file and Redeploy the entire app via command line interface. On Azure, AWS, and other infrastructure we manage ourselves, we can edit METEOR_SETTINGS directly, and it’s super useful and important in production. With Galaxy, we have to wait to do a redeploy and wait 45 minutes. Sometimes this happens while we’re traveling on the road or don’t have a laptop with CLI available. But with this one simple feature, devops out in the field would be greatly improved a hundredfold.
#1 feature request, hands down. Nothing else is even close.
#2 request would be if Galaxy ran on the HIPAA Tier of AWS and if Galaxy operators would sign HIPAA BAA agreements. Right now we can run 21st Century Cures apps on Galaxy, which is sort of like healthcare single-user mode. A BAA agreement would allow us to run in multi-user mode and support Enterprise clients. Average price point for AWS HIPAA Tier is around $400/mo/server, and infrastructure management services like Aptible and Modulus have averaged around $800 - $2000/mo/server… but a lot more process and procedure is involved.
From memory, at the time of the withdrawal of the free deploy (which was truly great), I believe it was costing MDG around $10,000 a week to provide. That’s a staggering amount of money. I’d be very surprised if we ever see it again.
Doing something like requiring an upgrade to paid Galaxy after a month or two could be a good compromise (and a limit on the number of simultaneous deployed sites per user). Still provides the magic Meteor sauce and would be a more effective channel for customer acquisition. Should perhaps also be paired with a lower cost bottom tier hosting option. Also if the cpu/mem was throttled it would ease people towards an upgrade if the app reached any real level of popularity. The important thing is to maintain the instant gratification of write code -> live site.
However, an exemption for atmosphere hosted packages is probably a good idea. I really miss live demo sites for packages.
The live demos were fantastic, as was MeteorPad. But there was definitely a hosting cost that became difficult to maintain. CodeSandbox.io seems to have stepped into niche that MeteorPad and MDG free hosting were occupying. It would be a really interesting exercise to try to figure out how much of a Meteor stack can be run on CodeSandbox. If we ditch DDP and go with Express, I’m sure we could build a release that runs on both.
Then add 30 - 90 days of a freemium trial, and you have a great mix of education pathways, conversion paths, etc. After 90 days, bump into the current price tier. And enterprise tiers after that.
For us it is the following, list. Please note that some points may already be available or collide with requirements of others. It’s just a list of our needs:
Builtin Mongo functionality
Clustering a db without the need to be a mongodb blackbelt
One db per app option for Microservice deployments
Fixed budget plans (scaling is great but our budget won’t scale so fast)
Access to nginx configuration
Private network ip for services, that are solely meant for private access
Zero downtime / autospawn process (like pm2 or passenger provide)
A staging plan with limited traffic and limited ip ranges (this limited costs) for access; Staging environment is so important yet it costs often the same as a prod setup, although just used for internal demos, usability testing and e2e testing. This makes it for smaller projects often hard to setup.
If the Galaxy services become the real all-included service, we can reason the higher costs at ease.
Cheaper tear for hobbyists and possibly a free tier (could be tied with MongoDB Atlas free tier)
Speed-ups
APM should be its own product for non-Galaxy apps
APM improvements
More regions and hosting options (add Azure and Google)
Firewall
Ngix access
Allow changing meteor settings
HIPAA tier
MongoDB addon
Free or cheaper tier for hobby projects
Personally I think 2 factor authentication should be #1 priority (possibly update to Meteor accounts?). Following that I think it would be realistic to focus on APM and metrics improvements and/or addons for Galaxy to bring additional revenue.
Personally for me I would like to also see more hosting options and regions with regional management along the lines of MongoDB Atlas with one deploy command and central management.
The original free tier meteor deploy was perhaps too generous; I think that they can provide a useful free tier that doesn’t incur that level of cost and still provides marketing and customer acquisition benefits.
For example, free tier apps could be auto-stopped after 1 week (requiring you to go into Galaxy and manually restart it) and auto-deleted after two weeks (requiring you to redeploy it). There could also be a limit of 5 free tier apps per Meteor account.
Note that to recapture the original free tier experience, they would have to auto-provision a free MongoDB (perhaps using the free tier Atlas).
For me, the simplicity of the original meteor deploy was a big factor in moving me to Meteor. I hope Tiny can figure out a reasonable, cost effective way to provide this capability again.