「業務システムを作りたいが、サーバ代は月500円くらいに抑えたい」。中小企業の方からこの相談を受けることが増えました。WordPressが動いているレンタルサーバがあるのだから、そこにシステムも置けないか、という発想です。

結論から言うと、さくらのレンタルサーバ（スタンダード）で Laravel 13 は動きます。ただし、共用サーバ特有の制約が4つあり、それを知らずに進めると途中で止まります。

この記事は、2026年9月に私が実際に契約して（14日間の無料お試し）、Laravel 13.30.1 を PHP 8.3.32 で動かすまでを検証した記録です。Web上には同じテーマの記事がほとんどなく、あっても古い情報が混ざっていたため、手を動かして確かめた事実だけを書きます。

なぜ「レンタルサーバでLaravel」の情報が少ないのか

理由は単純で、Laravel を使う開発者の多くは VPS やクラウドを使うからです。自由度が高く、情報も揃っています。

一方で、月額固定のレンタルサーバには別の価値があります。何をどう間違えても請求がそれ以上にならないことです。従量課金のクラウドは、設定ミスに気づくのが月末の請求書ということが起きます。小さな組織で最初に置くなら、私はレンタルサーバから始めることを勧めています。

ただしレンタルサーバは共用環境なので、Laravel が前提にしている「サーバの中身を自由に触れる」状態ではありません。そこにいくつかの罠があります。

置き場所の選択肢を公平に比べる

選択肢	月額のめやす	向いている場面	注意点
レンタルサーバ（さくら スタンダード）	500〜660円	小規模な業務システム、まず動かして試す	共用環境の制約がある（本記事）
VPS（さくらのVPS等）	1,000円前後〜	自由に構成したい、常駐処理が要る	OSの管理と保守を自分で行う
クラウド（AWS等）	従量課金	負荷変動が大きい、拡張前提	請求額が読みにくい。初学者には勧めにくい

弊社の標準構成はAlmaLinux上のLaravelで、案件では VPS を使うことが大半です。それでも「最初の一歩」や「社内向けの小さな道具」であれば、レンタルサーバは十分に現実的な選択肢です。

実機で確認した手順

以下はすべて 2026年9月時点、さくらのレンタルサーバ スタンダード、FreeBSD 13.0、Apache 2.4 の環境で確認しました。

1. プランは「スタンダード」以上を選ぶ

いちばん安いライトプランは SSH が使えません。Laravel の設置には SSH が必須なので、スタンダード以上が条件です。無料お試し期間中でも SSH の鍵は生成でき、データベースも作れます。

2. PHP を 8.3 以上にする

コントロールパネルの「スクリプト設定 → 言語バージョン設定」で、PHP を 8.3（推奨と表示されます）に変更します。モードはモジュール版のままで構いません。契約直後は 8.2 が選ばれていることがあり、そのままだと Laravel 13 の要件を満たしません。

3. SSH で接続したら、まず bash と打つ

接続直後のシェルは csh です。世の中の手順書はほぼ bash 前提なので、まず bash と1語打って切り替えます。

ログインシェルそのものを変える chsh は、共用サーバでは権限がなく Permission denied になります。これは仕様で、公式にも「ログインシェルは csh、ログイン後は bash への変更可」と書かれています。毎回 bash と打つのが正解です。

4. Composer は自分で入れる

Composer は最初から入っていません。公式の手順で取得し、~/bin/composer に置きます。~/bin は既定でパスが通っているので、置くだけで composer -V が使えます。

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php
php -r "unlink('composer-setup.php');"
mkdir -p ~/bin
mv composer.phar ~/bin/composer

5. composer create-project はサーバ上で通る

共用サーバではメモリ不足で落ちるという情報もありますが、実際には composer create-project laravel/laravel myapp が最後まで通り、Laravel Framework 13.30.1 が入りました。

6. 置き場所が最大の落とし穴

Laravel は public フォルダの中だけを公開し、その外側にある .env（データベースのパスワードが入っています）を絶対に見せてはいけない構造です。

ところが、さくらの Web公開フォルダは /home/アカウント名/www/ 以下しか指定できません（公式マニュアルに明記）。Laravel 一式を www の中に置くと、初期ドメイン経由で .env が読めてしまいます。

安全な構成は、本体を www の外に置き、public へのシンボリックリンクだけを www の中に作る方法です。

/home/アカウント名/
├── www/
│   └── myapp          ← シンボリックリンク（laravel-project/myapp/public を指す）
└── laravel-project/
    └── myapp/         ← 本体。www の外なので外部から見えない
        └── .env

ln -s ~/laravel-project/myapp/public ~/www/myapp

これで https://アカウント名.sakura.ne.jp/myapp/ で Laravel の画面が出ます。

7. ルートURLで出すには、無料サブドメインを使う

初期ドメイン（アカウント名.sakura.ne.jp）だけは Web公開フォルダを変更できません。ルートURLで表示したい場合は、さくらが提供する無料のサブドメイン（60種類から選べ、2個まで）を追加し、その Web公開フォルダに /myapp を指定します。SSL（https）も使えます。

つまり、独自ドメインを買わなくても、https のルートURLで公開できます。

8. データベースの接続先は localhost ではない

さくらではデータベースが別サーバに置かれています。.env の DB_HOST には xxx.db.sakura.ne.jp という形式の名前を指定します（コントロールパネルのデータベース画面に表示されます）。データベース名にはアカウント名の接頭辞が自動で付く点も、初めてだと戸惑います。

9. npm run build はサーバ上で落ちる

画面の見た目を組み立てる npm run build をサーバ上で実行すると、メモリ上限に当たって Killed で止まります。nice -n 20 npm run build と優先度を下げれば通る場合がありますが、手元のパソコンで組み立てて結果を転送するのが確実です。

10. CRON は控えめに

コントロールパネルの CRON 設定には「上級者向け」「実行頻度が1時間以内に連続する場合は予告なく設定解除されることがある」と明記されています。Laravel の標準は毎分実行ですが、共用サーバでは頻度を落として使うべきです。

公開前に必ずやること

• .env の APP_ENV=production、APP_DEBUG=false。デバッグ表示のまま公開すると内部情報が漏れます
• .env が www の外にあることを、ブラウザで /.env にアクセスして確認する

私が実際に踏んだ間違い

検証を始める前、私は「さくらは管理画面で公開フォルダを直接指定できるから、シンボリックリンクは要らない」と考えていました。これは誤りでした。公開フォルダは www 以下に限定されるため、結局シンボリックリンクが要ります。

日立グループで30年、いまは受託開発をしていますが、共用サーバの制約は実機で触らないと分かりません。手順書を書く前に必ず動かす、という基本を改めて確認した検証でした。

弊社の標準構成との関係

弊社が案件で使う標準構成は AlmaLinux＋MariaDB＋Laravel＋Vue.js で、サーバは VPS が中心です。Laravel を選ぶ理由はそちらの記事に書きました。

レンタルサーバは「まず動かす」「小さく始める」段階で有効です。本格運用で常駐処理や高頻度の定期処理が必要になったときは、VPS への移行をお手伝いしています。

まとめ

• さくらのレンタルサーバ スタンダードで Laravel 13 は動く（PHP 8.3、実機確認済み）
• 本体は www の外、public へのシンボリックリンクだけを www に置く
• ルートURLと https は無料サブドメインで足りる。独自ドメイン不要
• bash に切り替える、Composer を入れる、DB_HOST は専用ホスト名、ビルドは手元で

---