meteor-deployment

Meteor のデプロイ

meteor build は、対応する Node.js バージョンが動作するあらゆる環境で実行できる、自己完結型の Node バンドルを生成します。Galaxy はファーストパーティのホストです。Docker／Kubernetes／Node ホストへの SSH も利用できます。

Android／iOS の成果物とネイティブ HCP 互換性には、meteor-native を使用してください。互換性ハッシュだけでなく、実際のネイティブ設定も確認してください。権限などのネイティブ設定を変更すると、ハッシュが変わらなくても新しいバイナリが必要になることがあります。

バンドルされた Meteor の Node バージョンに合わせてください。

Meteor	Node のメジャーバージョン
3.0	20
3.1 から 3.4	22
3.5.x および 3.6-beta.0	24
3.6-beta.1 から beta.3	26 (26.8.2)
3.6-rc.0	26 (26.10.0)

対象アプリで meteor node -v と meteor npm -v を実行して確認してください。 Meteor 3.6-beta.1 から beta.3 には npm 11.19.0 がバンドルされています。デプロイするランタイムとネイティブ依存関係のビルド環境を、そのリリースに合わせてください。これらのベータ版をデプロイする前に、Node 26 と本番環境のアーキテクチャ向けにネイティブ npm モジュールを再ビルドしてテストしてください。 Meteor 3.6-rc.0 には npm 11.19.1 がバンドルされています。展開したバンドルには、正確な Node バージョンが bundle/.node_version.txt に記録されています。ソースツールを利用できない場合は、このメタデータを使用してください。ホストインストーラーの前提条件では、バンドルされたランタイムは選択されません。

選択の流れ

1. Galaxy を使用しますか？Git Push to Deploy または Meteor CLI を選択してください。Galaxy の設定ソース、ビルドフック、ヘルスチェック、ドメインの設定については、references/galaxy.md を参照してください。
2. Docker／Kubernetes を使用しますか？meteor build --directory ./build --server-only は、プラットフォーム固有のモバイル成果物をスキップします。クロスビルドには --architecture os.linux.x86_64 を使用してください。
3. Node ホストに SSH 接続しますか？同じ meteor build を実行し、バンドルを scp で転送して、bundle/programs/server の下に本番用依存関係をインストールし、node main.js を実行してください。
4. Vercel／Netlify／サーバーレスを使用しますか？サポートされていません。Meteor には WebSocket を使用する、長時間稼働する Node プロセスが必要です。

リンクされたワークスペースパッケージを使用する場合は、バンドルをチェックアウトの外に移動し、ソースにアクセスできない状態で、使用する .bin コマンドと隣接するリソースの読み込みをテストしてください。 3.6-beta.3 ではコピーされたコマンドリンクが修正されています。それより前のツールに依存する前に、動作を確認してください。マネージャーとロックファイルを保持し、生成されたリンクにはパッチを適用しないでください。 beta.3 のローカル MongoDB 8 と外部データベースの違いについては、データベースの境界を参照してください。

必須の環境変数

変数	用途
ROOT_URL	外部 URL（絶対 URL。例：https://app.example.com）。
MONGO_URL	mongodb://... 接続文字列。
MONGO_OPLOG_URL	Mongo レプリカの oplog URL（任意）。
PORT	待ち受けポート。デフォルトは 3000 です。
BIND_IP	ネットワークインターフェース。デフォルトは 0.0.0.0 です。
METEOR_SETTINGS	JSON。Meteor.settings に値を設定します。
MAIL_URL	Email.send とアカウントメール用の SMTP。

ROOT_URL はブラウザーから見える外部 URL であり、クラスター内部のサービス URL ではありません。OAuth リダイレクト、Meteor.absoluteUrl、CSP はすべてこれに依存します。

Meteor 3.0 から 3.4 では、oplog を利用したリアクティビティのために MONGO_OPLOG_URL を設定してください。設定しない場合、Meteor はポーリングします。Meteor 3.5 以降では、この変数なしでコアの変更ストリームを使用でき、必要に応じて oplog またはポーリングにフォールバックします。Atlas をホストに利用しても、古い Meteor アプリにコアの変更ストリームのサポートが追加されるわけではありません。

settings.json

{
  "public": { "appName": "My App", "stripePublishableKey": "pk_live_..." },
  "stripeSecretKey": "sk_live_...",
  "oauthSecretKey": "16-byte-base64==",
  "mailgun": { "apiKey": "..." }
}

トップレベルのキーはサーバーのみで使用されます。public サブツリーはクライアントに配布されます。

読み込み：

# dev
meteor run --settings settings.json

