Reliable approach for scaling Databricks Apps down and starting them on demand

[aswinkks]

Hi everyone,

I'm exploring ways to reduce compute costs for Databricks Apps during non-business hours.

I understand we can use Databricks Jobs to stop Apps on a schedule, but I'm confused about the on-demand part: If the App is stopped and a user tries to access its URL, how can we automatically start the App and then show the normal App UI?

I've seen a few approaches mentioned:

- Model Serving with "scale_to_zero"
- Ingress / reverse proxy
- Azure Functions / Container Apps
- Databricks Apps Start/Stop APIs

I'm looking for approaches that are actually working reliably, preferably Databricks-native.

Also, if we put something like Azure Application Gateway/Ingress in front:

- How is Databricks authentication/session information passed to the App?
- Can users access it through a custom URL such as "apps.company.com/team-a/my-app" while still seeing the normal Databricks App UI?
- Does Databricks officially support this kind of setup?

The desired flow is simply:

Scheduled stop → User accesses URL → App automatically starts → User sees the App UI.

Would appreciate any real-world implementations or recommended architecture.

I just need a workaround for now

[ivanvyd · Accepted solution]

@aswinkks there's actually a new native option worth looking at: Serverless Micro Apps, currently in Beta, can scale to zero when idle and automatically start again when a user opens the app.

The limitation is that, during Beta, this only applies to apps created with Genie App Builder inside an App Space; existing standard Databricks Apps can't be converted yet.

For an existing standard app, your original constraint still applies: once it is explicitly stopped, it is inaccessible, so something external would need to call the Start API before the user can reach it.

[balajij8]

@aswinkks 

Native start on first use is not available on Databricks Apps unlike SQL warehouses. A stopped app is entirely inaccessible and incurs no costs. Unlike few other services that has native scale to zero capabilities, Databricks Apps operate in different states. Also, there is no intermediate routing layer that catches a request, triggers a start, and serves a warming up page. If a user hits the URL of a stopped app, the request fails.

If you are planning to put an external reverse proxy like Azure Application Gateway in front of the app to intercept requests and handle the cold starts, note that its not recommended. Databricks performs strict host header validation and will block requests originating from non Databricks domains. The OAuth flow happens entirely at the Databricks platform layer. The user's session is validated against the control plane before traffic reaches the app, with their identity then forwarded down via the forwarded access token header. Because of it, mapping a custom URL may work natively. While you can configure a proxy to forcefully rewrite the Host header to the actual databricks apps domain, that setup is fragile and unsupported. Also it does not solve the core problem - the app still has to transition back to RUNNING to serve the traffic and it takes time.

You can use Databricks native approach - use two scheduled Lake flow Jobs. Use the apps API to trigger a stop at the end of business hours (eg 8 PM) and a start right before users arrive (eg 7 AM). For a Medium app running at 0.5 DBU, it effectively cuts the compute costs in half with zero additional infrastructure. If unpredictable after-hours access is a requirement, you will have to accept the base running cost or evaluate if the workload can be ported to other services (eg Lakebase / SQL warehouse) scale to zero is supported. More details here