HostingerのWeb Apps Hosting は、GitHub、ZIPファイル、またはAIコーディングエージェントからコードをプッシュすれば、サーバーを管理することなく、約1分でライブの本番アプリを立ち上げられるというシンプルな訴求を軸に作られています。実際に自分でデプロイをクリックしたときに、そのどれだけが本当なのかを知りたくて、調べてみました。
HostingerでWeb Appsをより速くデプロイ
Hostingerで最新のWebアプリを、自動ビルド、管理されたインフラ、グローバルCDN、SSL、セキュリティツール、30日間返金保証付きでデプロイできます。
Hostinger を訪問する 長所と短所 Pros フレームワークとNodeのバージョンを自動検出 ライブのビルドログがあり、ブラックボックスではない CDNがグローバルな読み込みを目に見えて高速化 2大陸からのGTmetrixで満点を記録 Kodeeが正確で検証済みの回答を返す マルウェアスキャナーと脆弱性スキャンがクリーン 環境変数がビルド時に正しく適用される 無料ドメイン、メール、SSLが含まれる 標準の30日保証で、VPSのようなクールダウンなし Cons 「Managed MySQL」はそれでも手動作成が必要 Web Apps専用のナレッジベースカテゴリがない 初回デプロイの前にMySQLデータベースを作成し、その接続情報を環境変数に追加しておけば、アプリが公開された瞬間から接続できます。
評価の内訳 HostingerのWeb Apps Hostingを採点するにあたり、私はHostAdviceの評価方法論 を適用しました。これはサイト上のすべてのレビューで使われる標準化された手法で、スコアがマーケティング文句ではなく実際のテストに基づくようにするためです。以下が各項目ごとのスコアです。
項目 スコア このスコアの理由 価格 9.2/10 標準の30日保証が適用され、VPSのような返金クールダウンはない。 機能 9.0/10 幅広いスタックをサポートするが、Managed MySQLは手動セットアップが必要。 パフォーマンス 9.8/10 2大陸からのGTmetrixとダッシュボードのスコアが満点だった。 使いやすさ 9.6/10 自動検出された、速くて分かりやすいデプロイ工程。 サポート 9.5/10 Kodeeがライブのアプリ状態を確認し、2回とも正確な回答を返した。 総合 9.4/10 強力なベンチマークとサポートが、小さな粗さによってわずかに抑えられた。
HostingerでWebアプリを、DevOpsの手間なくホスト
自動デプロイ、管理されたSSL、グローバルCDN、組み込みのセキュリティを備えた完全管理型ホスティングで、最新のWebアプリケーションを展開できます。
Hostinger を訪問する HostingerはWeb Apps Hostingを、Business と Cloud Startup の2つのティアで販売しており、どちらも従来のサイト作成ではなく、Node.jsや最新のJavaScriptアプリをデプロイするために特化して作られています。
私がテストしたCloud Startupは、Businessに比べてアプリ数の上限とCPUコア数が2倍で、両プランとも無料ドメイン、無料のビジネスメール、管理されたSSLを初年度のチェックアウトに直接バンドルしています。
注文前に知っておきたい点がいくつかあります。
返金保証: Web Apps HostingはHostingerの標準ホスティング返金条件に含まれ、購入日から30日間のシンプルな期間です。これは、HostingerのVPSプランに適用される、返金申請の間にさらに180日のクールダウンがある条件よりも明らかに分かりやすいものです。ここではそのクールダウンは適用されません。無料トライアル: 専用の無料トライアルは見当たりませんでした。評価期間としては30日間の返金保証を使う形になります。支払い方法: チェックアウトではデフォルトの支払い方法としてカードが表示され、Visa、Mastercard、Amex、Discoverのロゴが並び、さらに別の支払い方法をチェックアウト中に追加するオプションがありました。含まれているもの: 1年間の無料ドメイン、1年間の無料メールボックス、管理されたSSLがすべて追加料金なしでプラン料金に含まれているため、表示価格は、完全に機能し保護されたデプロイを始めるための実質的な費用にかなり近いです。唯一のアップセル: メールマーケティングの追加機能であるHostinger Reachが、独立した月額価格付きの強調表示ボックスとしてカートに出てきます。簡単にスキップでき、デフォルトでバンドルされたり、事前選択されたりはしていません。Web Apps Hostingプランを30日以内にキャンセルする場合、Hostingerの返金ポリシーでは除外リストではなく標準条件に含まれるため、その期間内にシンプルにキャンセルすれば、VPSやドメイン購入に付く追加条件なしで返金の対象になるはずです。
フレームワークとNodeバージョンの自動検出 管理されたMySQLデータベース作成ツール グローバルCDNがデフォルトで有効 WAFとDDoS保護を含む 毎日およびオンデマンドのバックアップ マルウェアスキャナーと脆弱性スキャン GitHub連携と自動デプロイ 無料ドメイン、メール、SSL 上級ユーザー向けのSSHアクセス コードからライブアプリへ、Hostingerで
GitHubリポジトリを接続するか、プロジェクトをアップロードするだけで、管理されたインフラ、自動デプロイ、毎日のバックアップ付きでオンライン化できます。
Hostinger を訪問する Web Apps Hostingは完全管理型なので、VPSレビューのようにCPU、RAM、ディスクを直接ベンチマークするためのシェルアクセスはありません。
測定できるのは、デプロイされたアプリ自体が、世界中の実際の場所からどれだけ速く読み込まれ、応答するかです。私はこれを4つの観点からテストしました。2大陸からのGTmetrix、50以上のポイントにわたるグローバル整合性チェック、そしてHostinger独自のビルトイン速度ツールのデスクトップとモバイルの両方です。
テスト対象のアプリは、下の「使いやすさ」セクションで扱うNext.jsデプロイで、Cloud Startupプラン（4 CPUコア、4096 MB RAM、100 GB NVMeストレージ）上で稼働しており、CDNはデフォルトで有効です。
1. GTmetrix、2大陸からのテスト 結果が一度きりの好条件ではなく、安定して再現されるかを見るために、私は世界の異なる2地点からGTmetrixを2回実行しました。
指標 シカゴ, USA フランクフルト, Germany パフォーマンススコア 100% 100% 構造スコア 100% 100% TTFB 237ms 145ms 接続 174ms 48ms バックエンド 63ms 97ms First Contentful Paint 339ms 217ms Largest Contentful Paint 339ms 217ms Total Blocking Time 0ms 0ms Cumulative Layout Shift 0 0 Onload Time 482ms 331ms Fully Loaded Time 553ms 441ms
両方の実行でPerformanceとStructureのどちらも100%の満点となり、どちらの場所でもレイアウトシフトはゼロ、ブロッキングタイムもゼロでした。つまり、読み込み中にブラウザの注意を奪うものも、表示を揺らすものも何もなかったということです。
本当に興味深いのは、サーバー自体はUSに置いてあるにもかかわらず、フランクフルトのほうがシカゴのすべてのタイミング指標で勝っていたことです。その結果はCDNを踏まえるとしか説明できません。
CDNが有効になっていれば、このケースのようにデフォルトで有効なのですが、訪問者は必ずしもオリジンサーバーに直接到達しているわけではありません。
最寄りのキャッシュされたエッジノードに到達するため、実際のサーバーがUSにあっても、ヨーロッパのテスト地点のほうがUSの地点より速くなることがあります。これは、Hostingerのデフォルト有効のCDNが、単なるマーケティングの飾りではなく実際に機能していることを、現実的かつ測定可能に示しています。
2. グローバル一貫性（Check-Host） 私はCheck-Hostが提供するすべてのチェックポイント、54地点・6大陸にわたって、ライブURLに対してHTTPチェックを実行しました。全体像は以下の通りです。
成功したチェックはすべてクリーンな200 OKを返し、エラーも、部分的な失敗も、予期しないリダイレクトもありませんでした。
応答時間は、CDNキャッシュが実世界の距離でどう振る舞うかをはっきり示していました。
地域の例 応答時間 Germany, Langen 0.006s France, Paris 0.017s Netherlands, Amsterdam 0.022s UK, London 0.045s USA, New York 0.048s USA, Los Angeles 0.112s Singapore 0.834s Japan, Tokyo 0.815s
ヨーロッパのチェックポイントは一貫して最速で、いくつかは50ミリ秒未満でした。一方、どのエッジノードからも最も遠いチェックポイント、Tokyo、Singapore、Ho Chi Minh Cityでは、依然として有効な200レスポンスが返り、ただし0.3〜0.8秒の範囲で少し遅くなっていました。
これはCDN対応のデプロイとして予想される形です。エッジに近い場所では速く、遠い場所でもきちんと機能する、ということです。
Kazakhstan、Romania、そして4つのRussianチェックポイントのうち2つで出た4件のタイムアウトは、Hostingerのインフラの問題とは考えません。
同じ国の他のチェックポイントは成功しており（Saint Petersburgは0.063sで問題なし、Moscowの2つはタイムアウト）、これはデプロイ済みアプリの問題というより、チェックポイント側の地域的なネットワーク制限を示しています。
3. Hostinger独自の速度ツール、デスクトップとモバイル Hostingerはダッシュボード内に独自のPage Speedテストを用意しているので、私はGTmetrixの独立した結果と比較し、どちらか一方だけを鵜呑みにしないようにしました。
指標 デスクトップ モバイル 総合スコア 100/100 100/100 First Contentful Paint 0.3s 1.1s Largest Contentful Paint 0.3s 1.1s Speed Index 0.3s 1.1s Total Blocking Time 40ms 10ms Cumulative Layout Shift 0 0
どちらのデバイスタイプも100点満点で、デスクトップの数値はGTmetrixが独立して測定した結果とかなり近く一致していました。これこそが、両方を走らせる本当の意味です。異なる2つのツール、異なる2つの測定方法、それでも互いに一致しているのです。
モバイルは、シミュレートされた遅い接続と弱いプロセッサを使うため、当然ながらすべてのタイミング指標で遅くなりましたが、それでも100スコアに値するほど十分に速く、単に採点基準が甘いからではない、真に強いモバイル性能でした。
ツール自体の一貫性のない点が1つあります。スコアはどちらのデバイスでもきれいに100なのに、その下のDiagnosticsパネルでは、network dependency tree、document request latency、multiple redirectsの回避という3項目が文字通り0点、さらにunused JavaScriptとlegacy JavaScriptの2項目が50点と表示されています。
これらの低いサブスコアは、全体の評価を下げることはありませんでした。つまり、デプロイに何か問題があるというより、実際に存在する小さな最適化の余地として捉えるべきです。
別の点として、これらのDiagnosticsの横に表示される「helpful links」はすべてWordPress向けです。「Speed up WordPress in 9 easy steps」「How to optimize images for your WordPress site」などで、このアプリはNode.jsでWordPressはどこにも関係していません。これは共有された診断テンプレートの名残であり、この製品向けに作られた内容ではありません。
パフォーマンスに関する総評 すべてのテストが互いに一致していたこと、これこそが実際の発見です。GTmetrixは2大陸からのテストでPerformanceとStructureの両方を100%と評価し、Hostinger独自のツールもデスクトップとモバイルの両方で100/100を示し、54地点のグローバル一貫性チェックでは、いくつかの地域的なネットワーク制限で知られるチェックポイントを除いてすべて200応答でした。
特筆すべき技術的ポイントは、サーバー自体がUSにあるのに、ヨーロッパのテスト地点がUSのテスト地点より速かったことです。これは、Hostingerがデフォルトで有効にしているCDNが、マーケティング上の文言ではなく実際に意味のある働きをしているという、実測可能な証拠です。
一般的なWebアプリをこのプランにデプロイするなら、あなたは自分で何かを頑張らなくても、本当に速く、世界的にも一貫した読み込み速度を期待してよいはずです。
注意すべき唯一の粗い部分は見た目の問題です。内蔵診断ツールがNode.jsアプリに対してWordPress向けのガイドを勧め続けているのは、コピー＆ペーストの残りであり、パフォーマンスには影響しないものの、全体として優れている結果の洗練度を少し損なっています。
Hostingerによる管理されたWebアプリホスティング
Hostingerがデプロイ、インフラ、セキュリティ、SSL、バックアップ、グローバル配信を引き受けるので、アプリ作りに集中できます。
Hostinger を訪問する 私はHostingerのWeb Apps Hostingを、ランディングページからチェックアウト、そして新規アカウントから完全に稼働するNode.jsデプロイまでテストしました。
その中には、プラン選択、支払い、ビルド方法の選択、GitHub接続、そしてビルド完了をリアルタイムで見ることが含まれていました。実際の流れはこんな感じでした。
1. 登録 私はWeb Apps Hostingのランディングページから始めました。そこでは1つのCTA、Start deploying が前面に出ています。
それをクリックしても、サインアップフォームは開きません。価格セクションへそのままスクロールするので、最初の実質的な決定はアカウント情報を入力することではなく、どのプランを買うかです。
2つのプランが横並びで表示されていました。
プラン 表示価格 Web Apps数 CPU / RAM Business $3.99/mo (79% off $18.99) 5 2 cores / 3 GB Cloud Startup $7.99/mo (71% off $27.99) 10 4 cores / 4 GB
私は、エントリープランよりもアプリ数の上限とCPUの余裕が2倍あるCloud Startupを選びました。1つ小さな不整合としてここで指摘しておきたいのは、料金ページでは「Cloud Startup」と呼ばれているのに、カートでは同じプランが「Startup plan」と表記されていることです。機能上の問題ではなく、同じチェックアウトの2画面間での名称の不一致です。
カート自体はすっきりしていました。48か月契約、割引額、1年間の無料ドメイン、無料メールボックスが表示され、そして1つのアップセルとしてHostinger Reachのメールマーケティングが、事前選択ではなく独立した強調表示ボックスで出ていました。
私はそれをスキップし、問題なくContinueをクリックしました。
新規顧客の場合、ここでチェックアウトにアカウント作成ステップが挿入され、その後に請求先住所と支払いページへ進みます。
次に、請求先住所を入力し、支払い方法を選び、カード、PayPal、またはその他のオプションを選んで送信します。Submit paymentをクリックしてから数瞬で購入確認メールが届き、その後すぐにhPanelへ移動し、プランはすでにプロビジョニングされていました。
私の所感: チェックアウトは短く、アップセルも、隠れたスキップリンクを探さなくても簡単に断れます。プラン名の不一致は小さな点ですが、初めての購入者なら、本当に正しいティアを選んだのか一瞬立ち止まって確認したくなるような種類の細部です。
2. ダッシュボード 支払いが通ると、Hostinger独自のin-houseコントロールパネルであるhPanelに移動します。これは、あなたの新しいWeb App専用ではなく、Hostingerが販売するすべての製品を管理するために作られたものです。
最初に表示されるページはHome で、上部にAIプロンプトバーがあります。「Hi, [your name]! How can I help you today?」という文言とテキスト欄、その下に6つのショートカットボタン、Get domain、Create website、Get email、Migrate site、Get VPS、Try email marketingが並びます。
その下へスクロールすると、以下があります。
機能プロモーションタイル : AI Builder、オンラインストアツール、無料ビジネスメールの主張、AI agents、自動化アプリ、無料ドメインの主張To-doチェックリスト : Reachの設定完了、無料メールの受け取り、無料ドメインの受け取りへ誘導する項目Your business 、アカウントに紐づくすべてのサイト、アプリ、VPSインスタンスの一覧で、それぞれにManage site ボタン付きVPS 、さらに下にある別の表で、IPアドレス、ステータス、有効期限ごとにVPSインスタンスが並ぶAgent パネルも、HomeだけでなくhPanelのすべてのページの右上に常時表示されています。これは同じKodeeアシスタントで、サポート用にも使われますが、ここでは一般的な操作ツールとして配置されており、「Deploy my Node.js app」や「Harden VPS updates」のような用意済みプロンプトを、完全な質問を書かなくてもそのまま送れます。
Homeは、アプリがすでに存在していれば本当に役立ちます。Your businessの中の項目から直接そこへ飛べるからです。しかし、新しいWeb Appを作成したりSetupボタンにたどり着いたりする場所ではありません。そのためには、サイドバーの別の経路を使う必要があります。
左サイドバーのWebsites をクリックする その下にサブメニューが展開される: WordPress、AI Builder、Web Apps 、PHP/HTML、Migrations Web Apps をクリックする
そのクリックで、Homeとはまったく別の画面に移動します。そこは、あなたの実際のホスティングプランを中心に整理された画面です。
ここでは、所有している各プランがカードとして表示されます。私のアカウントでは、それが縦に3枚並んでいました。
プラン ステータス 利用可能な操作 Business Hosting plan has expired, renew until 2026-09-02 Generate backups, Renew Growth Hosting plan has expired, renew until 2026-08-28 Renew Cloud Startup Plan expires on 2027-08-13 Setup
Business カードには、以前のテストからすでに1つライブのアプリが掲載されていて、orange-walrus-700988.hostingersite.com、さらにToolsとDashboardの各ボタンが付いていました。
これはそれ自体で注目すべき点です。いったんWeb Appが存在すると、そのカードにはこのようにライブサイトへの行が追加されます。Cloud Startupカードがセットアップ完了後に見える姿もまさにこれです。
私が買ったばかりでまだセットアップしていないのはCloud Startupプランだったので、そのカードには代わりに単独のSetup ボタンが表示されていました。これが実際にWeb App作成ウィザードを開始するボタンで、デフォルトで表示されるHome画面からではなく、Websites → Web Apps の下に来て初めて出ます。
私の所感: hPanelは、正しい画面にたどり着けば分かりやすいです。しかし、Web Apps Hostingには明確な入口がありません。Homeに着くと表示されるのはプロンプトバーとショートカットであって、アプリ作成への導線ではありません。Websitesをクリックし、そのあとWeb Appsを開いて初めてSetupが現れるのを知っていなければいけません。これは「1分でライブ」という売り文句の製品としては、少し多めのクリックです。ただし、一度そこへ行けば、プランカードはきれいで、ステータスも正直です。すでにアプリが動いているプランでは、それがカード上にそのまま表示されます。
3. アプリのデプロイ Setup をプランカードでクリックすると、短いオンボーディングフローが開きます。「Where would you like to start?」という画面で、Create a new site、Migrate an existing site、I hired someone to build my siteの3択です。私はCreate a new siteを選びました。
すると「How do you want to build your website?」に進み、上部に初心者向けの2つの選択肢、Hostinger AI BuilderとWordPress + AIがあり、その下の「for advanced users」見出しの下に、Node.js web app とPHP/HTML websiteの2つの選択肢があります。Node.js web appを選ぶと、実際にWeb Apps Hosting製品そのものに入ります。
これは、製品を比較する人にとって本当に重要な構造的な注意点です。Web Apps Hostingには独自のサインアップフローがありません。
AI BuilderやWordPressと同じ、サイト作成ウィザードの1分岐にすぎません。
私はNode.js web appの横の丸をクリックし、次にNextをクリックしました。
そこからは以下のように進みました。
Domain screen : テストデプロイだったため、実ドメインを紐づける代わりにUse temporary domainを選びました。
Server location screen : Hostingerは最も近い地域としてFranceを事前選択しており、167msのレイテンシーを表示していました。United Statesのオプションまでスクロールすると、364msと2倍以上でした。それでも私はUnited States, Massachusettsを選びました。ここでこのロケーションピッカーが毎回教えてくれる教訓は、リスト上の最小値ではなく、実際の訪問者がどこにいるかで選ぶことです。
私のテストアプリの想定読者は米国ベースなので、USのサーバーはFranceのサーバーよりも実際に彼らへ速く配信できます。画面上の数値は、Hostingerのテストに対してそのサーバーがどれだけ速く応答するかを示すのであって、実際の利用者に対してどれだけ速く応答するかを示すわけではありません。
Deploy method screen : 2つの主要オプション、Import Git repository（Recommendedと表示）とUpload your files、さらにClaude Code、Cursor、VS CodeからHostinger Connectorを通して直接デプロイするための案内がありました。私はImport Git repositoryを選び、Connect with GitHubをクリックしました。
すると、すでにログインしていなければ本物のGitHubサインインウィンドウが開き、その後にInstall & Authorize Hostingerという権限画面が表示され、次の2択が出ます。
all repositories 、未来に作成するものも含めて所有するすべてのリポジトリにインストールし、公開リポジトリには読み取り専用アクセスを与えるonly select repositories 、個別に選んだリポジトリのみにインストールし、付与される正確な権限として、actions、metadata、repository hooksへの読み取りアクセス、administration、code、pull requestsへの読み書きアクセスが一覧表示されます。Install & Authorize をクリックすると、GitHubは自動的にhPanelへ戻します。するとSelect Git repository to importに移動し、GitHubアカウントに紐づくすべてのリポジトリがスクロール可能な一覧で表示され、それぞれにDeployボタンが付いています。私は以前にプッシュしておいたテスト用リポジトリ、hostadvice-webapps-testを見つけ、その横のDeployをクリックしました。
そのボタンをクリックしてから、次のページが読み込まれるまで進捗表示なしで約30秒かかりました。クリックが効いたのかどうか不安になるくらいの長さです。
ようやく表示されたページは「Review build settings」というタイトルで、コミットする前にアプリの公開先を明確に示しています。「Deploys to ivory-llama-856835.hostingersite.com.」その下には、何も触らなくてもすでに自動検出されていて、
設定 自動検出された値 Framework preset Next.js Branch main Node version 22.x Root directory ./ Build and output settings Default for Next.js Environment variables None (until you add one)
これら5つの行にはそれぞれChange またはAdd ボタンがあり、検出結果が間違っていても何も固定されません。
私はEnvironment variablesの横のAdd をクリックし、後で実際のライブアプリに届くか確認するためにキーと値を1組設定し、ダイアログのFinish をクリックした後、ページ下部のメインのDeploy ボタンをクリックしました。
ビルドの監視
画面はDeploying… ビューに切り替わり、ラベル付きの進捗バー「Deployment from GitHub」が実際の段階を追って進みます。私は28%、そして51%へ進むのを見ました。進捗バーの下には折りたたみ式のBuild logs パネルがあり、展開すると、本物のライブのターミナル出力がリアルタイムで表示されます。プレースホルダーのスピナーではありません。
> hostadvice-webapp-test@1.0.0 build
> next build
▲ Next.js 16.3.1 (Turbopack)
✓ Running next.config.mjs took 22ms Creating an optimized production build …
デプロイ完了
ビルドが終わると、Deployment completed! 画面に移り、実際に動いているアプリのライブサムネイルプレビューがカード上にそのまま表示され、横にはリポジトリ名と割り当てられたライブURLの概要が表示されます。
ここからは、Go to dashboard をクリックして、以後の管理画面に進めます。
私の所感: 自動検出がこのプロセスの目玉です。フレームワーク、ブランチ、Nodeバージョンが一つの手入力もなしに正しく取得され、ライブのビルドログによって待ち時間が不透明ではなくなっています。唯一の弱点は、設定画面にたどり着く前の30秒の空白で、何かが止まったのかと思うくらいの長さです。
4. ライブデプロイの確認 管理ツールを見る前に、アプリが本当にデプロイされて動いているのか、それとも画面上で「Completed」となっているだけなのかを確認したかったのです。
Deployment completedページから、ダッシュボードのプレビューサムネイルだけを信じるのではなく、ivory-llama-856835.hostingersite.com のライブURLへそのまま移動しました。
ライブページは読み込まれ、アプリに書かれているとおりの内容が表示されました。
Server build time 、ライブのタイムスタンプで、古いキャッシュではなく新しくビルドされたページであることを示すEnvironment variable check 、デプロイ画面で設定したカスタム変数が、ダッシュボードのプレビューだけでなく実際のライブサイトでも正しく確認されたことを示す
次に、アプリ自身のPing the API route ボタンをクリックしました。これは静的コンテンツを表示するだけではなく、ライブのバックエンドエンドポイントを呼び出します。返ってきたのはクリーンなJSONレスポンスでした。
json
{
“status”: “ok”,
“serverTime”: “2026-08-19T13:44:05.234Z”,
“nodeVersion”: “v22.18.0”
}
この応答は見た目以上に重要です。ページが正しく読み込まれるだけでは、静的ファイルがアップロードされたことしか分かりません。
API呼び出しが機能しているということは、実際のNode.jsサーバーが裏で動いていて、本物のリクエストに応答していることを示します。これは「Node.js web app」ホスティングの本質であり、キャッシュされた静的ページでは偽装しやすい一方、ボタンを押したまさにその瞬間に生成されるライブのサーバー時刻では偽装しにくい部分です。
私の所感: これは、このプラットフォーム、あるいは同種のプラットフォームでのデプロイを信頼する前に、あなたにも勧めたい確認方法です。緑色の「Completed」ステータスとプレビューサムネイルは、ビルドが終わったことを示すだけです。ライブURLを開き、API呼び出しやデータベース読み取りのような静的ページでは偽装できない動的なものを実行してみて、サーバーが本当に生きていて、あなたが作ったものを実際に動かしているかを確かめるべきです。
5. Web App管理 ライブアプリが本当に動いていることを確認した後、hPanelに戻り、この製品の実際のサーバー管理層であるアプリ固有の管理ダッシュボードを、前述の一般的なhPanel Homeとは別に、最初から最後まで見てみました。
ダッシュボード概要。 ここに着いた瞬間、4つのステータスバッジで状況がひと目で分かります。
バッジ ステータス Running Green Auto-deployment Green Malware protected Green CDN Green
4つともデフォルトでGreenになっており、手動で何かを切り替える必要はありませんでした。その下にはLast deployment カードがあり、状態、リポジトリ、作者、コミット、デプロイ時刻、検出されたスタック、Nodeバージョンが一目で確認できます。掘り下げなくても見たいものがすべてそろっています。
自動で実行されたPage Speed test は、私が何も触らないうちにライブサイトを対象にすでに走っており、デスクトップで99/100のスコアを返していました。すぐ横には、データベース接続、バックアップ、ファイルマネージャー、ランタイムログ、キャッシュへのクイックリンクがあるEssentials パネルがあります。
Deployments、環境変数、ログ。 これらは3つの別ページで扱われます。
Deployments は、プッシュ、作者、ブランチ、コミットハッシュ、完了ステータスの完全な記録を保持しており、最新の1件だけでなく履歴として残りますEnvironment variables には、デプロイ時に設定した1つの変数が正しく表示され、保存され適用されたことが確認できました。設定時に一度表示されただけで忘れられたわけではありませんRuntime logs は、Next.jsの起動行、readyのタイムスタンプ、問題とエラーの件数をライブで流していましたが、私が見ている間ずっとどちらも0のままでしたセキュリティ。 Malware Scanner はクリーンな結果で、「Your website is safe」と表示されました。ただし、注意点も明確にありました。このスキャンはWebサイトのファイルのみを対象とし、データベースの中身は含まれません。より深い検査、データベースまで含む検査をしたい場合は、別料金のクリーンアップオプションがあります。Vulnerabilities スキャンもクリーンでした。
データベース。 ここは、買う前に理解しておくべき、製品のマーケティングと実際のギャップがある部分です。プランはManaged MySQLを目玉機能として宣伝していますが、何も自動ではプロビジョニングされません。
Databasesセクションを開くと、手動のCreate a New MySQL Database And Database User フォームが表示されます。つまり、アプリがデータベースを使う前に、自分でデータベースに名前を付けて作成する必要があります。私はこの点をSupportセクションで後述するKodeeに直接確認しましたが、答えは明快でした。managedとは、Hostingerが裏側のデータベースインフラを運用するという意味であって、データベースがアプリ公開と同時に自動で作成されるという意味ではない、とのことでした。
高度なアクセス。 Advancedの下にSSHアクセスがあり、IP、ポート、ユーザー名も表示されていますが、デフォルトではInactive で、使うには手動でEnableをクリックする必要があります。File Managerでは、このアプリのファイルだけを見るか、ホスティングプラン全体のすべてのファイルを見るかを選べます。
私の所感: 日常的なダッシュボードは、整理が行き届いていて分かりやすいです。とくにセキュリティとデプロイ履歴は見つけやすく、本当に情報量がありますし、0件の問題しかないランタイムログとクリーンなマルウェアスキャンによって、アプリが単にオンラインなだけではなく健康であるという実感が得られました。
一方で、インターフェースがやや過大に見せているのはデータベース部分です。「Managed MySQL」という表現は、プランページ上ではアプリが公開された瞬間に使えるもののように読めますが、実際には自分で作成する管理画面がある、というのが現実です。
使いやすさに関する総評 チェックアウトは短く、アップセルも簡単に断れ、デプロイ自体の流れはこの製品全体で最も優れている部分です。スタック、ブランチ、Nodeバージョンの正確な自動検出に、スピナーではなく本物のストリーミングビルドログが組み合わさっています。
その後に続くダッシュボードも、日常利用のためによく整理されており、デプロイ履歴、環境変数、セキュリティスキャンがすべてワンクリックで、分かりやすくラベル付けされています。
この製品が、自らのマーケティングほどには少しだけ注意を求めるのは、データベースの部分です。「Managed MySQL」は、アプリが公開されたらすぐに使えるもののように聞こえますが、実際には手動作成フォームがあり、自分で済ませる必要があるシンプルなステップです。
どれも難しくはありませんが、最初からそれが来ると知っているかどうかが、プランページには書かれていないポイントです。
Hostingerでのサポートレベル
KodeeとWeb Apps Hostingで、すばやく具体的な回答を得られます。
Hostinger を訪問する 私はHostingerのWeb Apps Hostingに対するサポートを、hPanelに組み込まれたAIアシスタントであるKodeeを通じてテストし、その後ナレッジベースを確認して、問い合わせなしでどれだけの範囲をカバーしているかを見ました。Kodeeは2か所にあり、区別しておく価値があります。1つは公開マーケティングサイト上のAsk AI 、もう1つはhPanel内のどのページからでも使えるAgent パネルです。Web App専用のダッシュボードから直接でも使えます。
1. AIサポート（Kodee） 私は、テスト中に見つけた実際のギャップに基づく2つの質問をしました。一般的な問い合わせではなく、このプラットフォームへ本番投入する人にとって現実的な問題です。
Question 1 は、デプロイ失敗時の挙動と環境変数のタイミング、どちらも本番運用で本当に重要な点を確認するものでした。
If my app’s build fails partway through a GitHub deployment, does the app revert to the last successful version automatically, or does it go down until I fix and redeploy? And can I set custom environment variables before the first deploy, or only after?
Kodeeは両方について、直接かつ正確に答えました。ビルドが失敗しても、すでに動いているアプリは上書きされません。以前のデプロイが成功していれば、その最後に正常だったバージョンが配信され続けます。もし最初のデプロイで、戻る先がないなら、ビルドを修正して再デプロイするまでアプリは停止したままです。曖昧な安心材料ではなく、明快で正直な回答でした。
環境変数については、最初のデプロイ前に設定画面で追加できること、すでに稼働中のアプリでは、SettingsとRedeployを開いてEnvironment variablesで変数を追加・編集し、保存して再デプロイするという正確な3ステップを案内してくれました。
Question 2 は、私自身がダッシュボードを見ていて感じた2つのギャップ、つまり「managed MySQL」という表現と手動作成フォームの食い違い、そしてSSHがデフォルトでInactiveになっている点を掘り下げました。
This plan advertises managed MySQL, but the dashboard shows a manual ‘Create a New MySQL Database’ form rather than a database provisioned automatically. Is a database created for every Web App by default, or only if I create one myself? Also, SSH access is listed as available but shows as Inactive by default. If I never enable it, does that change anything about how my app actually runs, or is SSH purely an optional extra for advanced users?
Kodeeの回答は、私がインターフェースで確認した内容をそのまま裏付けるもので、やわらげた言い方ではありませんでした。データベースはすべてのWeb Appに自動作成されるわけではなく、「managed」とはHostingerがデータベースサービスとインフラを裏で運用しているという意味で、実際のデータベースを作成・設定するのは、私が見たその同じCreate a New MySQL Database画面を通して自分で行い、接続情報も自分のアプリの環境変数に追加する必要がある、ということでした。
SSHについては、それを有効化しなくても、アプリの実行、デプロイ、データベース接続には何も変わりがないことを確認してくれました。CLIコマンド、マイグレーション、直接のファイルデバッグ用の、完全に任意のツールとして位置付けられているだけで、裏側でこっそりプラットフォームが依存しているものではない、とのことでした。
私の所感: どちらの回答も、私がダッシュボードで手動確認した内容と一致しており、曖昧にしたり、弱めたりしなかったのが印象的でした。これは、そのサポートツールが実際の製品状態をきちんと確認していて、台本を読み上げているだけではない証拠です。どちらの質問も、一般的なFAQを貼り付ければ答えられるものではありませんでしたが、Kodeeは両方に、具体的で構造化された2部構成の回答を、1分ほどで返してくれました。
2. ナレッジベース Hostingerのナレッジベースを開くと、カテゴリ別のグリッドが表示され、合計20カテゴリがあり、それぞれに記事数が示されています。大きいものをいくつか挙げると、AI Builderが330記事、VPSが276記事、Emailが127記事、Websiteが103記事です。
Web Apps Hostingには専用カテゴリがありません。その内容はGetting Started、hPanel、Websiteに散らばっており、VPSやEmailのような専用のホームベースを期待している人にとっては、これは実際の発見です。
「Web Apps」を直接検索すると、71件の結果が8ページにわたって返ってきました。上位結果は、直接関連するものと、やや関係するだけのものが混在していました。
How to deploy apps built with Codex on Hostinger 、直接関連Hostinger AI Builder: How to create a web app in agentic mode 、近いが別製品How to add a Node.js Web App in Hostinger 、直接関連How to install Flutter Web on a VPS at Hostinger 、別製品いくつかのWebsite Builderの支払い方法記事（PayPal、WeChat Pay、BLIK）、本文のどこかに「web」と「app」があるだけで無関係
上位結果の1つ、How to deploy apps built with Codex on Hostinger を開き、その深さを確認しました。結果は非常によく構成された詳細な手順書で、対応フレームワークの一覧、GitHub取り込みとZIPアップロードの両方に対するステップごとのスクリーンショット、ビルド設定の例コマンド、デプロイ後のファイル構造の説明、データベース接続ウィザードの案内、脆弱性監視のセクション、そしてFAQブロックで締められていました。
Codex向けに書かれていますが、基盤となるプラットフォームは一般的なNode.js Web App製品と同じなので、その多くはそのまま直接当てはまります。
私の所感: 検索結果数は見た目上は強そうで、1つの用語に対して71件ヒットしますが、その中には似た言葉を共有しているだけの無関係な製品のノイズがかなり含まれています。実際に1つ全文を読んだ記事は、手順が明確で、実際のスクリーンショットがあり、本物のFAQセクションもあって、品質としては十分でしたが、それを見つけるには、自分が本当にデプロイしたい内容と関係ない結果をスクロールして抜ける必要がありました。
カスタマーサポートに関する総評 Kodeeのほうが、2つのサポート経路の中では優れています。私が試した質問はいずれも、デプロイ失敗時の復旧、環境変数のタイミング、データベースのプロビジョニング、SSHの実際の役割という、実際に検証可能な曖昧点に関するものでしたが、Kodeeはどれも正確かつ具体的に答え、私がダッシュボードで手動確認した内容と一致していて、曖昧にしませんでした。
ナレッジベースは、適切な記事にたどり着けば品質はしっかりしています。特にCodexデプロイガイドは詳細で最新です。ただし、Web Apps Hostingには専用カテゴリがなく、広く検索すると、役に立つ結果の中にかなりの無関係なコンテンツが混ざります。
素早く具体的な答えがほしいなら、Kodeeがより頼れる最初の窓口です。じっくり自分で読むなら、この製品に本当に当てはまるものにたどり着く前に、検索結果を自分でふるいにかけることになるでしょう。
Hostingerでのシンプルな最新Webアプリ向けホスティング
React、Next.js、Vue、Node.js、その他の最新アプリケーションを、サーバーや複雑なインフラを管理せずにデプロイできます。
Hostinger を訪問する Hostinger Web Apps Hostingをおすすめしますか？ はい。デプロイの流れはこの製品の最も優れた部分です。スタック、ブランチ、Nodeバージョンの正確な自動検出、スピナーではなく本物のストリーミングビルドログ、そして2大陸からの完全なGTmetrixスコア、54地点のクリーンなグローバル整合性チェック、デスクトップとモバイルの両方でHostinger独自ツールが示した100/100がそれを裏付けています。Kodeeも、テンプレート的な返答ではなく、実際の技術的な質問に対して正確で具体的な回答を返してくれました。
気になる粗い部分は小さいですが、買う前に知っておく価値があります。「Managed MySQL」は、アプリが公開された瞬間に使えるもののように読めますが、実際には手動作成フォームを意味します。また、ダッシュボードではWeb Apps HostingにHome画面からの分かりやすい入口がなく、まずWebsitesを経由する必要があります。
本当にこのレベルで速く、フレームワークに縛られないデプロイを求める開発者なら、この製品は簡単におすすめできます。チェックアウト後にすべての機能が即座に有効になると期待する人は、データベースを自分で用意するために、少し余分に時間を見ておくとよいでしょう。
Hostinger Rating based on expert review
