我運行在EC2上我的流星的應用程序是這樣的：node main.js（在TMUX會話）更新部署流星應用程序 - 最好的做法
下面是我使用的步驟來更新我的流星應用：
1）流星束app.tgz
2）SCP app.tgz EC2-服務器：/路徑
3）的ssh EC2服務器和連接到TMUX
4）通過CC
5殺當前流星節點處理）提取app.tgz
6）的提取app.tgz
運行 「節點main.js」 這是標準的做法？
我知道forever也可以使用，但是您是否還必須殺死舊節點進程並在每次更新我的應用程序時都啓動一個新進程？在不殺死Node進程的情況下，升級是否更加順暢？
你不能沒有殺死節點過程做到這一點，但我還沒有發現真正的問題。更令人討厭的是客戶端上的瀏覽器刷新，但你可以做的事情不多。
首先，我們假設應用程序已經在運行。我們通過forever以我的回答here中的腳本開始我們的應用程序。我會告訴你我的整個升級腳本，但它包含了各種具體Edthena-的東西，所以我將概述的步驟，我們採取如下：
建立一個新的軟件包。我們在服務器本身上執行此操作，這可以避免任何missing fibers問題。該軟件包文件被寫入/home/ubuntu/apps/edthena/edthena.tar.gz。
我們cd進入/home/ubuntu/apps/edthena目錄和rm -rf bundle。這將吹走當前正在運行的進程使用的文件。由於服務器仍在內存中運行，它將繼續執行。但是，如果您的應用程序在啓動後不定期讀取private目錄中的磁盤操作，則此步驟存在問題。我們沒有，所有的靜態資產都由nginx服務，所以我覺得這樣做很安全。或者，您可以將舊的bundle目錄移至bundle.old及其should work之類的內容。
tar xzf edthena.tar.gz
cd bundle/programs/server && npm install
forever restart /home/ubuntu/apps/edthena/bundle/main.js
真的是沒有使用這種方法的任何停機時間 - 它只是重新啓動應用程序以同樣的方式它將如果服務器拋出一個異常。永遠也保持你的原始腳本的環境，所以你不需要再次指定你的環境變量。
最後，您可以查看~/.forever目錄中的日誌文件。確切的路徑可以通過forever list找到。
David的方法比這更好一次，因爲使用forever restart時的停機時間比forever stop; ...; forever start短。
下面是使用後者技術闡述的部署腳本。在~/MyApp，我運行這個bash腳本：
echo "Meteor bundling..."
meteor bundle myapp.tgz
mkdir ~/myapp.prod 2> /dev/null
cd ~/myapp.prod
forever stop myapp.js
rm -rf bundle
echo "Unpacking bundle"
tar xzf ~/MyApp/myapp.tgz
mv bundle/main.js bundle/myapp.js
# `pwd` is there because ./myapp.log would create the log in ~/.forever/myapp.log actually
PORT=3030 ROOT_URL=http://myapp.example.com MONGO_URL=mongodb://localhost:27017/myapp forever -a -l `pwd`/myapp.log start myapp.js