HOSTING / OPERATIONS

Render無料プランのスリープが困るとき、公開先をどう選ぶ?

初回アクセスが遅い原因を切り分け、有料化・静的配信・移行を比較

久しぶりに自分のアプリを開くと、画面が出るまで待たされる。Renderの無料Webサービスでは、アイドル時の停止と再起動が、その理由になる場合があります。ただし、遅い原因がいつもスリープとは限りません。

移行先を探す前に決めたいのは、誰が、どのタイミングで、どれくらい待てるかです。自分だけが試すアプリと、外部サービスからWebhookを受けるAPIでは、必要な運用が変わります。

この記事ではRenderの無料Webサービスを対象に、有料化、静的配信への変更、KamuiDashへの移行を考えます。無料枠を使い続けるための定期アクセス手順は扱いません。費用と手間を含めて、続けられる構成を選びます。

この記事の内容

Render無料プランのスリープは、どこで起きる?

Renderの公式資料では、無料Webサービスは15分間、受信トラフィックがないと停止し、次のアクセスで起動すると説明されています。起動の目安は約1分です。HTTPリクエストと既存WebSocket接続のメッセージが対象として挙げられています。

これは無料のWebサービスの仕様です。Renderの静的サイトや、すべての有料サービスへ同じ説明を当てはめることはできません。

無料Webサービスの停止と復帰 · 概念図
稼働中アクセスを処理
15分間受信なしアイドル停止
次のアクセス起動後に処理
Render公式仕様の概念図。所要時間の実測ではありません。

この約1分はRenderの資料にある目安で、今回測った応答時間ではありません。アプリの初期化や外部接続にも時間がかかるので、実際の待ち時間は自分のURLで確認します。

スリープとアプリの遅さを分ける

しばらく使わずにアクセスしたときだけ遅く、その後のリクエストは速いなら、停止からの復帰を疑えます。毎回遅い場合は、DBのクエリ、外部API、CPUやメモリ、アプリの処理を先に調べます。

初回と直後の応答、アプリの起動時刻、ログのエラーを一緒に見ると切り分けやすくなります。初回の1件だけを見て「このサービスは遅い」と判断しないことが大切です。

待ち時間が問題になる用途を整理する

用途 気になること 選び方の目安
自分だけの学習・試作 起動を待てば使えるか 待ちを許容できるなら無料枠を続ける
面接・商談で見せるデモ 相手が最初に開く瞬間 自分が事前に開く運用で足りるか、常時稼働が必要か考える
外部サービスのWebhook 送信側のタイムアウトと再送 応答期限に収まる構成と、重複を安全に扱う実装を用意する
利用者向けの小さな業務アプリ 初回の待ちを利用者に説明できるか 必要な応答と継続費用から有料構成を検討する
説明ページ・作品紹介 サーバーで処理する必要があるか 静的ファイルだけにできるなら静的配信も候補

Webhookの再送方法や時間は送信元ごとに異なります。常時稼働にしても、ネットワークの障害や再送は起こり得ます。同じイベントを二重処理しない設計は、公開先と別に必要です。

選択肢は、有料化・構成変更・移行の3つ

公開方式を選ぶ · 概念図
有料化既存構成を維持
静的配信ビルド済みの成果物を配信
移行必要な稼働条件を比較
アプリの用途と保存要件から選びます。

Renderの有料インスタンスへ変更する

すでにビルドやログ確認に慣れているなら、環境を移さずに済む利点があります。Render公式の有料化の説明では、有料のコンピュートプランへ変更すると無料インスタンス固有の制限を外せると案内しています。ワークスペースのプラン変更と、Webサービスのコンピュートプラン変更は別なので、変更対象を確認します。

アプリとDBは別に費用を確認します。アプリだけを有料化しても、DB側の保存期間や容量の制限まで同時に変わるとは限りません。

サーバーでの処理が不要なら、静的サイトにする

プロフィール、説明ページ、ビルド時に生成できる一覧などは、常駐サーバーなしで配信できる場合があります。公開する内容が変わるたびに再ビルドする方式で足りるかを考えます。

