Hostgingerは、そのLaravel VPSを、Laravelプロジェクトを素早く本番公開するために設計された、プリインストール済みでAI管理のサーバーとして販売しています。その約束の大半は実地テストでも確認でき、強力なベンチマーク、有能なAIサポートエージェント、予定どおりに実行されていることが確認できたバックアップなどがありました。

ただし、ダッシュボード上のあるボタンをクリックすると、私はまったく予想していなかった場所へ連れて行かれました。その点は、自分でクリックする前に知っておく価値があります。ここからはその全体像を詳しく見ていきます。

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

Hostinger を訪問する

長所と短所

評価の内訳

HostingerのLaravel VPSホスティングを採点するにあたり、私はHostAdviceの評価方法を適用しました。これはサイト上のすべてのレビューで使われている標準化された手法であり、スコアが一貫し、マーケティング上の主張ではなく実際のテストに基づくようにするためです。各項目ごとの採点は以下のとおりです。

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

Hostinger を訪問する

プランと価格

HostingerはLaravelホスティングを、KVM 1からKVM 8までの4つのKVM VPSティアの1つとして販売しており、上位プランに進むにつれてCPUコア、RAM、NVMeディスク容量、帯域幅が一緒に拡張されます。

Laravel自体は別途購入するものではなく、チェックアウト時に選んだティアの上にワンクリックアプリとして重ねて導入されます。Cloudpanelは、稼働後にインストールを管理するための実際のコントロールパネルとして同梱されています。

注文前に知っておくべき点がいくつかあります:

• 課金期間: プランは1、12、24か月の前払いで、長期契約ほど月額料金に実際の割引が適用されます。各ティアと期間の詳細は下の価格ウィジェットを参照してください。
• 返金保証: VPSプランには30日間の保証がありますが、細則には実際の制限があります。VPSの返金請求は180日に1回しか行えず、その期間内に別のVPS購入で2回目の返金を申請しても通りません。既存VPSプランのアップグレードは完全に対象外です。
• 無料トライアル: Laravel VPSホスティング用の専用無料トライアルは見当たらず、30日間の返金保証のみでした。この制限を踏まえて評価期間を計画してください。
• 支払い方法: カード（Visa、Mastercard、Amex、Discover）、PayPal、Google Pay、ChinaとHong Kongで別バージョンのAliPay、そして暗号資産用のCoingateに対応しています。暗号資産での支払いは返金ポリシーの対象外なので、保証を重視する場合は注意してください。
• 含まれているもの: すべてのティアに、初年度無料の.cloudドメイン、フルrootアクセス、Git連携、Cloudpanelが追加料金なしで含まれているため、実質的なコストはコントロールパネルを別料金にするホストよりも表示価格に近くなっています。

Hostinger独自の案内では、KVM 1はシンプルなLaravelサイトに十分であり、KVM 8はより重いリソース集約型プロジェクト向けとされています。

テストから付け加えると、Manage Appボタンまわりのアプリ管理の混乱と、マルウェアスキャナーがデフォルトでオフになっている点は、どのティアでも同じように当てはまります。つまり、どのプランを選んでも、この2点は解消されません。CPUとトラフィックの需要に基づいてプランを選び、この2つの問題にはどのティアでも同じように対処してください。

機能

• 全ティアでAMD EPYCプロセッサー
• すべてのプランでNVMe SSDストレージ
• コードデプロイを効率化するGit連携
• SSHによるフルrootアクセス
• Cloudpanelコントロールパネルが標準搭載
• VPS管理タスク用のAIエージェント
• 各プランで自動週次バックアップ
• プランごとに1 Gbpsのネットワーク速度
• 初年度無料の.cloudドメイン

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

Hostinger を訪問する

パフォーマンス

Laravelアプリケーションは、そのコードだけでなく、その下で動くサーバー次第で生きも死にもします。ページ読み込みはPHPを実行するためのCPU速度に、データベースクエリはディスクI/Oに、セッションやキャッシュはメモリに依存します。アプリがキュージョブを実行したり実際の訪問者が来たりするなら、ネットワークスループットと持続負荷への耐性も重要です。

