Astro + Lightsail で個人ブログを作る

なぜ自作か

個人サイトを作る理由は、「何者で・何を考えていて・何が作れるか」がひと目で分かる場所 が欲しかったからです。 「自分という人物のまとまり」をひとつのドメインに置きたい、というのが一番の動機でした。

採用したスタック

Astro による静的サイト生成 を AWS Lightsail に置き、Caddy で静的配信 + 自動 TLS としました。 完全静的なので DB も API もなし、デプロイは git push に寄せています。

• Astro — 静的サイト生成に特化したフレームワークです。コンポーネントは .astro ファイルで定義し、必要に応じて React/Vue などのフレームワークを混在させることができます
• MDX — Markdown に JSX を混ぜられるので、技術記事に小さな可視化やコード実行フレームを置けます
• AWS Lightsail — 月 $5 の固定費で動くので採用しました
• Caddy — Caddyfile 数行で TLS が立ちます。Nginx + Certbot で必要だった cron / certbot プラグイン管理 / reload 忘れの心配がなくなります
• GitHub Actions — push でビルドし、rsync で転送します

技術選定の判断軸

自作ブログを作るとなると「フレームワークどれにする?」「管理画面どうする?」「将来 DB 連動する?」と選択肢が膨らみます。 最初に決めたのは、スコープを削るルール でした。

管理画面は作らない

「将来管理画面が欲しくなるかも」と思って一度は Astro + Next.js のハイブリッド構成を検討しました。 ただ管理画面を用意するとなると、バックエンドを用意する必要が出てきたりなど、開発コストが大幅に上がることと、自分しか使わないブログに管理画面を用意するのは過剰設計な気がして、管理画面は作らないことにしました。 記事は Obsidian で書きます。Markdown を Git で管理すれば履歴も残ります。

このような理由から、Astro 単体で静的サイトを作成する ことに決めました。スコープを削った瞬間、構成も判断も一気にシンプルになりました。

Caddy vs Nginx

Web サーバーの選択は Caddy です。理由は 3 点です。

1. Caddyfile 数行で HTTPS が自動化される（cron も certbot もいらない）
2. 証明書の自動更新と reload がプロセス内で完結する
3. Nginx は副業 DevOps 案件で必ず触る機会がある。MVP は Caddy で時間を買う

Nginx を「いつか書き直す題材」として残しておく、という戦略でもあります。

構築の流れ

実際のセットアップは順序立てて進めました。重要だったところだけ抜粋します。

Lightsail インスタンス

AWS の新規アカウントを Paid plan で作成しました。 Lightsail で Ubuntu 24.04 LTS の $5/月プラン（512 MB RAM / 2 vCPU / 20 GB SSD / 1 TB Transfer）を選択しています。

静的 IP を割り当て、ファイアウォールで 22 / 80 / 443 を開けます。これだけで配信の入り口は揃います。

DNS は Cloudflare で集約

ドメインは Cloudflare Registrar で取得しました。原価販売（年 $10.44）、WHOIS privacy も無料で付きます。 DNS も同じ Cloudflare DNS に揃えれば、ドメイン取得 → ネームサーバー設定が省略できます。

A レコードを Lightsail の静的 IP に向けるだけで、数分で名前解決が走ります。 プロキシは MVP 段階では OFF（DNS only）にして、Caddy が直接 ACME チャレンジを受けられる構成にしています。

ビルドは GitHub Actions

サーバー上ではビルドしません。GitHub Actions の ubuntu-latest ランナーで npm ci && npm run build を走らせ、生成された静的ファイルを rsync で Lightsail に転送します。

コスト

動かすのに必要なものは限定的です。

• Lightsail $5/月
• Cloudflare Registrar 年 $10.44（原価販売）
• GitHub Actions（無料枠の中で完結）

月額にならすと $5〜$6 で済みます。

学びとこれから

ブログを立ち上げてみて思ったのは、「シンプルさが将来の選択肢を増やす」 ということでした。 次のフェーズで EC2 + Terraform に移行する道も、CDN 化する道も、両方残っています。 重い構成を最初から組むと、一見便利でも次の一手が見えにくくなる印象です。

普段は iOS エンジニアとして働いているので、今後は Apple 関連のテーマも書いていく予定です。直近では、6 月の WWDC 2026 で発表される注目 API のレビュー記事を書きたいと考えています。