Streamlit app deployment expensive on cloud run

Deployment
,
1

Hi everyone.
We have deployed streamlit app on google cloud run.
Streamlit version → 1.31
With 1 gb container, 1 vcpu and minimum to moderate traffic it’s costing us 1.5-2$ everyday.

Is there a way to deploy it on gcp with less cost?
We want application to be scalable for concurrent users.

2

I’m having the exact same problem. It’s because it’s constantly pinging the health check endpoints (/_stcore/health , /_stcore/host-config , and /_stcore/stream ). This makes streamlit absolutely useless for a lot of use cases with GCP, and no one seems to either know why it’s constantly keeping the container alive with those checks, or how to disable them. I see requests every 5 minutes or so in the logs, and I’m using version 1.32.

Note that my specific application is for testing purposes and has nearly 0 uses (which I can double check because the app makes api calls on another backend and that backend is absolutely dead) and it’s still costing me 2$ daily, and of course I have min instances set to 0 (which you should check as well, having the one instance running in idle would produce the 1-2$ daily charge as well)

3

I have setup the min instance as 0 as well.
Planning to migrate this to compute engine.

4

I’m experiencing the same issue.

I’ve deployed a Streamlit app on Google Cloud Run (using Streamlit version 1.37.0) and I’ve noticed that even when users leave the app open, the page keeps reconnecting due to the constant WebSocket pings.

Streamlit uses WebSockets for real-time updates and interactive user experiences. This results in unnecessary charges, which add up to around $1.5-2 per day with minimal usage. Additionally, because the connection is constantly maintained, the more inactive users or open browser tabs there are, the more the number of instances increases. This can lead to increased costs, degraded performance, and delayed scaling.

I’m curious if there’s any way to close the WebSocket connection when there’s no data update for a certain period. Alternatively, I’m interested in exploring other solutions. Has anyone found a solution to this?

5

I do not know for spesifically 1 cpu but if you consider multiple process and if you need non-blocking functions. You can read the blog post about scaling streamlit by redis queue. Background processes were very useful in my case, it works.

6

Running into the same issue! Has anyone resolved the bug that was re-introduced after 1.19?

7

It obviously depends on usage, but for reference for a dozen personal Streamlit apps deployed on Railway.com, I’m averaging $6/month with a standard deviation of ~$6 - so some costing as under $1/mon and the highest at $20/mon.

8

As of april 2025 I’m having this same issue, any solutions?

9

Also having same issues.

10

I was struggling with the same problem.

One thing I found is that if you run JavaScript’s alert() so a popup is showing in the user’s tab, the main thread gets blocked and the periodic calls to /host-config and /health stop (and Cloud Run scales the instance count down to 0).
It’s definitely intrusive, but by periodically showing alert("Are you still using this app?"), you can keep Cloud Run costs almost at zero even when users leave a browser tab open.
Since I’m building a small internal app, this was acceptable for me.

The code looks like this:

import streamlit.components.v1 as components
components.html(
    """
    <script>
    (function () {
      const ctx = window.top || window;           // Prefer the top window so the alert blocks the main tab
      if (ctx.__sessionTimeoutStarted) return;    // Guard against multiple initializations
      ctx.__sessionTimeoutStarted = true;

      const PERIOD = 15 * 60 * 1000; // 15 minutes

      function scheduleNext() {
        ctx.__sessionTimeoutTimer = ctx.setTimeout(() => {
          try { ctx.alert("Are you still using this app?"); }
          finally {
            // Schedule the next run only after the alert is dismissed (ensures at most one pending timer)
            scheduleNext();
          }
        }, PERIOD);
      }

      // Kick off the first run
      scheduleNext();
    })();
    </script>
    """,
    height=0,
)
11

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.