Laravel自体はそれを変えません。結局のところLinux上で動くPHPのままなので、ここでの本当のテスト対象はVPSです。

私はCPU、メモリ、ディスク、ネットワーク、そして持続的なストレス負荷を含む完全なベンチマークスイートをこのサーバーに対して実行し、このプランが実際に何を提供し、それが実際のアプリケーションにどうつながるのかを確認しました。

私がテストしたインスタンスはKVM 2プランで、チェックアウト時に選んだものです:

• CPU: 2 vCPU、AMD EPYC 9354Pプロセッサーを搭載したホストから割り当て
• RAM: 割り当て8GB中、使用可能7.8GB、加えて2GBのスワップ
• ディスク: 100GBのNVMe割り当て中、使用可能96GB
• OS: Ubuntu 24.04.4 LTS、kernel 6.8.0-137-generic

数値に入る前に、HostingerのLaravel VPSラインナップは他のVPSと同じくKVM 1からKVM 8までの4ティアで構成されており、KVM 2は下から2番目、最安プランの1つ上で、より重い複数アプリのワークロード向けのKVM 4やKVM 8よりもかなり下位に位置していることを知っておくとよいでしょう。

以下の内容は、小〜中規模のLaravelプロジェクト、実際のトラフィックはあるが控えめな単一アプリを想定しており、複数のサービスを1台に載せる大規模プラットフォームではありません。

1. CPUパフォーマンス

• シングルスレッド: 1,624.55 events per second、平均レイテンシ 0.61ms、95パーセンタイル 0.64ms

• マルチスレッド、2スレッド: 2,864.02 events per second、平均レイテンシ 0.70ms、95パーセンタイル 1.10ms

• スレッド公平性の標準偏差: 平均14,321.5 events per threadに対して182.50

では、このシングルスレッド数値が実際には何を意味するのかを説明します。典型的なLaravelリクエスト、つまりBladeビューのレンダリング、いくつかのEloquentクエリの実行、セッションの確認などは、複数コアに同時に広がるというより、主に1つのCPUコア上でPHP処理に時間を費やします。

このテストでイベントごとの平均レイテンシが0.61msだったということは、CPUがページを遅くする原因になる可能性は低いということです。

平均レイテンシと95パーセンタイルの差も小さく、0.61ms対0.64msでした。つまり、性能は一定で、たまに1つのリクエストだけが他より大幅に遅くなるようなことはありません。そうした挙動は、実際の訪問者に対してランダムなページ遅延として現れます。

マルチスレッド結果のほうが、並行処理を理解するうえではより有用です。 1スレッドから2スレッドへの増加でスループットはほぼ倍増し、約88パーセントのスケーリング効率でした。つまり、このVPSは、別テナントとの競合やオーバーヘッドによって物理コアの能力をあまり失っていません。

実用上は、このプランでPHP-FPMを2つのワーカープロセスで動かせば、CPUがボトルネックになるまでのリクエスト処理量は単一スレッド時のおよそ2倍になります。これは、2つのvCPUが互いに処理を取り合ってしまうような場合とは異なります。

スレッド公平性の数値、つまり2つのスレッド間で約1.3％のばらつきしかないことは、両コアがほぼ均等に仕事を分担していたことを裏付けています。実際のサイトでは、リクエストが片方のPHP-FPMワーカーに偏って滞留するのではなく、ワーカー間で均等に振り分けられることを意味します。

2. メモリ速度

• Sequential Write: 5,865.22 MiB/sec

• Sequential Read: 7,155.43 MiB/sec

メモリ速度はLaravelにとって見落としやすい意味で重要です。OPcacheの検索、セッション読み込み、リクエスト処理中にアプリが構築する配列やコレクションのすべてがRAM上にあり、Redisのようなキャッシュ層が同じマシン上で動いている場合は、そのメモリ帯域幅を奪い合います。

およそ書き込み5.9 GiB/秒、読み込み7.2 GiB/秒なら、このVPSはメモリの出し入れを十分高速に処理できるため、メモリ操作がリクエストを遅くする原因になる可能性は非常に低いです。典型的なLaravelアプリでは、ボトルネックになるのはRAM速度よりむしろディスクかネットワークです。

