Many Studios, One City

How one City can serve multiple studios without mixing studio differences with shared infrastructure.

When many studios share one City, the goal is not “save one server.” The goal is to separate shared infrastructure from studio-specific differences.

What should be shared:

provider env
model directory
service routing
hooks, usage, and logs
user_token verification

What should stay in each studio:

pages and interaction
the user system
plan, order, and balance rules
studio-specific brand, positioning, and pricing

One diagram for the reuse boundary

Studio AFor example, a web tool.studio_id = studio_web

Studio BFor example, a Chrome extension.studio_id = studio_extension

Studio CFor example, a client demo or internal tool.studio_id = studio_demo

One DowncityReuses the model directory, provider env, service logic, usage records, and hooks.

How to think about `studio_id`

studio_id is a studio boundary, not a model boundary.

It is useful for:

identifying which studio sent the call
deciding whether a studio is still active
telling hooks where usage should be recorded
separating one user’s activity across different studios

A common pattern is one stable studio_id per studio:

const studio = await admin.studios.create({
  name: "Chrome Extension",
});

const issued = await admin.studios.tokens.apply({
  studio_id: studio.studio_id,
  user_id: "user_123",
  metadata: {
    plan: "starter",
    channel: "extension",
  },
});