Herokuとは？デプロイ手順（Git・GitHub連携・Docker）と料金・2026年の提供方針

Herokuは、コードを送るだけでビルドから公開までを引き受けるPaaSです。デプロイの入口は、Gitで直接pushする方法、GitHubのブランチと連携して自動で出す方法、Dockerイメージを持ち込む方法の3つに分かれます。この記事では3方式それぞれの手順をコマンド付きで示し、デプロイが失敗したときのエラーコードの読み方、料金と制限値、2026年2月に発表された提供方針を踏まえた採用判断までをまとめます。手順と数値はHeroku Dev Centerの各記事で2026年10月時点の記述を確かめたものです。

まとめ：Herokuのデプロイ方式・料金・2026年の位置づけ

• HerokuはSalesforce傘下のPaaS。アプリ実行のdyno、Heroku Postgresなどのデータサービス、Salesforce連携のConnect・AppLink、閉域環境のPrivate Spaces・Shieldで構成される
• デプロイは「Git push」「GitHub連携の自動デプロイ」「Dockerコンテナ（heroku.yml／Container Registry）」の3方式。最初の1本はGit push、チーム運用はGitHub連携とPipelines、既存のDockerfileがあるならコンテナ方式を選ぶ
• デプロイ失敗の大半は、待ち受けポートを環境変数PORTから読んでいない（R10）、起動コマンドの誤り（H10）、web dynoが0台（H14）のどれか。まずheroku logs --tailでコードを確認する
• 料金はdyno単位で、Eco以外は秒単位の従量課金。個人向けEcoは月5ドル定額で1000時間、常時稼働のBasicは月7ドル、本番向けStandard-1Xは月25ドル。無料プランは2022年11月28日に終了
• 2026年2月6日に安定運用重視の方針へ移行し、その目的に沿う機能追加は継続。通常の実行環境（Common Runtime）のリージョンは米国と欧州だけで、東京はPrivate Spaces限定

Herokuとは：Salesforce傘下のPaaSと名前の意味

Herokuは、アプリを動かすOS・ミドルウェア・スケール機構をまとめて提供するPaaS（Platform as a Service）です。2007年に創業し、Salesforceが2010年12月に約2億1,200万ドルでの買収合意を発表、2011年1月3日に取得を完了しました。共同創業者のAdam Wigginsは、社名を「heroic（英雄的な）」と「haiku（俳句）」を組み合わせた造語と説明しています。haikuには、創業時に対象としたRubyが日本生まれの簡潔な言語であることを重ねた、という説明です。PaaSという提供形態そのものの位置づけはPaaSとは？IaaS・SaaSとの違いと開発を速める仕組みで整理しています。

dyno・buildpack・アドオンによるアプリ実行と構築の仕組み

アプリはdynoと呼ばれるコンテナで動きます。git pushを受けるとbuildpackが言語を判定し、依存パッケージを入れた実行イメージ（slug）を作って、dynoへ配ります。データベースやログ監視はアドオンとして後から付け足す方式で、サーバーを自分で組む作業がありません。

公式に対応する言語はNode.js、Python、Ruby、Java、PHP、Go、Scala、Clojure、.NETの9つです。新しい実行基盤のFir世代はKubernetesとCloud Native Buildpacksの上に作られ、2025年4月14日にPrivate Spaces向けとして一般提供が始まりました。Eco・Basicなど通常のdynoは従来のCedar世代で動きます。Buildpackの仕組み自体はCloud Native Buildpacksとは？Dockerfile不要のイメージ生成とリベース運用が詳しいです。

herokuapp.comの既定ドメインと本番向け独自ドメインの使い分け

ホスト名が.herokuapp.comで終わるURLは、Herokuがアプリを作ると自動で割り当てる既定ドメインです。2023年6月14日以降に作られたアプリはアプリ名-識別子.herokuapp.comの形になります（例：example-app-1234567890ab.herokuapp.com）。Heroku社が運営するサイトという意味ではなく、中身は各利用者のアプリです。公式は本番アプリに独自ドメインの追加を強く推奨しています。

Herokuの製品ラインナップ：アプリ実行・データ管理・企業向け機能

「Heroku」は1つのサービス名ではなく、実行基盤・データサービス・AI・企業向け機能を束ねた製品群の名前です。公式サイトの製品一覧を用途別にまとめると次のとおりです。