メモリでより直接的に重要なのは速度より容量です。使用可能7.8GBと2GBのスワップがあれば、このプランはPHP-FPM、MySQLまたはPostgreSQL、小規模なRedisインスタンスを1つのアプリ向けに同時に十分動かせますが、複数サイトを同じVPSで動かす場合や、大きなワーキングセットを持つデータベースには余裕があまりありません。

スワップは、一時的なメモリ急増に対する安全策であり、アプリがこのプランに対して本当に小さすぎる場合のRAM代替ではありません。

3. ディスクI/O

• Sequential Write: 740 MiB/s (776 MB/s)、740 IOPS

• Sequential Read: 749 MiB/s (785 MB/s)、748 IOPS

• Random 4K mixed read/write: それぞれ約9,400 IOPS、方向ごとに約36.7 MiB/sのスループット

シーケンシャル速度は、一度きりの大きな処理、たとえばデータベースバックアップの復元、アップロードされたアーカイブの展開、大きなログファイルの書き込みなどで重要です。

およそ740〜750 MiB/秒が両方向で出ており、読み書きの差も2％以内に収まっているので、このディスクには、読み取りは速いのに書き込みが大きく遅れるような、一部のクラウドストレージで見られる片寄った弱点はありません。

ランダム4K性能は、Laravelアプリが日常的にどれだけ快適に感じるかを実際に予測する指標です。データベースは大きな連続ブロックで読み書きするのではなく、行の検索、インデックス更新、トランザクションログへの書き込みのために、ディスク上の小さく散らばったブロックを読み書きします。

片方向あたり9,000を少し超えるIOPSは、ディスクI/Oが制限要因になる前に、1秒あたりおよそ9,000件の小さなデータベース操作を処理できることを意味します。

典型的なLaravelのページ読み込みでは、アプリの設計次第で数件から数十件のクエリが発生することがあります。つまり、このディスクには、クエリがディスクアクセス待ちで詰まり始める前に、かなり多くの同時ユーザーをさばく余地があります。

この上限に本気で到達するには、高頻度ログ記録、繁忙なキュー用テーブル、ディスクへの頻繁なキャッシュ書き込みなど、かなり書き込み重視のワークロードが必要です。

4. ネットワーク速度

• Run 1: Download 990.06 Mbps, Upload 910.87 Mbps, idle latency 0.31ms, 0% packet loss

• Run 2: Download 985.24 Mbps, Upload 947.82 Mbps, idle latency 0.27ms, 0% packet loss

両方のテストは、チェックアウト時に選んだ米国ロケーションに一致するフェニックス、アリゾナ州のサーバーに対して実行され、どちらもほぼギガビットに近い双方向速度で、パケットロスは0%でした。

Laravelアプリにとってこの数値が最も重要になるのは2つの点です。1つはサーバーが訪問者に対してアセットやAPIレスポンスをどれだけ速く返せるか、もう1つはアプリが外部APIを呼び出したり他サービスからデータを取得したりする際に、その外向き通信がどれだけ早く完了するかです。

ほぼギガビットのスループットなら、通常のウェブアプリにとって帯域幅は制約になりません。制限要因がCPUやディスクではなくなるほど大量の大容量ファイル転送、動画、大きなダウンロード、一括エクスポートなどが必要になるでしょう。

2回の測定結果が数分差でほぼ同じだったことも、たまたま良い値が出ただけではないことを示しています。これは一度だけ跳ねた数値ではなく、この接続が安定して出す結果です。

5. ストレステスト

CPU、メモリ、ディスクのストレス負荷をそれぞれ180秒間実行し、短時間の急激な負荷ではなく継続負荷に対する耐性を確認しました:

• CPU stress, 2 workers: 540,042 bogo ops, 0 failures

• Memory stress, 2 workers: 24,335,966 bogo ops, 0 failures

• Disk stress, 2 workers: 2,655,058 bogo ops, 0 failures