# production
METEOR_SETTINGS=$(cat settings.json) node bundle/main.js

Galaxy

デプロイ方法を1つ選択します。

方法	適した用途	トリガー
Push to Deploy	Galaxy に、接続された GitHub または Bitbucket のブランチをビルドさせる場合。	選択したブランチへのプッシュごと。
Meteor CLI	各アップロードを担当者または CI パイプラインが管理する場合。	meteor deploy <app-name>。

meteor whoami を確認します。特定のユーザーまたは組織を選択するには、--owner my-account を追加します。新しい Free アプリの場合は、カスタムドメインではなく、シンプルなアプリ名を指定します。

meteor login
meteor deploy myapp --free --settings settings.json

DEPLOY_HOSTNAME=eu-west-1.galaxy-deploy.meteor.com \
  meteor deploy myapp --plan essentials --settings settings.json

Galaxy は、Free では myapp.sandbox.galaxycloud.app ホスト名を、有料プランではリージョン別の myapp.<region>.galaxycloud.app ホスト名を割り当てます。カスタムドメインはダッシュボードで追加します。アクティブなプライマリドメインが ROOT_URL を制御します。

既存のアプリを再デプロイする前に、現在のホスト名、リージョン、所有者を確認します。--plan と --container-size は作成時の設定を指定するオプションです。既存のアプリのプランやサイズはダッシュボードで変更します。テスト用に無料の共有 MongoDB をプロビジョニングするには、オプションで --mongo を追加します。Mongo TLS のガイダンスに従ってください。バックアップはなく、本番環境での使用は推奨されません。

Galaxy は PORT、ROOT_URL、METEOR_SETTINGS を注入します。MONGO_URL、MAIL_URL、その他のサーバー環境変数は、Galaxy の設定 JSON 内の galaxy.meteor.com.env に記述してください。Repository Mode で CLI の --settings ファイルが上書きされると想定しないでください。

設定モード、Push to Deploy のビルド、ダウンタイムなしのロールアウトとロールバック、プロキシ、Mongo TLS、メモリ、カスタムベースイメージについては、references/galaxy.md を参照してください。

Docker

動作するマルチステージ Dockerfile については、references/docker.md を参照してください。あるステージでバンドルをビルドし、別の小さなステージでサーバーの依存関係をインストールして実行します。--server-only はプラットフォーム固有のモバイルアプリケーションのビルドを省略しますが、ブラウザクライアントを省略したり、API 専用のバンドルを作成したりするものではありません。Meteor は、ホットコードプッシュに使用する web.cordova クライアントターゲットを引き続きビルドします。

ホットコードプッシュ

autoupdate は本番環境のホットコードプッシュを提供します。DDP 経由で新しいクライアントバージョンを検出し、可能な場合は再読み込みせずにスタイルシートのみの変更を適用します。それ以外の場合は、ブラウザーを完全に再読み込みします。HCP を無効にするには、.meteor/packages から autoupdate を削除します。

hot-module-replacement はこれとは異なります。開発中に受け入れ可能な JavaScript モジュールを置き換え、モジュールが更新を受け入れられない場合は HCP にフォールバックします。HMR は本番環境およびサポートされていない Web アーキテクチャでは無効です。現在の公開 API に Meteor.disableClientResourceFetch スイッチはありません。

アンチパターン

• 本番環境のシークレットを含む settings.json をコミットする。CI のシークレットストアまたは環境変数を使用し、起動時に METEOR_SETTINGS=$(cat ...) で読み込みます。
• ROOT_URL に内部 Kubernetes サービスの URL を設定する。外部 HTTPS URL を使用しないと、OAuth リダイレクトや Meteor.absoluteUrl が機能しません。
• バンドルされた Meteor の Node と一致しない Node バージョンを実行する。必ず meteor node -v で確認します。
• 誤ったアーキテクチャでビルドする。M シリーズ Mac の開発者が x86_64 Linux 向けにビルドする場合は、--architecture os.linux.x86_64 を指定する必要があります。
• 認証情報を含む Galaxy の設定をコミットしたり、Repository Mode が CLI の --settings ファイルを読み込むと想定したりする。シークレットは Galaxy Mode またはシークレットストアで管理します。
• Galaxy のポート、ロードバランサーの IP、リージョン別 DNS のターゲットをハードコードする。$PORT を読み取り、アプリのダッシュボードから現在のネットワーク値をコピーします。
• ビルド済みバンドルと一緒にソースツリーを Docker イメージに含める。マルチステージを使用し、実行時イメージには bundle/ のみを含めます。

関連項目

• references/settings-and-env.md
• references/galaxy.md
• references/docker.md
• references/eval-cases.md