VULKがフルスタックアプリの裏側に構築するもの:データベース、サインイン、APIを実環境で確認

2026年10月10日、VULKが現在実行しているコードと稼働中のエンドポイントに対して検証。

ストア、予約ツール、CRMのように物事を記憶しておく必要があるアプリをVULKに頼むと、VULKは画面だけで終わりません。その裏側に、プロジェクト専用のデータベース、アプリを使う人のためのサインインシステム、REST APIの3つを構築し、画面はこのAPIとやり取りします。3つともVULKのマネージドバックエンドapi-backend.vulk.dev上で動くので、サーバーやデータベース、認証プロバイダーを自分で用意する必要はありません。

この記事では、それぞれの部分が実際にどう動くのかを示します。以下の数字はすべて、次の3つのいずれかから得たものです。これらのアプリを生成・配信するコード(2026年10月10日に確認)、バックエンドの公開ヘルスエンドポイント、そしてVULKショーケースで公開されているストアへの実際のリクエストです。他社の製品に対して私たちが走らせたベンチマークは、ここには一つもありません。

VULKが書くフロントエンド

WebアプリはViteでビルドされるReactプロジェクトとして出力されます。バージョンは変動に任せず生成側で固定されているので、プレビューするプロジェクトとエクスポートするプロジェクトは同じものです。

アプリにデータが必要なとき、VULKはプロジェクトに型付きのクライアントファイルを追加します。画面がURLやトークンを手で組み立てることはありません。画面はそのクライアントを呼び出し、クライアントがバックエンドを呼び出します。

プロジェクトごとに1つのデータベース

バックエンドはすべてのプロジェクトに専用のPostgreSQLデータベースを割り当て、短いIDで識別します。IDはproj_に続けて、アプリを構築した会話の最初の16進数8文字を並べたものです。IDはどの編集を経ても変わらないので、変更を頼んでもアプリのデータはそのまま残ります。

バックエンドは、誰でも読めるヘルスエンドポイントを公開しています。2026年10月10日22:34 UTCの応答は次のとおりでした。

{
  "status": "ok",
  "service": "vulk-api-engine",
  "database": "connected",
  "projects": 1440
}

つまり、その時点でエンジン上には1,440のプロジェクトデータベースがプロビジョニングされていました。

生成されるテーブルの姿

VULKはアプリに必要なもの(商品、注文、予約)からテーブルを決め、独自の列を3つ追加します。

• id:テキストの主キー
• created_at:データベースが値を入れるタイムスタンプ
• user_id:各行がサインイン中の1人に属するテーブルに付く列

それ以外の列は、テキスト、数値、整数、真偽値、日時の5つの型のいずれかを取ります。テーブル名と列名には小文字、数字、アンダースコアを使い、先頭は文字で、長さは最大48文字です。APIはcamelCaseで応答するため、created_atは画面にcreatedAtとして届きます。

スキーマの変更は追加だけです。編集で新しいテーブルや列が必要になれば、バックエンドがそれを追加します。列の削除や型の変更が自動で行われることは決してありません。それこそがデータを消してしまう変更だからです。

REST APIをルートごとに

各テーブルには、プロジェクトのアドレスの下に同じルート一式が用意されます。

一覧は{ data, meta: { total, page, perPage, totalPages } }という1つのエンベロープで返ります。生成されるクライアントは1ページあたり100行を読み、1,000行で止まります。一括挿入は1,000行ずつのチャンクで送ります。各プロジェクトはクライアントのアドレスごとに毎分100リクエストを受け付け、バックエンドはすべてのレスポンスのX-RateLimit-Limit: 100ヘッダーでそれを示します。

誰が何を読み書きできるか

生成されたバックエンドが最もよく間違えるのがこの部分なので、正確に書いておく価値があります。アクセスポリシーが宣言されていないテーブルは閉じています。VULKはまず、アプリ全体に次の4つの形のいずれかを与えます。

• プライベートアカウント:各自がサインインし、自分の行だけを見ます。
• チームアカウント:チームが同じ行を扱い、メンバーは招待で参加します。
• 公開:アカウントは一切ありません。
• オーナーパネル:訪問者向けの部分に加えて、オーナーだけが開ける領域が1つあります。

次に、テーブルを1つずつ設定します。テーブルの読み取りは、公開、プロジェクトのAPIキー付き、サインイン中のユーザー、オーナーのみのいずれかにでき、書き込みには同じ選択肢に加えて、お問い合わせフォームなどのための「誰でも」があります。匿名の書き込みはアドレスごとに毎分20件が上限です。フィールドは、アプリの計画で別途指定されない限り非公開です。

稼働中のアプリでこのポリシーを見てみましょう。LUMAはショーケースにあるファッションストアで、このバックエンドのproj_266b7c3c上で動いています。2026年10月10日に、サインインせずに次のリクエストを送りました。

ショップは商品を見せる必要があるので、カタログは公開です。注文にはサインインした顧客が必要です。アカウントのテーブルは、そもそもテーブルとして公開されていません。

アプリを使う人のためのサインイン

フルスタックアプリにはそれぞれ、あなたのVULKアカウントとは別の、専用のユーザーアカウントがあります。生成されるクライアントは登録、サインイン、「自分は誰か」の確認、パスワードリセットに対応します。バックエンドには、トークンのリフレッシュ、サインアウト、パスワード変更のルートもあります。

• パスワードはPBKDF2-SHA256で、100,000回の反復と16バイトのランダムなソルトを使ってハッシュ化されます。
• セッションはブラウザに保持され、Bearerトークンとして送られます。401が返るとセッションは消去されるので、サーバーがすでに拒否したセッションをアプリが持ち続けることはありません。
• プロジェクトのオーナーが管理者で、登録した人は全員が一般ユーザーです。
• 登録は誰でもできるようにするか、招待制にできます。招待制では、1回だけ使えて7日で失効するコードを使います。

スタジオでは、各プロジェクトのダッシュボードにBackendタブがあり、概要、データベース、アプリのユーザー、API、そのシークレットを確認できます。

キーとシークレット

各プロジェクトには、vk_に64文字の16進数が続く形式のAPIキーが発行され、AES-256-GCMで暗号化して保存されます。公開されるバンドルにキーは含まれません。バックエンドのアドレスは読み込み時にページへ注入され、訪問者がオーナーとして振る舞えるようなものは一切ブラウザに送られません。サードパーティのAPIトークンなど、アプリが必要とするシークレットは書き込み専用です。設定や差し替えはできますが、誰も読み戻せません。サイズは1つあたり8 KBまでです。

公開と、コードの持ち出し

公開はワンクリックです。VULKはプレビューを動かしたのと同じ隔離されたマシンの中で本番版をビルドし、HTTPSで<name>.vulk.spaceから配信します。選んだ名前はあなたのものとして残ります。公開を取り消すとサイトはオフラインになり、アドレスはそのプロジェクトのために確保されたままです。バックエンドのアドレスはプレビューと公開ビルドの両方に組み込まれているので、公開したアプリはテストしたのと同じデータベースとやり取りします。

コードもあなたのものです。すべての有料プランで、プロジェクト全体をZIPでダウンロードするか、新しいGitHubリポジトリ(非公開または公開)にプッシュできます。GitHubへのエクスポートが強制プッシュすることはなく、1回のプッシュで最大1,000ファイル、8 MBまで扱えます。