Databricks apps

[anmolhhns]

I have multiple Databricks Apps running, but their usage is not fixed or predictable. Some apps are used only occasionally, while others may remain idle for long periods.

Since Databricks Apps need to stay up and continue consuming resources even when there is no active usage, I wanted to understand the recommended approach for cost optimization.

Is there any supported way to automatically stop or scale down Databricks Apps when they are idle and start them again when needed, similar to how serverless compute can scale based on usage?If automatic idle shutdown is not currently supported, is there a recommended pattern to schedule app start/stop using Databricks Jobs, APIs, CLI, or any platform-native automation?

[Ashwin_DSA]

Hi @anmolhhns,

I couldn't find any public documentation showing that Databricks Apps supports automatic idle shutdown or usage-based scale-to-zero for the app runtime itself. The current documented lifecycle is that an app can be Running, Stopped, Deploying, or Crashed, and Databricks explicitly states that apps are billed while running, while a stopped app is not accessible and does not incur cost. The same documentation also notes that a stopped app keeps its configuration and environment, so it can be started again without reconfiguration.

In my view, the cost optimisation for intermittently used apps can be handled through explicit lifecycle control rather than demand-based autoscaling. The supported control surface is the Databricks CLI apps command group, which includes databricks apps start to start the last active deployment and databricks apps stop to stop the active deployment.

something like the below..

databricks apps stop my-app
databricks apps start my-app

If your goal is to reduce spend for apps that are only needed during certain windows, the most reasonable pattern is to schedule start and stop actions using a Databricks Job, an external scheduler, or CI automation that calls the CLI or the equivalent workspace APIs. In other words, this is currently more of a scheduled operational pattern than a serverless-style idle policy. It is also worth noting that features such as horizontal scaling for Databricks Apps are about availability and concurrency, not idle suspension, and if you need true scale-to-zero semantics, that capability is documented for Lakebase compute rather than for the Databricks App runtime itself.

One final caveat is that app restarts do not preserve in-memory state, so anything that needs to survive a stop/start cycle should be stored outside the app process, as described in Key concepts in Databricks Apps.

Hope this helps.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.