Zeaburを使ってみた感想とレビュー
2026/08/30 更新
この記事を書いたあと、Zeabur には大きな変更がありました。
- クラスタの共有が終了し、料金体系も変わりました。新しいプロジェクトを作るときにプロバイダを選んでマシンを借りる方式になり、月額はおよそ USD $10 からです。アリババクラウドやテンセントなど安い選択肢もありますが、台湾のユーザーにとっては提供元の背景を考えると優先しにくい選択肢です。
- 08/29 に環境変数の流出が発生しました。Zeabur に設定した環境変数が攻撃者にアクセスされるリスクがありました。
以上の理由から、現在は Zeabur をおすすめしません。Railway を検討してください。
ちょっとした話
不思議な縁と言うべきか、先日Zeaburの創業者が福岡にやってきた。ちょうどその頃、僕は積極的に人と話したりご飯を食べたりしたいと思っていて、ふとした思いをTwitter(X)に投稿したところ、アルゴリズムのおかげで彼が福岡にいるというツイートが目に留まり、何気なくフォローした。するとZeaburの創業者から僕のツイートにリプライがあり、翌日には直接会うことになった。
創業者は情報工学部を卒業したばかりの台湾人で、僕たちは福岡名物の一つである水炊きを食べに行った。当日はYuanlinとたくさん話し、さまざまな意見を交わして、とても楽しい時間を過ごせた。
彼は人とコミュニケーションをとることにとても慣れているのが伝わってきたし、初対面にもかかわらずかなり深く率直な意見交換ができた。当時、僕は日本のスタートアップを手伝っていたのだが、彼に現状の課題を伝えると、どのような協業ができるかや割引プランの提案までしてくれた。
「まず自分に何ができるか」を考える姿勢は僕にとって非常に魅力的で、たとえ少し損をしたとしても自分も目指したいと思っているあり方の一つだ。
Zeabur — ワンクリックでサービスをデプロイ
本題に戻ろう。
ちょっとしたプロダクトをデプロイするのが好きな開発者にとって、どのプラットフォームを選ぶかは大きな問題だ。その理由の一つは、開発者が普段求めているのはゼロからマシンを立ち上げて設定することではなく、素早くリリースできる「Out of the Box(手軽にすぐ使える)」なデプロイフローだからだ。
ここ数年で、僕はいろいろなデプロイツールやクラウドプロバイダーを使ってきた:
- AWS: EC2やServerless Functionなどを含む
- GCP: App Engine、Cloud Run、Storage、Database
- Vercel
- Netlify
- Cloudflare
- DigitalOcean
- Railway
そのため、開発者がどんなサービスを求めているかは大体把握しているつもりだ。
今回は主にZeaburを紹介したい。他のプロバイダーの使用感については、また追々シェアしていくことにする。
僕自身の使用体験から言うと、一般的なクラウドホスティングプロバイダーにはいくつかの欠点がある:
1. コストが比較的高い
GCPでデータベースを1つ立ち上げるだけで、月2,000台湾ドル(約1万円)近くかかる。マネージドのメリットは高可用性、バックアップ、モニタリング、ロギング、アラートなどが備わっており、自分で構築する手間が大幅に省ける点にある。
しかし小規模なサービスにとっては、これらは妥協できるか、あるいはなくても困らないものだ。資金が限られているスタートアップや個人開発者にとって、「どれだけ節約できるか」こそが正義なのだ。
僕個人の考えとしては、サービスに特別な要件(高トラフィック、並行処理など)がない限り、サーバーマシンは思っているほど脆弱ではない。
2. サービス間の連携関係がわかりにくい
例えば、プロジェクトがデータベース、Redis、Kafka、RabbitMQなどに接続する必要がある場合、AWSやGCPではプロジェクトページから直接見るのではなく、各サービス固有の管理画面を行き来して確認しなければならない。また、DigitalOceanのようなサービスはサーバーが提供されるだけで、残りはすべて自分で設定する必要があり、一目で把握できるUIが存在しない。
3. UIが比較的複雑
AWSやGCPが提供するサービスは多すぎる。大半の個人開発者が必要としているのはサーバーとデータベース、せいぜいMQ(メッセージキュー)程度だ。しかしGUIにはノイズが多すぎて、サーバーを起動したりログを確認したりするだけでもあちこちクリックしなければならず、迷子になることもしょっちゅうだ。
こう書くと、「大半のサービスは一元管理できる」と反論する人もいるかもしれない。確かにその通りで、自分でAPIを書いて管理画面を作ることもできるし、Terraformを書くこともできる。だが、それでは手軽さに欠け、すぐに使える(Out of the box)状態にはならない。
Railway
僕は2年前に同僚のおすすめでRailwayを使い始め、すっかり気に入って愛用するようになった。Railwayは安さと迅速なデプロイを売りにしており、実際にもほぼ設定なしでサービスを動かすことができる。
僕自身、気に入っている機能がいくつかある。例えばプロジェクト内でdev / staging / production環境を定義できたり、テンプレートやDockerからのデプロイに対応していたり、GitHub連携で新しいコミットがあるたびに自動デプロイしてくれる機能だ。これは僕にとって最も重要なことで、デプロイスクリプトを書くコストを丸ごと省き、より多くの時間をコーディングに充てることができる。
同じプロジェクト内で、データベース、GitHubのコード、Redisをデプロイでき、プロジェクトと外部の接続関係が一目でわかるようになっている。
その料金プランは開発者にとって非常に良心的で、5ドル支払えばHobbyプランにアップグレードできるが、使用量が5ドル未満なら請求されない。つまり、使用量が5ドル未満であれば実質無料と捉えることができる。
僕のブログのデータベースは現在Railwayを使っていて、月額およそ3ドル程度で済んでいる。メインのコードはVercelに置いてある。やはり今のところNext.jsの統合が最も優れているのはVercelだし、Serverless Functionも無料で使えるため、ブログ用途としては非常に便利だ。トラフィックも無料枠よりはるかに少ない。
Zeabur の紹介
Railwayの手軽さを体験済みの開発者にとって、ワンクリックデプロイはもはや当たり前のものだろう。先ほど触れたカスタムテンプレートやDockerからのデプロイ、GitHub連携によるコミットごとの自動再デプロイなど、これらはZeaburでもサポートされている。だが、Zeaburにはさらに際立った強みがあると僕は考えている。
料金について言えば、Railwayは無料枠を超えなければ無料で使えるものの、リージョンを選択できないという制約がある。通信速度の観点から見れば、物理的に近いサーバーの方がやはり速い。
一方Zeaburは月額5ドル(開発者プラン)で、5ドル分の無料クレジットが付与される。そのため、使用量が5ドルを超えなければ月額5ドルのままだ。
Railwayと比較した対照表がこちらだ:
| Railway | Zeabur | |
|---|---|---|
| Memory | $0.000231 / GB / minute $10 / GB / month | 4 / GB / month |
| vCPU | $0.000463 / vCPU / minute $20 / month | $0.0003 / vCPU / minute $12 / month |
| Network Egress | $0.1 / GB | $0.1 / GB (最初の 100GB 無料) |
| Volume | $0.2 / GB | $0.25 / GB |
見てわかる通り、料金面でZeaburはRailwayよりも優れている。Network Egress(送信トラフィック)の単価は同じだが、Zeaburは最初の100GBが無料枠に含まれている。使用量が5ドルを超える場合、Zeaburの方が圧倒的にお得な選択肢になる。
現在僕が動かしているサービスはブログやBot程度なので、Egressが上限を超える心配はほとんどない。しかし、ある程度のリアルタイム性が求められるサービスや、サーバー側での処理が集中するサービスの場合、Egressの使用量は重要な検討要素の一つであり、コントロールが難しい部分でもある。
Zeaburは毎月100GBの無料枠があるため、僕にとっては非常に大きなプラスポイントだ!さらにZeaburはプロジェクトごとの予算管理機能も提供しており、月間の上限額を設定しておくことで、超過時にサービスを自動停止して想定外の出費を防ぐことができる。
1. ユーザー体験
Zeaburでのサービス作成体験はとても快適だ。GUIを通じてデータベースを作成したり、構築済みのDockerイメージを使ったり、GitHubと連携したり、ローカルからファイルを直接ドラッグ&ドロップしたりできる。
Dockerイメージを構築した後は、管理画面から直接環境変数を追加できる。
2. コミュニティと事前構築されたテンプレート
Zeaburにはあらかじめ構築されたテンプレートが豊富に用意されている。例えばWordPressを使う際、データベースも一緒にセットアップしたいと思うことが多いが、そんな時はZeaburのテンプレート機能が便利だ。用意されたテンプレートの種類は充実しており、もちろん自分でテンプレートを作成することもできる。
テンプレートの実体はYAMLファイルで、特殊なフォーマットを覚える必要もない。
3. ネイティブな言語サポート
開発者が台湾人ということもあり、公式サイトや管理画面は自然な繁体字中国語に対応している。Discordに参加すれば、中国語でチケットを作成して直接やり取りすることも可能だ。
英語圏のエコシステムに慣れている開発者にとっては大きな違いではないかもしれないが、母国語で直接サポートとやり取りできる安心感はやはり別格だ!
Discordでは、Zeaburの開発者たちがユーザーと積極的にコミュニケーションを取りながら不具合を修正している様子が見られる。Zeaburはまだ比較的新しいサービスだが、大半のケースでは問題なく動作するし、何かトラブルがあっても開発者に直接助けを求めることができる。「カスタマーサポート経由で開発者へ」というワンクッションがないのは、人によっては非常に大きなメリットだろう。
3. サーバーのクラウドプロバイダーを選択可能
Zeaburの開発者プランではAWSとHuawei Cloudのサーバーを選択できる。AWSの場合、香港、東京、カナダ、ドイツが選べ、TeamプランならGCPの台湾リージョンも選択可能だ。日本、台湾、中国市場をターゲットにする開発者にとっては非常に便利と言える。
4. 自前のサーバーを接続可能
Zeaburのドキュメントによると、内部ではk3sといくつかのモニタリングツールが使われているらしい。そのため理論上は、マシンさえあればZeaburを使って自前でデプロイの手間を省くことも可能だ。
つまりZeabur経由でサーバーを立てるだけでなく、自分で借りたサーバーにSSH設定を行い、Zeaburにサービスを構築してもらうこともできる。要するに、デプロイ周りの面倒なタスクをすべてZeaburに丸投げできるわけだ。
感想
Zeaburは既存のPaaSとある程度似通っている部分はあるものの、全体的な使用感としては非常に満足している。Web画面上のUIの細部や翻訳の不完全さなど気になる点はあるが、これらは重箱の隅をつつくような話で、時間が経てば改善されていくだろう。
それに加えて、Zeaburの価格設定はRailwayよりもかなり安く、個人開発者がMVP(最小限の実行可能製品)を構築するのに非常に適したプラットフォームだ。
自前のマシンを統合できる点やリージョンを選択できる点などからも、Zeaburが他とは違う独自の道を切り拓こうとしているのが伝わってくる。今後の発展がとても楽しみだし、僕も応援の意味を込めて今後のいくつかのプロジェクトをZeaburへ移行するつもりだ。
ブログを運用したい、あるいはデータベースやRedisを伴うサービスをデプロイしたいが、高額なマネージドサービスの費用は払いたくないという人は、ぜひZeaburを検討してみてほしい!なお、静的サイトやNext.jsであれば、僕としては依然としてVercelをおすすめする。
ちなみに、より高度な使い方をしたい開発者は、Cloudflareと組み合わせるのもおすすめだ。プロキシとキャッシュをCloudflareに任せることで、かなり快適な体験が得られるはずだ(Zeaburが直接サポートしてくれたら最高なのだが😂)。
関連記事
- 測定が目標になるとき:窓税からPull Request数まで かつて僕は小さなツールを自作し、四半期で自分がどれだけPRに貢献したか、レビューコメントをどれだけ残したか、チケットをどれだけ消化したかを集計して、上司にアウトプットを証明しようとしたことがある。上司は淡々と、評価はアウトプットだけで見るものではないと言った。数年後、僕はようやく理解した――測定が目標になるとき、それはもはや良い測定ではなくなるのだ。英国の窓税、ハノイのネズミ駆除の報奨金から、現代のPR数による開発者評価に至るまで、そのメカニズムはまったく同じだ。
- Cloudflare Images を画像ストレージ・変換ソリューションとして使う ウェブページに画像を1枚置くのはフロントエンドにとって最も簡単なことだが、リサイズや各種フォーマットの生成、さらにはトラフィックの負荷に耐えることまで完璧にやろうとすると、実際には一つの包括的なソリューションが必要になる。僕はその後、すべて Cloudflare Images に任せるようになり、オリジナル画像1枚だけを渡すようにしている。
- もう AWS Access Key を使うのはやめよう Access Key は AWS において見落とされがちなセキュリティリスクだ。OIDC と IAM Role を組み合わせることで、GitHub Actions にシークレットを一切保持させることなく、安全に AWS リソースを操作できるようにする。
- データベース主キー:AUTO_INCREMENT、UUID、そしてUUIDv7 バックエンド開発で度々直面する主キーの決定。auto incrementを使うべきか、それともUUIDか?衝突への懸念は?UUIDv7とcreated_at + インデックスの性能差はどれほどか?実際に2,000万件のデータで検証したベンチマークと設計上の意思決定を解説する。