表の「マネージド推論・エージェント」の正式名称はManaged Inference and Agentsです。小規模なWebアプリの構成例は、dynoとHeroku Postgresです。ファイル保存やメール送信、監視などは、要件に応じて外部サービスを組み合わせます。Salesforce連携と企業向け製品は、Salesforceを導入済みの企業が顧客向けアプリを作る場面で選ばれる製品です。

Salesforce連携：Heroku ConnectとAppLinkの違い

Salesforceの販売パートナー各社がHerokuを扱っている理由は、CRMのデータと自社アプリをつなぐ専用製品があるためです。2つは役割が違います。

Heroku Connectは、SalesforceのオブジェクトとHeroku Postgresのテーブルを同期するアドオンです。同期はデータだけで、オブジェクトごとに読み取り専用か読み書きかを選べます。既定のdemoプランは同期行数が合計10,000行、ポーリング間隔が最短10分に制限され、本番で使う有償プランは営業経由の契約です。

Heroku AppLinkは、Heroku上のアプリをAPIとして公開し、Salesforce側のFlow・Apex・Data Cloud・Agentforceから呼び出せるようにするアドオンです。呼び出し時にSalesforceのユーザー権限が適用され、アドオン自体の公開プランは無料です。AppLinkのサービス自体は米国virginiaリージョンで動いているため、アプリを欧州に置くと呼び出しの遅延が増えます。API方式の選び方やコール上限の設計はSalesforceのシステム連携とは？API方式の選定とコール上限の設計で扱っています。

公式サイトの企業導入事例：患者データの処理とSalesforce連携

公式の事例ページには、ダボス会議の参加者向けアプリを動かす世界経済フォーラム、患者ケアを扱う医療ネットワークのAspen Physician Network、音声・メッセージング基盤のFastcall、AI製品のPixieBrix、AppLinkでSalesforceとEC基盤をつないだTAO Driveなどが掲載されています。Aspen Physician Networkの事例では、Heroku ShieldとPostgresで患者データを処理し、Heroku Connectを通じてSalesforce Health Cloudへ連携しています。

Herokuの料金プラン：dynoとアドオンの費用・稼働条件の比較

費用はdyno（実行環境）とアドオン（データベースなど）の合計で決まります。Eco以外のdynoは起動時間に応じて秒単位で按分され、前月分が請求されます。アクセスが無くても台数が1以上なら課金の対象です。

dynoの月額料金とメモリ：検証用・常時稼働・本番向けの条件比較

公式の料金ページに載っているCommon Runtime向けdynoの月額上限は次のとおりです（2026年9月時点）。

Ecoは使用量にかかわらず月5ドルの定額で、全Eco dynoで月1000時間を分け合います。使えるのはHeroku TeamsやEnterprise Teamsに属さない個人アプリだけです。Basicは1台あたり約0.01ドル/時で、2時間だけ動かせば2時間分しか請求されません。検証用のアプリは使わない時間にheroku ps:scale web=0でweb dynoを0台にすると、その従量課金は止まります。ただし、Ecoの月額料金やアドオン、別のプロセスの料金は止まりません。

データベースとKey-Value Storeの料金・容量と最小構成の費用

Heroku Postgresの最安はEssential-0で月5ドル、ディスク1GB・同時接続20です。10GBが必要ならEssential-1の月9ドルになります。Key-Value Storeの最安はMiniで月3ドル、メモリ25MBです。Postgresを使うWebアプリ1本を常時動かす最小構成は、Basic（7ドル）とEssential-0（5ドル）で月12ドルが目安です。

無料プランの変遷：「18時間」の起動制限から2022年の提供終了まで

「heroku 無料 18時間」で検索される条件は、2015年5月7日に導入された旧free dynoのルールです。当時のfree dynoは24時間のうち18時間までしか起動できず、残り6時間は強制的にスリープしました。2016年6月には、個人アカウントに月550時間（クレジットカード認証で450時間を追加し計1000時間）を配る枠制に変わりました。

この無料枠も、2022年8月25日の告知どおり2022年11月28日に終了しています。あわせて同年10月26日からは、1年以上使われていないアカウントと関連ストレージの削除が始まりました。「無料で試せる」「18時間ルールに注意」と書かれた解説は2022年以前の情報です。

Herokuにデプロイする3つの方式：Git・GitHub連携・Dockerの違い

Herokuへのデプロイは、コードをどこから受け取ってどうビルドするかで3つに分かれます。どれを選んでもdynoの料金は同じで、違うのはビルドの担い手と運用の手間です。