ここで重要なのは個々のbogo opsの数値というより、何が起きなかったかです。

3分間ずつ、3つのテストを連続で実行しても、すべてのテストで失敗したワーカーも疑わしい指標もゼロだったため、CPU、メモリ、ディスクに同時圧力をかけてもサーバーはクラッシュせず、不安定な状態にスロットリングされることもなく、ベンチマーク自体が疑わしいと判断する結果を返すこともありませんでした。これは、この種のテストで現実のトラフィック急増を最もよく模した状態に近く、複数のリソースが同時に上限まで使われたときに何が起こるかを示す結果です。

パフォーマンスの総評

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

Hostinger を訪問する

使いやすさ

私はHostingerのLaravel VPSを、チェックアウトから実際の管理ツールを開くところまでテストしました。

その範囲には、プランとサーバーロケーションの選択、アカウント作成、支払い、そしてサーバー稼働後にLaravelデプロイをどうやって実際に管理するかを把握することが含まれていました。以下は、そのプロセスが実際にどうだったかであり、インターフェースがまったく予想外の場所へ私を連れて行った瞬間も含まれます。

1. 登録

私はLaravel VPSのランディングページから始めました。そこには、最初に覚えておくべき3つの主張が掲げられています:

• 無料の自動週次バックアップ
• AI管理のVPS
• 自動マルウェアスキャナー

私はKVM 2プランを選びました。これは、リソースを大量に使う大規模構成ではなく、単一のLaravelアプリケーションにとって妥当な中間地点です。そしてカートに進みました。

そこからカートページには、すべてが1画面にまとまっていました:

• 課金期間: 1、12、24か月、各オプションの節約額を表示
• サーバーロケーション: 大陸ごとに地域を分類し、各地域にレイテンシ見積もりを表示
• アプリマーケットプレイス: 1,000以上のワンクリックOS、パネル、アプリの選択肢

私はより低い料金の24か月を選び、その後いつもより長くロケーション選択を見比べました。

一覧ではUnited Kingdomが最も良いレイテンシでしたが、他の地域も比較するためにスクロールしました。North AmericaではUnited Statesもかなり良好で、Asiaの最速候補であるMalaysiaはその両方よりかなり遅れていました。

私が想定していたサイトは主に米国の視聴者を対象にするため、理論上最速だったUnited KingdomではなくUnited Statesを選びました。

この点は、このページで地域を比較する読者にとって強調しておく価値があります。自分のノートPCの前で測った自分向けの最良レイテンシは重要ではありません。実際にそのサイトを訪れる人々に対するレイテンシが重要なので、自分ではなく対象ユーザーに基づいて選んでください。

次に、アプリケーションマーケットプレイスに進みました。そこではLaravelがすでに選択されており、Hostingerが全アプリカタログで使っているのと同じワンクリックセットアップ方式でした。変更する必要はなかったので、そのままチェックアウトに進みました。

私はすでに既存のHostingerアカウントにログインしていたので、登録自体は1クリックで終わりました。

その後の請求先住所と支払い画面では、以下が利用できました:

• カード、Visa、Mastercard、Amex、Discoverを含む
• PayPal
• Google Pay
• ChinaとHong Kongで別バージョンのAliPay
• 暗号資産決済用のCoingate

すべて1ページで完結し、別のリダイレクトはありませんでした。私は支払いを送信し、すぐに確認メールを受け取り、hPanelに戻ると新しいサーバーはすでに稼働中として一覧表示されていました。

ここで目立ったのは、Hostingerがチェックアウトで多くの選択肢を提供しながら、どれも必須にしていないことです。

特にロケーション比較は、そのまま流さずに真剣に受け止める価値があります。なぜなら、プランページの既定おすすめが、実際の利用者に最適とは限らないからです。

2. ダッシュボード/クライアントエリア

支払いが完了すると、hPanelはホーム画面を開きました。そこは、ドメイン、メール、サイトビルダー、VPS管理を1か所で扱う同じ中央アカウントパネルです。