ただし、ブラウザから直接DBへ接続したり、秘密のAPIキーをJavaScriptへ埋め込んだりして、サーバー処理を省くことはできません。保存や認証が必要な部分には、別のAPIや適切なサービスが必要です。

自動スリープしないPaaSへ移行する

KamuiDashは東京リージョンのPaaSで、稼働中のアプリをアイドル時間だけで自動スリープさせない構成です。GitHub連携のHTTPアプリや、マネージドPostgreSQLを使う小さな構成の移行先として検討できます。

KAMUIDASH · SCREENSHOT
KamuiDashのアプリ作成画面。ランタイム言語とGitHubリポジトリを選択する項目。
KamuiDashのアプリ作成画面。実行する言語とGitHubリポジトリを選ぶ入口です。画面は既存の公開記事で使用しているものです。

一方、対応していない言語や実行方式、特定のアドオンが必要なアプリは、そのまま移せるとは限りません。ワーカー、定期実行、ローカルの永続ディスクなどを使っている場合は、HTTPアプリとは別に対応状況を確認します。

「自動スリープしない」は「再起動しない」や「常に無停止」を意味しません。KamuiDashもメンテナンスや障害対応で再起動する場合があり、1レプリカでは短時間の停止が起こり得ます。個人プランにはSLAが付帯しません。公式の仕様・料金に沿って判断します。

移行前に、保存先と継続費用を確認する

アプリのファイルに大切なデータが残っていないか

Renderの無料Webサービスのファイルシステムは一時的で、再デプロイ・再起動・スリープによって変更が失われる仕様です。SQLiteのDBやアップロード画像をローカルファイルへ置いている場合は、移行先に関係なく保存方法を見直します。

DBはPostgreSQLなどへ、ファイルは永続性のある保存先へ分けます。Renderの無料Postgresにも作成から30日の期限があるため、Webサービスのスリープだけに注目してDBの期限を見落とさないようにします。

基本料金だけで比較しない

KamuiDashの個人プランでは、Nanoアプリ1レプリカが30日あたり税抜$3、Nano DBが$6です。両方を30日使う基本料金は$9となります。HTTPリクエスト、外向き通信量、デプロイ時間、DB処理時間などは、無料枠・含有時間を超えると別に料金が発生します。

静的サイトだけならWebサーバーとDBが不要な場合があります。反対に、アプリを2台にするとアプリの基本料金も台数分になります。費用の内訳はKamuiDash公式の仕様・料金で確認できます。

切り替えは、別URLで確認してから行う

移行する場合は、元のサービスを残して新しいURLで動作確認します。順序は、起動、DB接続、テストデータの保存、外部連携、更新後の読み取りです。

KAMUIDASH · SCREENSHOT
KamuiDashの静的サイトのアプリ詳細。稼働状態、公開URL、GitHubブランチ、コミットごとのデプロイ履歴。
KamuiDashの静的サイトのアプリ詳細画面。公開URLとコミットの履歴を確認できます。移行先のURLを開き、画面の表示とAPIの動作を確かめる際の見方の参考です。

自分のアプリで保存・読み取りができた後に、Webhookの宛先や独自ドメインの切り替えを計画します。書き込みのあるDBを移す場合は、単にURLを変えるだけでは済みません。書き込みを止めるタイミングと、問題が起きた場合に元へ戻す手順を決めておきます。

よくある疑問

定期的にアクセスすれば、無料のまま使えますか?

アクセスの有無は停止条件に関係しますが、定期アクセスだけで無料枠の時間制限やDBの期限、再起動時の保存問題まで解決するわけではありません。用途に必要な応答と、継続利用の条件から構成を選ぶ方が判断しやすくなります。

移行せずに済ませたい場合は?

まずRender内で必要なコンピュートプランとDBプランを確認します。移行のための実装変更や確認にかかる時間も、費用の一部として考えられます。

無料枠を続ける、有料化する、構成を変える、別のPaaSへ移す。どれを選ぶかは、利用者が待てる時間と、アプリに必要な保存・運用の条件で決まります。

仕様確認日:2026年11月2日。Renderの時間・制限は公式の無料プラン資料に基づきます。今回、サービス間の応答時間の比較計測はしていません。

KamuiDashは、GitHubやAI連携からWebアプリを公開できる東京リージョンのPaaSです。