Git pushはherokuという名前のGitリモートへ送るだけで、Herokuが言語を判定してビルドします。Deploying with Gitによれば、デプロイされるのはリモートのmainかmasterブランチだけで、それ以外のブランチへpushしてもビルドは走りません。GitHub連携は、ダッシュボードの「Deploy」タブでリポジトリとブランチを選び、そのブランチへのpushを合図に自動でビルドします。コンテナ方式は、buildpackの代わりに自分のDockerfileでイメージを作る方式で、言語ランタイムやOSパッケージを細かく固定したいときに選びます。

迷ったら、最初の動作確認はGit push、チームで回し始めたらGitHub連携とPipelines、という順で十分です。テストからデプロイまでの一連の流れをどう組むかはCI/CDとは：仕組み・パイプライン構成と導入判断の基準で全体像を整理しています。

Herokuの使い方：Node.js・PythonのAPIをGitでデプロイする手順

ここではNode.jsで最小のAPIを作り、Eco dynoへ公開するまでを示します。事前にHerokuアカウントを作成し、支払い方法を登録したうえで、アカウントのBilling画面からEcoプランを購読します。Gitの事前導入も必要です。Gitの基本操作はGitコマンド一覧｜用途別早見表で確認できます。

Heroku CLIの導入とログイン：OS別の導入方法と認証手順

macOSはHomebrewでbrew install heroku/brew/heroku、Windowsは公式サイトの64bitインストーラーを使います。Linuxはcurl https://cli-assets.heroku.com/install.sh | shのスタンドアロン版がHeroku CLIの公式ページで案内されており、Snap版は2026年時点でサポート対象外です。導入後にheroku --versionで確認し、heroku loginを実行するとブラウザで認証が済みます。

Node.js APIの作成とGitによる公開手順：必要なファイルと起動確認

必要なファイルは3つです。Herokuはdynoごとに待ち受けポートを環境変数PORTで渡すため、ポート番号を固定で書くと起動に失敗します。

index.js

const http = require("node:http");

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

const server = http.createServer((req, res) => {
  if (req.url === "/api/health") {
    res.writeHead(200, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ status: "ok", time: new Date().toISOString() }));
    return;
  }
  res.writeHead(404, { "Content-Type": "application/json" });
  res.end(JSON.stringify({ error: "not found" }));
});

server.listen(port, () => console.log(`listening on ${port}`));

package.json

{
  "name": "hello-api",
  "version": "1.0.0",
  "engines": { "node": "24.x" },
  "scripts": { "start": "node index.js" }
}

Procfile（拡張子なし）

web: npm start

enginesの24.xは、Herokuが2026年6月時点でActive LTSとして案内している系列です。3つのファイルを同じ作業ディレクトリに保存し、そのディレクトリで次の順に実行します。

git init
git add .
git commit -m "first deploy"
git branch -M main
heroku create
git push heroku main
heroku ps:scale web=1
curl https://<アプリ名-識別子>.herokuapp.com/api/health

heroku createはアプリを作り、herokuという名前のGitリモートを追加します。git pushでビルドが走り、完了するとURLが表示されます。Ecoプランを購読していれば、heroku ps:scale web=1で起動するdynoの既定値はEcoです。最後のcurlで{"status":"ok",...}が返れば公開できています。

既に作ってあるアプリへ別の作業ディレクトリからデプロイするときや、main以外のブランチを試しに出したいときは、次のように書きます。testbranch:mainは「手元のtestbranchを、リモートのmainとして送る」という意味です。

heroku git:remote -a example-app
git push heroku testbranch:main

PythonのFlaskアプリをgunicornでデプロイする場合

Pythonは、依存パッケージをrequirements.txt、Pythonの版を.python-versionで宣言します。Pythonのサポート状況では、2026年2月時点で3.11〜3.14系がサポート対象、3.10系は廃止予定で、版を指定しない新規アプリには3.14系の最新パッチが使われます。公式の推奨も、既定に任せず版を明記する方法です。

app.py

from flask import Flask, jsonify

app = Flask(__name__)


@app.get("/api/health")
def health():
    return jsonify(status="ok")

requirements.txt

flask>=3.1,<4
gunicorn>=25,<26

.python-version

3.14

Procfile

web: gunicorn app:app --bind 0.0.0.0:$PORT