そこでは私の名前で挨拶され、AIプロンプトバー、ショートカットボタンの列、To-doチェックリスト、そして下部にはアカウント上のすべてのWebサイトとサーバーの一覧が表示されていました。

次にVPSテーブルまでスクロールすると、新しいサーバーがすでにRunningと表示され、ホスト名、IPアドレス、プラン、有効期限が開かなくても見える状態で並んでいました。

私はManageをクリックしてサーバー専用パネルに移動しました。

支払い直後にアカウントホームページへ戻り、サーバーがすでにプロビジョニングされ一覧に出ている、この流れは一貫してうまく機能していました。

待機画面が別にあるわけでもなく、買ったものを見つけるためにメニューを掘り進む必要もありません。

3. Laravelとサーバー管理

ManageをクリックするとVPS Overviewページが開き、ここで本当の違いが見えてきます。

最上部にはLaravelとラベル付けされたアプリカードがあり、Manage Appボタンが表示されていて、Laravelがプロビジョニング中に自動でインストールされたことを示していました。

そのすぐ下には、予想していなかった2つ目のカードがありました:

• Ubuntu 24.04上に構築されたCloudpanel
• adminユーザー名が平文で表示される
• パスワードリセットリンク
• Laravelカードとは別の、独自のManage panelボタン

この2枚目のカードは見た目以上に重要です。CloudpanelはLaravelと並んで同梱された完全なサーバー管理パネルであり、実際の日常的なファイル、サイト、サーバー管理のための画面だったことがわかりました。

この2つのカードを過ぎて下にスクロールすると、その下にUbuntu 24.04インスタンスがあり、Runningと表示され、再起動とターミナルの操作、root SSH情報が他のVPSと同じように並んでいました。

このサーバーはちょうどプロビジョニングされたばかりだったので、リソースグラフはまだ埋まっておらず、hPanelは30分ほど後に使用状況データを確認するよう促していました。空のグラフを意味ありげに見せるのではなく、実際にはまだトラフィック履歴がないサーバーへの誠実な扱いです。

さらに下には以下がありました:

• SSHキー管理
• ファイアウォールルール
• バックアップスナップショット
• マルウェアスキャナー: 未インストール

最後の行が最初の本当のギャップです。マルウェアスキャナーはNot installedと表示されており、この製品のヘッドライン機能の1つとして同じページで自動マルウェアスキャナーを掲げているのに、実際に受け取ったサーバーでは有効になっていませんでした。

他のヘッドライン主張のほうはどうか気になったので、次にBackups & Monitoringを確認しました。Latest Actionsログには次の内容が表示されていました:

• 同じ日に記録されたrecreateアクション
• 1か月以上前まで遡る、Successと表示されたweekly backup_createエントリ

この主張はアカウント自身のログで確認でき、マルウェアスキャナーがすぐ隣のセクションで未有効化だったことと対照的でした。

Hostingerが自社の主張する機能の一部はデフォルトで提供し、他はユーザーが自分で有効化する必要があることは知っておく価値があります。そして、どれがどれかを見分けるには、自分で確認しに行くしかありません。プランページではそれらが同じように含まれているものとして扱われているからです。

それからLaravelアプリカードに戻ってManage Appをクリックし、CloudpanelのボタンのようにLaravel専用の設定やファイル管理画面が開くのだろうと思って試してみました。

ところが開いたのは「Let’s get started」というページで、Laravel公式ドキュメントやLaracastsの動画チュートリアルへのリンクがあり、その下にDeploy nowと書かれたボタンが1つあるだけでした。

私はそれでもクリックしてみましたが、飛んだ先はlaravel.com/cloud、つまりLaravel Cloudのサインアップページでした。

ここで明確にしておくべき違いがあります。

Laravel CloudはHostingerの製品ではありません 。また、私がちょうど支払ったVPSとは何の関係もありません。これはLaravelチーム自身が構築・販売している別の完全管理型ホスティングプラットフォームで、VercelやHerokuのようなサービスと同じ市場で競合しており、独自のアカウントシステム、独自の料金体系、独自の無料利用クレジットを持っています。

