mason: expose app instance count and sticky routing

[shivam5]

Summary

• add optional --instances to mason deploy for a fixed instance count
• map it to equal compute_min_instances and compute_max_instances values required by the Apps API
• support both new deployments and updates to existing deployments
• document sticky routing and __Host-databricks-app-router in mason deploy --help
• keep the default README deployment flow unchanged and simple

Demo

export PROFILE=<profile>
export BRIDGE=/home/shivam.mittal/databricks-ai-bridge-worktrees/mason-routing-autoscaling

rm -rf ~/horizontal-scaling
uv tool install --force --with 'mlflow[databricks]>=3.10.1' \
  --editable "$BRIDGE/integrations/mason"
mason login -p "$PROFILE"

mason init ~/horizontal-scaling
cd ~/horizontal-scaling
mason dev

Stop the local server, then create one instance and update the same deployment to two:

mason deploy horizontal-scaling --instances 1
mason deploy horizontal-scaling --instances 2

For the sticky-routing API demo, use a workspace-scoped OAuth profile:

export APP_AUTH_PROFILE=<workspace-oauth-profile>
export APP_URL=$(databricks apps get mason-horizontal-scaling -p "$PROFILE" -o json | jq -r .url)
export TOKEN=$(databricks auth token "$APP_AUTH_PROFILE" | jq -r .access_token)
export ROUTING_KEY=$(uuidgen)

for i in 1 2 3 4 5; do
  curl -fsS "$APP_URL/api/demo/config" \
    -H "Authorization: Bearer $TOKEN" \
    -b "__Host-databricks-app-router=$ROUTING_KEY" |
    jq '{session_id, instance_id}'
done

The same routing key should return the same session and process instance on every request.

Testing

• uv run pytest -q — 306 passed
• uv run ruff check
• uv run ruff format --check
• uv run ty check
• fresh generated LangGraph project — 26 passed, 1 skipped
• local cookie test — repeated requests returned the same non-null session_id and instance_id
• live e2-dogfood test on September 4, 2026:
  • deployed with --instances 1
  • updated the same deployment with --instances 2
  • verified both API bounds were 2, active_instances=2, compute_status=ACTIVE, and app_status=RUNNING
  • cleaned up the temporary app and workspace source
• the existing e2-dogfood account-routed OAuth token returned HTTP 401 for the App API; use a workspace-scoped OAuth profile for the curl demo above

[elainewang-db]

were you able to test this live and deploy updates the apps scaling properly? my claude hit some issues with this, not sure if it was an apps side blocker or my own setup