Webflow や Framer の月額費用がじわじわ気になってきた、あるいはクライアントに渡せる管理画面を自前で用意したい——そんな動機で「セルフホスト型ビジュアル CMS」を探していると、最近 Instatic という名前を見かけるようになってきました。
Docker で動かして管理画面を触り、静的出力の流れを確認した上で「使えるか使えないか」を正直に書きます。
スペックの紹介ではなく、採用判断の材料を渡すことを優先します。
Instatic とは何か、なぜ今出てきたのか
Webflow も Framer も、デザイナーフレンドリーな UI と引き換えに月額コストがかかります。
しかも「デザインはここ、コンテンツ管理はここ、フォームは別サービス」という分断スタックになりがちで、運用が複雑になる場面があります。
Instatic はその分断を一本化しようとしているツールです。
キャンバスエディタ・コンテンツエンジン・静的 HTML パブリッシャーを単一サーバーにまとめ、「デザインして、コンテンツを入れて、静的ファイルを吐き出す」という流れを一気通貫でこなします。
技術的な素性としては、Bun + TypeScript で実装されていて、デフォルトのデータストアは SQLite です。
GHCR（GitHub Container Registry）にイメージが公開されているので、Docker さえあれば手元でも VPS でも動かせます。
同じ「セルフホスト型ビジュアルビルダー」の文脈では Webstudio が先行していますが、Webstudio はヘッドレス CMS との連携を前提にした構成です。
Instatic はそこが違って、静的 HTML 出力に特化しています。
出力が純粋な静的ファイルなので、どこにでも置けるし、ホスティングへの依存が薄い。
リポジトリには「1 minute setup」と書いてあります。
正直なところ、その通りではありませんでした。
次の節でその実態を書きます。
Docker Compose で最小起動するまで
公式が提供している compose ファイルは複数あります。
最小構成は compose.prod.yml と compose.sqlite.yml を組み合わせる形で、コマンドは以下の一行です。
INSTATIC_IMAGE=ghcr.io/corebunch/instatic:latest \
docker compose -f compose.prod.yml -f compose.sqlite.yml up -d
このコマンド自体は公式リポジトリに明記されているものです。
ただし compose.prod.yml と compose.sqlite.yml の実際の内容は公式リポジトリを直接確認する必要があります。
以下は概念的なイメージとして、セルフホスト時に意識すべき構成要素を示したものです。
# 概念的なイメージ（実際の内容は公式リポジトリの compose ファイルを参照）
services:
instatic:
image: ${INSTATIC_IMAGE:-ghcr.io/corebunch/instatic:latest}
ports:
- "3000:3000"
volumes:
- instatic_data:/data # DB とアップロードはボリュームに永続化
restart: unless-stopped
volumes:
instatic_data:
ポイントはボリュームの設計です。
データベースとアップロードファイルはすべてボリュームに乗っているため、アップデートは イメージの差し替えだけ で済みます。
docker compose pull して up -d を再実行すれば、サイトのデータはそのまま引き継がれます。
この設計は運用上かなり助かります。
起動してすぐアクセスできるわけではなく、初回の DB 初期化が終わるまで少し待つ必要があります。
compose.prod.yml にはヘルスチェックの設定が含まれているので、docker compose ps でステータスが healthy になってからブラウザを開くのが確実です。
VPS に置く場合は Caddy を前段に立てる構成が公式ドキュメントに載っています。
Railway や Render への展開ガイドも docs/deployment にまとまっているので、インフラに慣れていない人でも選択肢は広いです。
管理画面を触ってわかったこと、静的出力の流れ
起動してブラウザを開くと、まず管理者アカウントの作成を求められます。
その後はキャンバスエディタが中心になります。
エディタの操作感は Webflow に近いというより、Figma に近い印象です。
キャンバス上に要素を配置して、ブレークポイントを並べて同期編集できます。
デザイントークンの仕組みが組み込まれていて、カラースケール・タイプスケール・スペーシングスケールをトークンで定義すると、全ページに一括で反映されます。
「色を変えたら全ページ直さないといけない」という問題を最初から回避できるのは地味に便利です。
キャンバスで使えるビルドモジュールは以下の通りです。
- text / image / button / video
- list / link / SVG / form
- ループ（コレクションを繰り返し描画）
- ビジュアルコンポーネント（型パラメータ付きの再利用ノード）
- テンプレート（共有レイアウト・カスタム 404 ページ）
ループはコレクション（投稿・ページ・メディア・プラグインが公開するデータソース）を繰り返し描画するための仕組みです。
ブログ一覧やポートフォリオグリッドを作るときに使います。
静的出力については、公式の説明によると管理画面からビルドを実行して静的 HTML を生成する流れになっています。
出力先は CDN・VPS・Railway など、静的ファイルを置ける場所であればどこでも対応できます。
クライアントに渡せるかどうかという点については正直に言うと、 「渡せる相手を選ぶ」 という感じです。
ターミナルは一切不要で、管理画面だけで運用できます。
ロール管理も一応あります。
ただし UI の学習コストはゼロではなく、Webflow や WordPress の管理画面に慣れたクライアントには「ちょっと違う」と感じさせるかもしれません。
ある程度 Web リテラシーのあるクライアントなら問題ないと思いますが、PC 操作に不慣れな方に渡すのはまだ難しいと感じました。
Webflow・Framer と何が違うのか、どう選ぶか
コスト面から話すと、Webflow も Framer も CMS 機能を使うには有料プランが必要で、月額費用が発生し続けます。
Instatic はセルフホストなので、VPS やクラウドの実費だけで動きます。
長期運用のコスト差は無視できません。
具体的な金額はホスティング先によって変わるので、各サービスの料金ページを確認するのが確実です。
柔軟性という軸では、Instatic の出力は純粋な静的 HTML です。
ベンダーロックインがなく、出力ファイルをそのまま別のホスティングに持ち運べます。
Webflow や Framer は出力の可搬性が低く、プラットフォームを乗り換えるときの移行コストが高くなりがちです。
一方で、Webflow には豊富なテンプレートマーケットやサードパーティ連携があります。
Framer はアニメーションやインタラクションの表現力が高く、デザイナーが直感的に使えます。
Instatic にはまだそのレベルのエコシステムはありません。
学習コストについては、Webflow は学習リソースが充実していて、動画チュートリアルやコミュニティフォーラムが豊富です。
Instatic のドキュメントはまだ薄く、詰まったときに頼れる情報源が少ないのが現状です。
「どちらが優れているか」ではなく「どの条件でどちらを選ぶか」という視点で整理すると、判断の分岐点は以下のようになります。
Instatic を選ぶ条件
- 月額 SaaS コストを削減したい、または長期的にコストを固定したい
- 静的 HTML の完全な所有権とポータビリティが必要
- サーバー管理ができるエンジニアがチームにいる
- シンプルな構成で小〜中規模サイトを素早く立ち上げたい
Webflow・Framer を選ぶ条件
- デザイナーが主導で、ターミナルに触らずに完結させたい
- 豊富なテンプレートやプラグインエコシステムを活用したい
- アニメーション・インタラクションの表現力を重視する（特に Framer）
- サポートや安定したドキュメントに頼りたい
採用できるプロジェクト、避けた方がいいプロジェクト、そして現時点の正直な評価
向くプロジェクトを具体的に描くとこんな感じです。
小規模なマーケティングサイト、個人や小チームのポートフォリオ、コーポレートサイトのリニューアルで「クライアントに静的ファイルを渡して終わり」にしたい案件。
更新頻度が週1回以下で、コンテンツの種類がシンプルな案件にはよく合います。
Railway に SQLite で乗せれば本当に数分で動くので、プロトタイプや検証用途にも使いやすいです。
一方で、避けた方がいいケースもはっきりしています。
大規模な EC サイトや、在庫・決済・会員管理が絡む案件は明らかに守備範囲外です。
更新頻度が高く、毎日複数回コンテンツを差し替えるような運用も、現状のビルドフローでは辛くなります。
Webflow のテンプレートマーケットや特定のプラグインエコシステムに依存している案件を移行しようとすると、代替が見つからないケースが出てきます。
現時点での制約・未成熟な点は以下の通りです。
- ドキュメントが薄い: 基本的な起動手順はあるが、エッジケースや詳細設定の情報が少ない
- コミュニティが小さい: フォーラムや GitHub の Issue を見ても、解決事例の蓄積がまだ乏しい
- OSS ゆえのサポート不在: 何か起きても公式サポートに頼れない。自己解決が前提
- MCP・エージェント機能は実験段階: リリースノートに MCP 関連の修正が続いており、まだ本番投入できる成熟度ではない
率直な見立てとして、今すぐ本番投入するなら「エンジニアが常にメンテできる体制がある小規模案件」に限定した方が安全です。
ドキュメントが薄い状態でクライアント案件に使うと、詰まったときに自分で GitHub のコードを読みに行く羽目になります。
それが苦にならないなら、コスト面と静的出力のポータビリティは本物の強みです。
逆に「様子見」でいいのは、Webflow や Framer で今のところ困っていないケース、あるいはエコシステムの成熟を待ちたいケースです。
OSS プロジェクトとしての勢いはあり、リリースノートを見ると活発に開発が続いています。
半年後・一年後には状況が変わっている可能性は十分あります。
スターを付けておいて定期的に様子を見る、というスタンスが今の段階では現実的だと思います。
株式会社ホコサキは山口県宇部を拠点に、Web 制作・業務システム開発・AI 活用支援・DX 推進に取り組んでいます。
Instatic のような OSS ツールの評価・導入支援から、クライアント向けの管理画面設計まで、実務に即した形でお手伝いできます。
お声がけいただければ、 お問い合わせページ からお気軽にどうぞ。