この4ファイルを置いたディレクトリで、Node.jsと同じくheroku createとgit push heroku mainを実行します。開発用サーバーのflask runをProcfileに書くと、本番向けではない単一プロセスで動いてしまうため、gunicornのようなWSGIサーバーを経由させます。Procfileの書式やプロセスタイプの考え方を確認するための資料は、The Procfileです。

公開後の運用コマンドと設定：ログ確認・環境変数・台数変更・復旧操作

公開後に使う頻度が高いのは次のコマンドです。

• heroku logs --tail：ログをリアルタイムに表示。起動失敗の原因はまずここで見る
• heroku config:set KEY=VALUE：環境変数（Config Vars）を設定。APIキーやDB接続文字列はコードに書かない
• heroku ps:scale web=1：web dynoの台数を変更。0で停止
• heroku releasesとheroku releases:rollback：リリース履歴を見て、直前のリリースに戻す
• heroku addons:create heroku-postgresql:essential-0：Postgresを追加し、接続先をDATABASE_URLに自動設定

コンテナで持ち込みたい場合はDockerfileとは｜書き方・主要命令で作ったイメージもデプロイできます（後述）。Heroku自体の操作をプログラムから行うPlatform APIは、1時間あたり4,500リクエストが上限です。

GitHub連携とPipelinesでHerokuへの自動デプロイを組む手順

手元からのGit pushは、誰がいつ何を出したかが残りにくく、チームでの運用には向きません。GitHubのブランチを起点にデプロイし、本番へは検証済みのビルドだけを昇格させる形に組み替えます。

GitHub連携の自動デプロイと「Wait for CI to pass」

GitHub Integrationは、ダッシュボードの「Deploy」タブでGitHubアカウントを認証し、リポジトリを選んで有効にします。連携の設定にはリポジトリの管理者権限が必要です。続いて「Automatic deploys」で対象ブランチを選ぶと、そのブランチへのpushごとにビルドとデプロイが走ります。「Wait for CI to pass before deploy」にチェックを入れると、コミットのステータスがすべてsuccessになったときだけデプロイされ、pendingのままならスキップされます。

テストはGitHub側で先に回すのが素直な構成です。次のワークフローは、mainへのpushとプルリクエストでテストを実行し、その結果がコミットのステータスとしてHerokuの判定に使われます。ワークフローの書き方はGitHub Actionsとは？できること・使い方で詳しく扱っています。

.github/workflows/test.yml

name: test
on:
  push:
    branches: [main]
  pull_request:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm ci
      - run: npm test

注意点が2つあります。GitHub連携はGitHubが生成するアーカイブからビルドするため、Gitのサブモジュールの中身は含まれません。もう1つは、RailsやDjangoのマイグレーションは自動では実行されない点です。後者は次のRelease Phaseで解決します。

Release Phaseでマイグレーションをデプロイ前に流す

Release Phaseは、Procfileにreleaseプロセスを書くと、新しいリリースが出る前に1回だけ実行される仕組みです。ビルドの成功時だけでなく、Config Varsの変更、Pipelinesでの昇格、ロールバックのときにも走ります。

release: python manage.py migrate
web: gunicorn myproject.wsgi --bind 0.0.0.0:$PORT

releaseコマンドが0以外の終了コードで終わると、新しいリリースは出ず、動いているリリースはそのまま残ります。失敗したら原因を直してheroku releases:retryで再実行してください。タイムアウトは1時間で延長できないため、大きなテーブルの書き換えのように長くかかる処理はreleaseに載せず、別途ワンオフdynoで流します。

Pipelinesによるstagingから本番への検証済みビルドの昇格

Pipelinesは、同じコードベースのアプリをreview・development・staging・productionのステージに並べる機能です。stagingで確かめたビルド成果物（slug）を、作り直さずにそのままproductionへコピーするのが特徴で、検証したものと本番で動くものが一致します。パイプライン自体は無料で、課金されるのは各アプリのdynoとアドオンです。

heroku pipelines:create example-pipeline -a example-app -s production
heroku pipelines:add example-pipeline -a example-staging-app -s staging
heroku pipelines:promote -r staging

stagingのアプリにGitHub連携の自動デプロイを設定し、本番へはpipelines:promoteで昇格させる、という分担が基本形です。プルリクエストごとに一時的な検証環境を立てるReview Appsもパイプライン上で設定でき、そのdynoとアドオンも通常と同じ料金がかかります。設定値をビルド時に成果物へ焼き込む構成では、昇格先で値が変わらないため、Git経由のデプロイに戻します。