そこにサインアップするということは、すでにHostingerに支払った分とは別にLaravelへ支払い、アプリをまったく別の場所でホストすることを意味します。

なぜManage Appがそこへ向かうのかについては、この質問の際にKodee自身が参照した公式ナレッジベース記事How to use the Laravel VPS template at Hostingerを確認しました。その記事では、VPSのIPアドレス上のポート8443でCloudPanelにアクセスし、.env ファイルを編集し、SSH経由でComposerとArtisanコマンドを実行する手順が説明されています。

Manage Appボタンについては一切触れていませんし、Laravel Cloudについても一切触れていません。つまり、説明がどこか別の場所にあるのを私が見逃した、という話ではありません。

Hostinger自身のこのテンプレート向け公式ガイドでは、そのボタンの存在すら認めておらず、Kodeeも直接尋ねた際に、Manage AppはVPSを管理するものではなく、そこからLaravel Cloudにサインアップすると別の独立した請求が発生すると警告していました。

Manage Appをアプリ管理用だと思ってクリックした人は、事前の説明もなく、別の有料製品のサインアップページを見せられることになります。

実際にその先へ進むボタンは、1枚下のカードにあります。CloudpanelカードのManage panelです。

それをクリックするとユーザー名とパスワードを求めるログイン画面が開きます。ここは、画面上ではヒントが何もないので、正確に言っておく必要があります。

ユーザー名はadminで、パスワードはサーバーが最初にプロビジョニングされたときにHostingerがメールで送ってきたサーバーパスワードです。Hostingerアカウントのパスワードではありません。

そのメールがもう手元にない場合でも、Cloudpanelカードのパスワード欄の隣にあるResetリンクを使えば、受信箱を探し回ることなく新しいパスワードを生成できます。

ログインすると、CloudpanelはSites一覧を表示し、VPSのホスト名がすでにライブサイトとして設定され、アプリ種別はPHPになっていて、横にManageリンクが表示されています。

そのサイト設定を開くと、Settings、Vhost、Databases、Varnish Cache、SSL/TLS、Security、SSH/FTP、File Manager、Cron Jobs、Logsというタブがずらりと並んでいました。

これは本物の、かなり充実したコントロールパネルです。そして、Cron JobsタブがこのUI内にきちんと存在している点も強調する価値があります。Kodeeは、Artisanのscheduler用cronエントリをSSHで手動追加するよう案内しましたが、Cloudpanelにはターミナルを触らずに同じことを行うクリック操作の方法があり、Kodeeもナレッジベース記事もその選択肢には触れていませんでした。

これで表側は終わりです。サーバー管理ページ の左側メニューに、実際の管理機能が並んでいます。

提供されているのは次のとおりです:

• Overview: LaravelとCloudpanelのアプリカード、リソース使用状況、下にあるすべてへのクイックリンクを含む概要ページそのもの
• Settings: rootパスワードのリセットやホスト名変更などを含むサーバー全体の設定
• OS & Panel: オペレーティングシステムと、サーバーにインストールするコントロールパネルの管理
• Backups & Monitoring: Snapshots & Backups、Server Usage、Latest Actionsに展開され、週次バックアップログを確認したのもここです
• Security: マルウェアスキャナーとファイアウォール設定を扱うセクションで、スキャナーがオフになっていることを確認した場所です
• API: 外部からサーバー管理を自動化したい人向けに、HostingerのAPIドキュメントを新しいタブで開く
• DNS Manager: サーバーに紐づいたドメインとDNSレコードの管理
• Tutorials: Hostingerのヘルプコンテンツへの外部リンク

これだけ幅広く揃っていれば、VPS管理としては十分に完備していると言えます。サーバー設定、OS制御、セキュリティ、バックアップ、DNS、APIアクセスがすべて明確に別カテゴリとして存在し、包括的な設定メニューの中に埋もれていることはありませんでした。そして、この一覧の中で必要なものが欠けていることもありませんでした。

ただし、Laravel特有のツール、つまりコードのデプロイ、環境変数ファイルの管理、Artisanコマンドの実行といったものは組み込まれていません。そうした作業はCloudpanelかターミナルで行うものであり、このサイドバーでは扱われません。

