2026年7月12日

Render.comでWebアプリをデプロイする方法（GitHub連携・環境変数・独自ドメイン）

VPS・クラウド

Render は、GitHub などのリポジトリを接続するだけで、ビルドから HTTPS 付きの公開までを自動で行ってくれるクラウドの実行基盤（PaaS）です。この記事では、Node.js の小さな Web アプリを例に、Render の Web Service としてデプロイし、環境変数・ヘルスチェック・独自ドメインを設定し、つまずきやすい点を確認するところまでを説明します。Python や Ruby など他の言語でも流れは同じです。

Renderで作れるサービスの種類

Render ではアプリの性質に合わせてサービスの種類を選びます。主なものは次のとおりです。

Web Service: HTTP リクエストを受けるアプリ。公開 URL（〜.onrender.com）が割り当てられます。
Static Site: HTML・CSS・JavaScript だけのサイト。ビルドした成果物を CDN から配信します。
Background Worker: キューの処理など、外部からのリクエストを受けずに動き続けるプロセス。
Cron Job: 決まった時刻にコマンドを実行するジョブ。
Private Service: 外部公開せず、Render 内の他のサービスからだけ呼ばれるサービス。

データベースとして PostgreSQL や、Redis 互換のキーバリューストアも Render 上に作れます。無料で試せるプランもありますが、無料のインスタンスは一定時間アクセスがないと停止し、次のアクセス時に起動を待つ必要があるなどの制約があります。プランの内容と料金は変わることがあるので、本番で使う前に公式の料金ページを確認してください（2026年10月現在）。

アプリ側で守るべきこと

Render の Web Service にデプロイするアプリには、次の前提があります。ここを外すとデプロイが失敗したり、公開後にデータが消えたりします。

**環境変数 PORT のポートで、0.0.0.0 に待ち受ける**: Render はアプリに使うポートを環境変数で渡します。localhost や 127.0.0.1 にだけ待ち受けると、外からの通信が届かずデプロイがタイムアウトします。
ファイルシステムに保存したデータは残らない前提で作る: デプロイや再起動のたびにインスタンスは新しくなり、ローカルに書いたファイルは消えます。データはデータベースや外部のオブジェクトストレージに置きます。有料プランでは永続ディスクを付けられますが、付けたサービスはゼロダウンタイムのデプロイができないなどの制約があります。
秘密情報をコードに書かない: API キーやデータベースの接続文字列は、Render の環境変数に登録して読み込みます。

例として、最小の Node.js アプリは次のようになります。

// server.js
const http = require('http');

const port = process.env.PORT || 3000;

http.createServer((req, res) => {
  if (req.url === '/healthz') {
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    return res.end('ok');
  }
  res.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' });
  res.end('Hello from Render\n');
}).listen(port, '0.0.0.0', () => {
  console.log(`listening on ${port}`);
});

{
  "name": "render-demo",
  "private": true,
  "engines": { "node": ">=20" },
  "scripts": { "start": "node server.js" }
}

/healthz は、後で設定するヘルスチェック用のパスです。Node.js のバージョンは engines や .node-version ファイルで指定できます。指定しないと Render の既定のバージョンが使われ、手元と挙動が違う原因になるため、明示しておくことをおすすめします。

ダッシュボードからデプロイする

コードを GitHub（GitLab、Bitbucket も可）のリポジトリに push したら、Render のダッシュボードで新しい Web Service を作成します。画面の表記は更新で変わることがありますが、設定する内容は次のとおりです。

リポジトリとブランチ: 接続するリポジトリと、デプロイ対象のブランチ（例: main）。Render にリポジトリへのアクセス権を与える必要があります。権限は対象のリポジトリだけに絞るのが安全です。
ランタイム: Node、Python などの言語、または Docker。
ビルドコマンド: 依存パッケージのインストールやビルド。例: npm ci。
スタートコマンド: アプリの起動。例: npm start。
リージョン: 利用者に近い場所を選びます。日本向けならアジアのリージョンが候補になりますが、提供されるリージョンは公式で確認してください。データベースを使うなら、アプリと同じリージョンにそろえます。
インスタンスタイプ: 無料または有料のプラン。

作成するとビルドが始まり、ログが画面に流れます。「Live」のような状態になれば、割り当てられた 〜.onrender.com の URL でアクセスできます。以後は、対象ブランチに push するたびに自動でデプロイされます（自動デプロイは設定で止めることもできます）。

