Help Tiny: What would it take for you to use Galaxy? (VERY IMPORTANT!)

deployment Galaxy
14

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.

12 Likes
15

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.

3 Likes
16

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.

6 Likes
17

+1 to what @veered just said.

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.

4 Likes
18

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.

9 Likes
19

Summary from Most Wanted Features for Meteor (with some updates from here):

  • 2FA
  • Improve APM
  • 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.

6 Likes
20

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.

8 Likes
21

The question is, if the free tier fits into the upcoming business model. It draws many back to the community (which is great) but not necessarily to Galaxy.

If there would be a budget tier, I would use it to show off some projects.

However, an education tier (students, schools etc) or an open source tier (coupled to an GitHub account/project) would also be interesting!

4 Likes
22

Not a big fan of Galaxy, it’s rather expensive compared to the competition. And I really don’t like a framework that looks like it only works well with its own hosting platform. It’s not good for adoption.

I’d personally prefer Tiny to support and extend MUP so that Meteor can be deployed anywhere by anyone at ease. Turn it into something similar like https://forge.laravel.com/ or https://envoyer.io/, including Kubernetes support.

Imo that would greatly increase Meteor’s changes for adoption, while also allowing people to run Meteor on cheap instances for hobby projects - something that is requested a lot.

6 Likes
23

For what it’s worth, I don’t find meteor hard to deploy at all. Running meteor build gives you a plain node project, then you can host that however you please.

For example, to deploy I just use this: https://www.npmjs.com/package/deploy-app. It builds, uploads, then restarts the server.

Config file for an example:

{
    "prod": {
      "user": "cereal",
      "host": "example.com",
      "port": "22",
      "files": "../project.tar.gz",
      "path": "~/",
      "pre-deploy-local": "meteor build ../",
      "post-deploy":
        "nvm use v8.15.1; rvm use default; tar -xzf ~/project.tar.gz -C ~/tmp; cp -rf ~/tmp/bundle/* ~/project; cd ~/project/programs/server; npm install; passenger-config restart-app ~/project
    },
    "dev": {},
    "staging": {}
}
5 Likes
24

a $5 tier— doesn’t even need a free tier. With this you could host 20 “example/sandbox/testing/MVP” apps and it’d only cost you $100/month.

For comparison right now it’s just under $30 per app at the cheapest so 20 apps would cost you almost $600, which is obviously too much for some side projects with 2 visitors a month.

Also becoming HIPAA compliant. Maybe they could get some pre-signups for a HIPAA tier to make sure it’s worth their investment (I bet it is).

4 Likes
25

In the end supporting MUP is ideal, but does meteor have any value to a company without galaxy?

1 Like
26

Name one framework that needs its own dedicated hosting platform to be valuable…

1 Like
27

I would like to have the settings controlled by the platform and not deployed with the app.
Among teams who do not have CI and everyone can deploy, you have to be certain that you have the correct version. Solution exists for that but looking at what wavehosting does has been a better flow for us.

28

My understanding was galaxy is the main revenue generating asset that was purchased.

2 Likes
29

Meteor-the-framework is valuable in of itself, but hosting is the primary way Meteor-the-company makes money. Mongo is similar. Mongo-the-db is valuable in of itself, but Atlas (their db hosting service) is one of the primary ways Mongo-the-company makes money.

1 Like
30

We really need a branding initiative to distinguish Meteor-the-tech-stack from Meteor-the-compiler from Meteor-the-company.

9 Likes
31

Get Galaxy run with Meteor accounts that don’t require local storage for storing login token, so apps can pass basic security audits and make Meteor more interesting to corporate customers.

This came up due to this related post:
https://forums.meteor.com/t/security-dont-store-tokens-in-localstorage/

2 Likes
32

This would open up HTTP/REST as an option for using Meteor accounts.

33

Thanks @veered for this thread

  • If your target audience is small teams, you should make it turnkey: bundle MongoDB (charge more of course). That would bring on board smaller teams focused on results (a bit like what Digital Ocean does. It’s nothing special, except it’s made for smaller teams)
  • Auto-scaling with EBS would bring in the bigger players (integrate redis-oplog)
  • Documentation: make it super easy to start and deploy a new project with sample boilerplates (e.g. no hard-coding of MongoDB URL – since we are using Galaxy it should automatically connect to the DB associated with the install)
  • APM – Kadira needs some love and very few of us have the bandwidth to invest. The code is AWFUL, needs to be cleaned up and made production-grade

PS: You don’t have to host your own MongoDB instances for now, you could work with a third-party provider and have an API into a common Galaxy interface

2 Likes