Meteor - Custom Deployment

help
1

I have deployed my Meteor Application on my local machine using:

Now during the process I used:

$ export ROOT_URL='http://192.168.100.2:9000'

Now my is not accessible on http://192.168.100.2:9000, but instead it is accessible on http://192.168.100.2:46223, so every time I do node main.js, it choose some random port for my application.

How can I specify a port of my own choice here?

2

Check the Meteor Docs.

3

I did used the command: $ export ROOT_URL='http://192.168.100.2:9000'

But as you know I am running my application using node main.js command, so how can I accomplish: ROOT_URL='http://192.168.100.2:9000' with node main.js command?

4

As the link explains:

export ROOT_URL='http://192.168.100.2'
export PORT=9000
2 Likes
5

This worked. I really appreciate the help I am getting from you. Thanks bro

1 Like
6

I need one more advice from you, since I was using the main meteor directory before and I was using git to manage my updates & changes, so how do I pull and push now? do I have to build/deploy again and again after the changes or I conside this node generated deployed bundle as my main application and integrated git in this bundle?

7

Application development usually goes through at least three environments:

  • Integration (development): your laptop, your developers’ laptops. This is where you collaborate on the building of an application, work on new features, fix bugs, etc. In Meteor, this is where you (and your co-developers) use the meteor commands and work on branches using git and GitHub.
  • Staging (QA/UAT): Usually a completely separate server (or container, VM, or instance) which matches your live environment in all respects except public access. No development work is done here: it’s used only to prove it works. (In a continuous delivery pipeline, you would employ a GitHub hook to trigger the build server to pull the release from GitHub and do a meteor build onto the staging server where it can be tested.) At this stage your app on the staging server is a pure NodeJS app - there is no meteor.
  • Live (production): When your app is proven to work in staging, you make a GitHub release, which (in a continuous delivery pipeline) triggers the build onto the production server in the same way as on staging.

Each of those environments can exist in multiple different places. Normally, staging and live are externally hosted. For small, in-house (intranet type) applications, they could run on any server able to run NodeJS within your infrastructure.

Clearly, for small applications, you can simplify the requirements, and build manually where needed. However, the key points are that you continue to use git during development, separate your development and production environments, and you do not run your production application with the meteor command.

10 Likes
8

Clear and concise summary! Rob, you are a gift to the community with your crafted posts!

Since I’m here: often with large applications with multiple sub-systems/teams and in corporate environments where ITIL rules (yeah, not everyone is lucky) and a continuous release pipeline is not possible, it is common to have a CI/Integration test environment separate from each development workstation.

4 Likes
9

Thanks for the kind words :slight_smile: - I was concerned I’d gone over the top.

It’s a difficult topic, given the people here are spread along the spectrum between hobbyist (not intended pejoratively!) and building commercial apps. What you should do may be wildly different from what you need to do. It’s not a “one-size-fits-all” answer.

5 Likes
10

don’t work for me (don’t show anything

âžś  bundle MONGO_URL=mongodb://localhost:27017/myapp ROOT_URL=http://localhost:3000 node main.js
11

Now It work fine
Linke