Prebootによるデプロイ切り替え時の停止回避と新旧同時稼働の注意点

通常のデプロイは、古いdynoを止めてから新しいdynoを起動するため、新しいdynoの起動が終わるまで応答が途切れることがあります。Prebootを有効にすると、新しいdynoを先に起動し、約3分後にトラフィックを切り替えてから古いdynoを止めます。

heroku features:enable preboot -a example-app

対象はStandardとPerformanceのdynoで、EcoとBasicでは使えません。切り替えまでの最大3分ほどは新旧2つの版が同時に動くため、データベースの接続数が倍になる点と、旧版と互換性の無いスキーマ変更を同じリリースで出さない点に気をつけます。新旧の環境を並べて切り替える考え方はブルーグリーンデプロイメントとは｜仕組み・他方式との違いと同じ系統です。

ブランチ運用・テスト・昇格・無停止切り替えまでを一度に組むのは、既存のリポジトリ構成や本番の制約によって設計が変わります。CI/CDの設計から導入までを任せたい場合は、一創のDevOps・CI/CD導入支援で相談を受け付けています。

DockerイメージのHerokuへのデプロイ手順：ビルド場所による方式の違い

Dockerfileが既にある場合は、buildpackを使わずにコンテナとしてデプロイできます。方法は、Gitのpushを合図にHeroku側でビルドするheroku.ymlと、手元でビルドしたイメージを送り込むContainer Registryの2つです。

heroku.ymlでgit pushからDockerビルドする

heroku.ymlによるビルドでは、リポジトリの直下に次のファイルを置き、アプリのスタックをcontainerに切り替えます。

heroku.yml

build:
  docker:
    web: Dockerfile
release:
  image: web
  command:
    - npm run migrate
run:
  web: npm start

heroku stack:set container -a example-app
git add heroku.yml
git commit -m "use heroku.yml"
git push heroku main

buildでビルドするDockerfile、releaseでRelease Phaseに相当するコマンド、runでプロセスごとの起動コマンドを指定します。Dockerのレイヤーキャッシュは効かないため、毎回フルビルドになり、ビルド時間はbuildpackより長くなりがちです。また、Private Spacesではrunの指定が無視されるので、Dockerfile側のCMDに起動コマンドを書いておきます。

Container Registryで手元のイメージを送り込む

Container Registry & Runtimeは、手元のDockerでビルドしたイメージをHerokuのレジストリへpushしてリリースする方式です。

heroku container:login
heroku container:push web -a example-app
heroku container:release web -a example-app

イメージ側には次の条件があります。待ち受けポートは$PORTから読み、EXPOSEは無視されます。CMDは必須で、プロセスを動かすユーザーはroot以外です。対応するアーキテクチャはlinux/amd64だけなので、Apple Siliconなどのarm64機でビルドするときはdocker build --platform linux/amd64を付けます。この方式の解説は2026年7月時点でCedar世代のアプリが対象で、Fir世代には当てはまりません。

Herokuのデプロイが失敗したときの切り分け：H10・R10・H14

ビルドは通ったのにアプリが開かない、という相談の多くはエラーコードで原因が絞れます。heroku logs --tailに出るcode=の値を、Heroku Error Codes（2026年9月更新版）と突き合わせます。

R10とH10は、ポートを3000や8000で固定している、Procfileのweb:の綴りや起動コマンドが手元と違う、起動時にデータベースへ接続しに行って待たされる、の3つでほとんど説明が付きます。H14は、検証後にps:scale web=0で止めたまま忘れているケースが典型です。ビルド自体が失敗する場合は、package.jsonやrequirements.txtが直下に無く言語判定に失敗しているか、ロックファイルと宣言の不一致が典型です。直前の正常な版へ戻すならheroku releases:rollbackが早く、原因はその後で落ち着いて調べられます。

Herokuの容量と制限値：設計前に確認すべき保存・応答時間の上限

Herokuで作り直しが発生しやすいのは、ファイル保存とリクエスト時間の制限を知らずに設計したケースです。Limitsに載っている主な上限は次のとおりです。