環境変数とヘルスチェックを設定する

サービスの設定画面で環境変数を登録します。値はダッシュボード上で管理され、コードやリポジトリに残りません。複数のサービスで同じ値を使う場合は、環境グループにまとめておくと管理しやすくなります。設定ファイルを丸ごと渡したい場合は、シークレットファイルとして登録する方法もあります。

アプリ側では次のように読み込みます。

const apiKey = process.env.EXTERNAL_API_KEY;
if (!apiKey) {
  console.error('EXTERNAL_API_KEY is not set');
  process.exit(1);
}

必要な値がないときに起動を止めておくと、設定漏れのままデプロイされて、本番で初めてエラーに気づくという事態を防げます。値そのものはログに出さないでください。

ヘルスチェックのパスに /healthz を設定すると、Render は新しいバージョンがこのパスに正常に応答するのを待ってから通信を切り替えます。起動に失敗したバージョンが公開されにくくなるため、設定しておく価値があります。ヘルスチェック用のパスでは、重い処理や認証を挟まず、すぐに応答を返すようにします。

render.yamlで設定をコード化する

ダッシュボードで設定した内容は、リポジトリに render.yaml を置く「Blueprint」の形でも管理できます。設定がコードとして残るので、別の環境を作り直すときや、変更の履歴を追うときに便利です。

services:
  - type: web
    name: render-demo
    runtime: node
    buildCommand: npm ci
    startCommand: npm start
    healthCheckPath: /healthz
    envVars:
      - key: NODE_ENV
        value: production
      - key: EXTERNAL_API_KEY
        sync: false
      - key: DATABASE_URL
        fromDatabase:
          name: render-demo-db
          property: connectionString

databases:
  - name: render-demo-db

sync: false を指定した変数は、値をファイルに書かず、ダッシュボードで入力する扱いになります。秘密情報はこの形にして、render.yaml に値を直接書かないようにします。指定できるキーは仕様の更新で増えたり名前が変わったりすることがあるため、公式の Blueprint リファレンスで確認してください。

独自ドメインとHTTPS

サービスの設定から独自ドメインを追加すると、DNS に登録すべきレコードが表示されます。www.example.com のようなサブドメインなら、〜.onrender.com を向く CNAME レコードを登録するのが基本です。example.com のようなルートドメインでは CNAME を使えないため、Render の案内に従って A レコードを登録するか、DNS サービスの ALIAS や ANAME、CNAME フラット化の機能を使います。

DNS の反映が終わると、Render が TLS 証明書を自動で発行し、HTTPS で配信されるようになります。反映には時間がかかることがあるので、すぐに証明書が出なくても、まず dig などで DNS が正しく引けているかを確認します。

うまくいかないときの確認ポイント

デプロイで失敗したときは、ビルドログとサービスのログを上から順に読みます。よくある原因は次のとおりです。

ポートの待ち受け: 「ポートが開いていない」旨のメッセージでタイムアウトする場合は、PORT と 0.0.0.0 の設定を確認します。
ビルドコマンドの誤り: ロックファイルとパッケージマネージャーが合っていない（yarn.lock があるのに npm ci を使っている）、ビルド成果物の出力先が違う、など。
バージョンの違い: 手元と Render で言語のバージョンが違い、依存パッケージのインストールに失敗する。バージョンを明示します。
環境変数の未設定: ローカルの .env だけに書いてあり、Render に登録していない。
データが消える: ローカルのファイルに保存している。データベースか外部ストレージに移します。

手動で再デプロイしたい場合は、ダッシュボードから実行できるほか、デプロイフック（呼び出すとデプロイが始まる URL）を CI から呼ぶ方法もあります。デプロイフックの URL は第三者に知られるとデプロイを起こされてしまうため、秘密情報として扱います。

まとめ

Render はリポジトリを接続するだけでビルドと HTTPS 公開を自動化できる PaaS。用途に合わせて Web Service や Static Site などを選ぶ
アプリは PORT のポートで 0.0.0.0 に待ち受け、ローカルのファイルにデータを残さない設計にする
秘密情報は環境変数で渡し、render.yaml には sync: false で値を書かない
ヘルスチェックを設定して、起動に失敗したバージョンが公開されにくくする
独自ドメインは CNAME を基本に、ルートドメインは DNS サービスの機能か案内に沿って設定する
失敗したらログを読み、ポート・ビルドコマンド・バージョン・環境変数の順に確認する