続いて、Ubuntuカードにあるターミナルボタンです。その役割はサーバー本体へ直接コマンドラインでアクセスすることで、別のSSHクライアントを用意したり秘密鍵を自分のマシンへコピーしたりせずに、ブラウザ内でライブSSHセッションを開けます。

それをクリックすると、私はすぐにrootシェルに入り、すでに認証済みの状態で、Cloudpanelのウェルカムバナーが画面に表示されていました。そこにはCloudpanel自身のWebアドレスと、コマンドラインからパネルを管理するためのclpctlというCLIツールが示されていました。

ターミナル作業に慣れている人にとって、Laravelインストールの実際の設定、コードのデプロイ、環境変数の編集、マイグレーションの実行に最も早くたどり着ける手段です。なぜなら、hPanel内にはそれ専用のボタンがないからです。

使いやすさの総評

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

Hostinger を訪問する

サポートの質

Kodeeは、HostingerのAIアシスタントで、hPanelのAsk AIボタンの裏側にあり、Hostingerの他の製品と同じようにここでサポートを担当します。

私は、このVPSについて2つの別々の技術的な質問を試しました。1つはすでに遭遇したインターフェースの問題について、もう1つはこのサーバー上でLaravelが本番環境でどう動くかという、より深い内容についてです。

その後、Hostingerのナレッジベースを確認し、どの程度まで追加質問なしでカバーできるのかを見ました。

1. AIサポート（Kodee）

最初の質問は、LaravelアプリカードのManage Appボタンを試したときにそのまま出てきたものでした。そのボタンは、VPSに紐づく何かではなく、別の有料プラットフォームであるLaravel Cloudを開いていました。

私はKodeeに、そのボタンがLaravel Cloudを開くものなのか、それともすでにCloudpanel経由で動いているインストールを管理するものなのか、また、そこからLaravel Cloudにサインアップしたら実際に何が起こるのかを直接尋ねました。

Kodeeは1分以内に答えました:

• Manage Appは既存のVPSインストールを管理するものではないと確認した
• Laravel Cloud、つまり別のデプロイプラットフォームへのリンクであると正しく識別した
• VPSのIPアドレスの8443ポートでアクセスできるCloudpanelが、本当の管理画面であると示した
• Laravel Cloudにサインアップすると、私がすでに支払ったVPSには何もデプロイされず、別の独立した請求環境が作成されると警告した

これは、間違えると実際の費用がかかる質問に対して、明確で正しい答えです。そして、Hostinger自身のドキュメントへの引用も添えられており、推測ではありませんでした。

次は、もう少し技術的な重みのある質問をしました。Laravelアプリケーションは本番環境では、schedulerのためのcronエントリと、キューワーカーを動かし続けるためのSupervisorプロセスに依存します。このVPSテンプレートがそれらを自動設定するのか、また、自分で設定した場合にSupervisor自体が再起動後も生き残るのかを知りたかったのです。

Kodeeは回答前にサーバーを直接確認すると言い、そのとおりにしました:

• schedule:run のcronエントリが存在しないと報告した
• Supervisorサービスが構成されていないと報告した
• queue workerが設定されていないと報告した
• schedulerに必要な正確なcron行を提示した
• queue worker用の完全なSupervisor設定ブロックを、正しいフラグ付きで提示した
• systemctl enable –now supervisorで有効化すれば、Supervisorは再起動後も持続すると確認した
• デプロイ後にはphp artisan queue:restartを実行するよう注意を追加した。これは見落としやすく、忘れると実際の本番バグにつながる詳細です

AIサポートについての所感: Kodeeは、ここでは実際の回答で評価を勝ち取りました。提案する前に、その特定のサーバーでスケジューラーもSupervisorプロセスも動いていないことを確認したのは、チェックリスト的な返答と、このサーバーが実際に何をしているかに基づいた返答との違いです。そして、デプロイ後にキューワーカーを再起動するよう促したのは、Laravelのキューの本番での挙動を本当に理解していなければ出てこない種類の詳細です。