• ファイルシステムは揮発性：dyno内に書いたファイルは再起動で消え、他のdynoからも見えない。画像アップロードはAmazon S3などの外部ストレージに保存する
• 初期応答のタイムアウトは30秒：最初の応答を30秒以内に返す必要がある。ストリーミングでは、その後の送受信ごとに55秒の無通信タイマーが更新される。重い処理はworker dynoに回して非同期にする
• 起動は60秒以内：webプロセスが60秒以内にPORTへバインドしないと起動失敗になる
• slugは圧縮後1000MB：サポートへの申請で2000MBまで引き上げ可能。ビルド（slugコンパイル）は25分で打ち切り
• Gitリポジトリは1GBまで：チェックアウトしたHEADとサブモジュールの非圧縮サイズの合計。600MBを超えるとpushが遅くなりタイムアウトしやすい
• Git操作は1時間75回まで：ユーザーとアプリの組ごとに、直近1時間のローリングで数える。CIから短い間隔でpushし続ける構成では引っかかる
• アプリ数は1アカウント100個：Heroku Teamsも100個、Enterprise Teamsは200個

slugの上限を「500MB」とする解説がありますが、Herokuは2026年3月に既定の上限を500MBから1000MBへ引き上げています。

Herokuの権限管理とセキュリティ：アプリ共有時の操作範囲と閉域環境

Herokuでアプリを共有するときは、個人アプリのcollaboratorと、Heroku Teamsのアプリ単位の権限を区別します。

アプリ単位の権限：Fine-Grained Access Control

2026年8月21日に、アプリごとに細かく権限を割り当てるFine-Grained Access Controlが全利用者に提供されました。従来はadmin・memberなどのロールごとに権限の束が固定されていましたが、現在はview（閲覧）、deploy（デプロイ）、operate（運用）、manage（管理）をアプリごとに任意の組み合わせで付与できます。チームの全メンバーはチーム内アプリのviewを持ち、ほかの権限は明示的に付与したものだけが有効です。利用者の追加・削除や権限の変更ができるのは、manageを持つ人かチーム管理者に限られます。

注意したいのは個人アカウントのアプリです。heroku access:add メールアドレスでcollaboratorを追加して共有できますが、collaboratorは有償アドオンの追加・削除、アプリの削除・移管・改名、請求書の閲覧を除き、スケーリングを含めて所有者とほぼ同じ操作ができます。外注先にはdeployまで、サポート担当にはviewだけ、と分けたいなら、アプリをHeroku Teamsへ移してからアプリ単位の権限を設定します。SAML 2.0のシングルサインオンもHeroku TeamsとHeroku Enterpriseでしか使えません。

Private SpacesとShieldのコンプライアンス対応

通常のdynoは他の利用者と共有される基盤（Common Runtime）で動きます。独立したネットワークが必要な場合に使うのはPrivate Spacesで、さらに医療・決済のような規制業種向けの製品はShieldです。Shield dynoは料金ページ上で月150ドル（Shield-S）からで、HIPAA準拠のためのBAA締結とPCI DSSへの対応、キーストロークログの記録が含まれます。独自ドメインのTLS証明書は、DNSを正しく設定してAutomated Certificate Managementを有効にすると、自動発行・更新できます。

2026年のHerokuは採用してよいか：提供方針とリージョンからの判断

採用判断を左右するのは、2026年の方針変更と日本からの利用条件の2点です。

2026年の提供方針：安定運用重視への移行と機能追加・既存契約の継続

Herokuは2026年2月6日の公式ブログで、安定性・セキュリティ・信頼性・サポートに集中するsustaining engineeringモデルへ移ると発表しました。クレジットカードで支払う既存・新規の利用者は、価格・請求・サービス内容とも変更なしと明記されています。一方で、Enterprise Account契約は新規顧客に提供されなくなりました。既存のEnterprise契約は更新できます。

サービス終了の発表ではありません。2026年3月19日のHeroku March 2026 Updateでは、この方針に沿う機能は今後も出すと明記され、slug上限の1GBへの倍増、ビルド時間の延長、Heroku CLI v11が同時に告知されました。8月のFine-Grained Access Controlもこの流れの機能追加です。方針の原文はAn Update on Herokuで確認できます。

東京リージョンの利用条件：Private Spaces限定と通信遅延

Eco・Basic・Standard・Performanceが動くCommon Runtimeのリージョンは、us（米国）とeu（欧州）の2つだけです。tokyoはPrivate Spaces用のリージョンとして用意されていますが、Private Spacesは認証済みのHeroku TeamsかHeroku Enterpriseでしか使えません。個人や小規模チームが月数十ドルの構成で使う場合、アプリは米国か欧州に置くことになり、日本の利用者からは往復の通信遅延が加わります。

