Meteor hosting providers

deployment
1

What are some providers that officially support Meteor hosting, making it super easy to deploy a Meteor app with single click upload or git integration?

I’m not referring to any host that can technically host a Node.js server, but host that specifically support Meteor and make it easy to import a Meteor app.

The only two I know currently are

Any others?

EDIT (based on comments):

2 Likes
2

Never used it personally but zcloud supports Meteor and @filipenevola is the CEO

1 Like
3

Fly.io is sort of split between both definitions. They host a lot of things, but they now detect Meteor 3 apps and automatically configure them like they would a typical Node or Python app. See: Run a Meteor App · Fly Docs

Note: I haven’t tested their Meteor support. I use Galaxy exclusively for Meteor apps at the moment.

1 Like
4
2 Likes
5

I’m on https://scalingo.com and those guys are awesome! Hosted in EU, push to deploy via git, you get mongo containers, redis aswell, scaling works like a charm and the support is really quick and helpful. Disclaimer: this is not a paid ad, I’m just genuinely satisfied with their service.

1 Like
6

I am also on Scalingo and also couldn’t recommend them enough!

1 Like
7

Railway looks awesome.

1 Like
8

Anyone try fly.io hosting yet? By default it won’t connect user requests to the same machine every time for “sticky sessions”, so I wonder if anyone’s tried it and had any issues configuring it to make sessions sticky.

9

https://tiiny.host looks nice and simple, but their Push To Deploy didn’t allow my repo because it is bigger than 75MB. Argh.

10

I tried NodeChef.com again and the nice thing about it is that, when it has no issues, it simply just works, including built-in MongoDB. Just connect GitHub, select repo and branch, hit deploy button. It is too easy.

However! NodeChef support is the least responsive. They often don’t respond at all, even if it’s a problem on their end (f.e. sometimes SSL setup doesn’t work, or some other issue). Other than those issues, most of the time the deployment is very simple to perform.

But the TLDR for NodeChef: don’t use it because if you do experience an occasional issue like their SSL not configuring itself properly, you will be stuck on a whim until they might realize and fix it.

Before trying NodeChef again, Galaxy updated my apps to Metal, and deployments stopped working with no way in the UI to revert, and no way to configure my build commands. That prompted me to go to NodeChef to get things running.

EDIT: just tried Metal. The team added the ability to customize the install/build command.

11

I switched to Railway, at least for now. It was a bit more work than with Galaxy to get up and running, having to set up MongoDB and having to figure out how to connect it to the Node instance.

The reason for the switch is that Galaxy currently has intermittent network failures across regions reported by users, and verified by myself using VPN. After switching to Railway, there are no network failures, and the same users who had issues can now access the app.

The Railway management system (apart from having to do some custom work for Meteor setup because it does not natively know about Meteor, but it knows about Node.js and MongoDB separately, requiring you to deploy the Meteor Node.js code as one service and then connect a separate MongoDB to it as a separate service), is that all the services you deploy for a project are on a visual canvas with floating boxes for each service, and it shows lines connecting the boxes to help you visualize exactly how your internal network is set up.

It has a variable system to allow any services to connect to other services, where variables from one service (such as MONGO_URL for the MongoDB service) can be used by another service (f.e. the Node.js service), and this is what causes a line to connect the Node.js service to the MongoDB service in the visual canvas. For example my Node.js service has a variable MONGO_URL that has its value set to ${{MyMongoDBService.MONGO_URL}} which will automatically fill in a MONGO_URL env var for the Node.js service when it is launched.

This is very interesting because I can configure, or replace the MongoDB with a new one, and the URL will magically stay updated behind the scenes (no need to copy/paste mongodb://user:pass@domain.example.com URLs around.

There are also global variables. Why this is powerful: you can define vars like PROD_URL or DEV_URL, and then you can make multiple app instances in multiple regions, each as represented as visual nodes on your visual canvas, and you can easily set ROOT_URL to ${{PROD_URL}} or ${{DEV_URL}}, and use it as a template. Any time you replicate a node into a new region, or in the same region, it can use the correct global URL.

Then, you can change the shared variables globally, restart the containers, and they all use the new URL! So this makes management of config really easy.

All of the Railway configs can be exported and saved into a JSON file in your repo, giving you more control (f.e. deploy a new instance from git, and it will use that config file rather than via the Railway UI).