2つの質問、2つの正確で完全な答え、どちらも数分以内に返ってきました。

2. ナレッジベース

Hostingerのナレッジベースは、他の製品と同じように整理されています。大きなカテゴリタイル、記事数、上部の検索バー、カテゴリフィルターです。

私はブラウズする代わりに検索に直接進み、「laravel」と入力しました。すると15件の結果が2ページにわたって表示され、より狭いワンクリックアプリよりも明らかに多く出てきました。

ただし、ここには注意点があります。結果数が多いことと、関連性が高いことは同じではありません。いくつかの一致は周辺的な関連にすぎず、PHPメールの制限に関する記事やサイト移行の問題に関する記事は、Laravelに少し触れているというだけで表示されていました。

最も関連性が高い結果である「How to use the Laravel VPS template at Hostinger」は、Cloudpanelへのアクセス、Laravelのフォルダ構造の理解、.env ファイルの編集、Composerの実行、マイグレーションの実行を扱っています。

これは、このテンプレートでLaravelプロジェクトを立ち上げるための堅実な手順です。ただし、本番デプロイで重要になるスケジューラーやキューワーカーについてはまったく触れていません。そのギャップを埋める必要があったのが、まさにKodeeでした。

検索結果をさらに掘ると、重要なことがわかりました。古い記事「How to deploy Laravel 8 at Hostinger」にはスケジューラー用のcron例が含まれていますが、それは別の古い構成向けであり、現在のVPSテンプレートとは異なる、sharedやcloud hostingにLaravelを手動デプロイするためのものです。public_html のファイル構成も、CloudpanelがVPSを整理する方法とは何の関係もありません。

このVPSテンプレートを使っている人がスケジューラーの案内をナレッジベースで探すと、まず別の製品を説明した記事にたどり着き、本当に役立つ内容はその後になります。

ナレッジベースについての所感: 「laravel」で検索すると15件出るというのは紙の上では強く見えますが、件数の多さだけでは、実際に役立つ内容がどれだけ散らばっているかはわかりません。VPSテンプレートの中心的な記事はよく書かれており、最初のプロジェクトを動かすところまでは導いてくれますが、本番運用で本当に重要になる部分でちょうど止まってしまいます。そして、スケジューラーを扱う数少ないドキュメントは、まったく別の古いホスティング製品向けの記事です。

ナレッジベースだけを信じる読者は、その古いガイドに従って、完全に違うファイル構成向けのコマンドをコピーし、VPSを誤設定してしまうかもしれません。

サポートの総評

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

Hostinger を訪問する

HostingerのLaravelホスティングはおすすめか？

はい。基本は優れています。LaravelとCloudpanelはプリインストールされて正常に動作し、基盤となるハードウェアはCPU、メモリ、ディスクのベンチマークで良好な結果を出しました。Kodeeは、実際に試した2つの技術的質問に対して、正確でサーバー状態を踏まえた回答を返しました。週次バックアップも、主張どおりアカウントのログで確認できました。

気になる点は狭い範囲ですが、知っておくべきです。プランページで目玉機能として挙げられていたマルウェアスキャナーはデフォルトで有効ではなく、Laravelアプリの管理ボタンは、アプリ管理らしきものではなくLaravel Cloudという別の有料製品へ送ります。そして、そのことを事前に警告するドキュメントはどこにもありません。

Cloudpanelが実際の管理画面であるとわかれば、どちらも回避は難しくありませんが、そのために推測を強いられるべきではありません。

Laravelを素早く、しっかりしたインフラで動かしたい開発者で、誤ったボタンの隣にあるCloudpanelを見つけるのに5分かかっても気にならない人には、これは容易におすすめできます。起動した瞬間に、宣伝された機能がすべてゼロ確認で有効になっていてほしい人には、本格的に使う前に少し余分にセットアップ時間を見込んでください。

Hostinger

5.0

2,471 user reviews

￥250 /mo

最低価格

Hostinger を訪問する

Rating based on expert review

• 使いやすさ
  4.9
• サポート
  4.9
• 機能
  4.8
• 信頼性
  4.7
• 価格
  4.5