Herokuの採用条件と見送る条件：Salesforce連携と国内向け応答速度

Herokuを選んでよいのは、次のどちらかに当てはまる場合です。1つは、Salesforceを導入済みで、Heroku ConnectやAppLinkでCRMのデータを使う顧客向けアプリを作る場合です。この連携を他のPaaSで作り直す手間は無視できません。もう1つは、既にHerokuで動いているアプリを保守する場合で、方針変更後も価格とサービスは維持されています。

見送るべきなのは、国内ユーザー向けで応答速度が重要な新規サービスを、Private Spacesなしで立ち上げる場合です。この条件なら、東京リージョンでコンテナを動かせるCloud Runとは？GCPのサーバーレスコンテナの仕組み・料金や、AWS上で同じくコードを渡すだけのAWS Elastic Beanstalkとは？仕組み・対応プラットフォームと料金、Amazon Lightsailとは？EC2との違い・料金・始め方で扱うVPS型の構成を先に比べてください。秒単位課金の実額とリージョンを比べるならRailwayのデプロイ手順とrailway.ts移行｜料金の実額とリージョンの制約、主要サービスを横並びで見るならPaaSの例｜主要サービス一覧と選び方が参考になります。長期運用を前提にする場合は、機能追加が安定運用の方針に沿うものに限られる点を踏まえ、必要な機能がCedar世代で提供されているかを事前に確認してください。

よくある質問

Herokuは今でも無料で使えますか？

使えません。無料のdyno・Heroku Postgres・Redisのプランは2022年11月28日に終了しました。最も安いのはEco dynoの月5ドルで、アカウント内のEco dyno全体で月1000時間まで動かせます。Postgresを使って常時稼働させる最小構成は、Basic dyno（月7ドル）とEssential-0（月5ドル）で月12ドルほどです。学生はHeroku for GitHub Studentsのプログラムでプラットフォームクレジットを申請できます。

Herokuへのデプロイが失敗するときは何を確認しますか？

まずheroku logs --tailでエラーコードを見ます。R10ならポートを環境変数PORTから読んでいるか、H10ならProcfileの起動コマンドと依存パッケージ、H14ならweb dynoが1台以上あるかを確かめます。ビルド段階で止まる場合は、package.jsonやrequirements.txtがリポジトリの直下にあるか、pushしたのがmainかmasterのブランチかを確認してください。

HerokuとAWSの違いは何ですか？

AWSはEC2のようにサーバー構成を自分で管理するサービスに加え、コードのアップロード後に環境構築やスケールを任せられるElastic Beanstalkも提供しています。HerokuはOS更新やスケール機構まで提供するPaaSで、git pushだけでデプロイできる代わりに、初期応答まで30秒というタイムアウトや、揮発性ファイルシステムなどの制約を受け入れる必要があります。

Herokuは日本のリージョンで使えますか？

通常のdynoでは使えません。Common Runtimeのリージョンは米国と欧州だけです。東京リージョンはPrivate Spaces専用で、認証済みのHeroku TeamsかHeroku Enterpriseが必要です。

Herokuはサービス終了するのですか？

2026年10月時点で終了の発表はありません。2026年2月6日に発表されたのは安定運用を重視する方針で、3月にはその目的に沿う機能追加を継続すると補足されています。クレジットカード払いの利用者は価格とサービスが据え置かれ、アプリ・パイプライン・チーム・アドオンなどの機能も従来どおり使えます。

関連記事

• PaaSとは？IaaS・SaaSとの違いと開発を速める仕組み・制約から採用判断まで解説
• PaaSの例｜主要サービス一覧と無料枠・提供状況で選ぶ
• Railwayのデプロイ手順とrailway.ts移行｜料金の実額とリージョンの制約
• CI/CDとは：仕組み・パイプライン構成・GitHub Actionsの設定例と導入判断の基準を解説
• ブルーグリーンデプロイメントとは｜仕組み・他方式との違い・AWS/Kubernetes実装をコード例で解説
• AWS Elastic Beanstalkとは？仕組み・対応プラットフォームと料金・採用判断を実装者目線で解説
• Salesforceのシステム連携とは？API方式の選定とコール上限の設計を実装目線で解説
• Cloud Native Buildpacksとは？Dockerfile不要のイメージ生成とリベース運用を実装目線で解説