Streamlit Community Cloud is one of the better free tiers in software: push a repo, get a URL, share a data app with anyone. For a demo, a portfolio piece, or an internal experiment, it is the correct answer and this post is unnecessary.
It stops being the correct answer at a specific and slightly brutal moment. Here is the detail that decides it, straight from Streamlit's docs: apps with no traffic for 12 hours go to sleep, and waking one requires a human to click a button on an interstitial page. Not an automatic wake on request - a person, looking at a "this app has gone to sleep" screen, choosing to press "Yes, get this app back up!". Anyone who can view the app can do it, which sounds fine until the person clicking is the client you sent the dashboard to, or a hiring manager opening your portfolio link on a Sunday.
That single behavior, plus the fact that the free tier allows exactly one private app at a time, is what moves people to hosting Streamlit themselves. Disclosure: Miget is our product and it appears below as one option among several, including free ones.
What Community Cloud actually gives you
Worth knowing precisely, because it is more generous than people assume on resources and stricter than people assume on everything else. Streamlit's published limits (the docs still date these figures to February 2024):
| Resource | Limit |
|---|---|
| CPU | 0.078 cores minimum, 2 cores maximum |
| Memory | 690 MB minimum, 2.7 GB maximum |
| Storage | up to 50 GB |
| Private apps | one at a time |
| Sleep | after 12 hours with no traffic, manual wake |
2.7 GB of RAM for free is a lot for a data app. Exceeding these limits does not produce a clean error either - Streamlit's docs say an over-limit app "may slow down from throttling or become nonfunctional," which is a rough failure mode to debug from the outside.
The official paid path is Snowflake, which owns Streamlit. That is the right call if your data already lives in Snowflake and the wrong one if this is a side project with a SQLite file.
When to keep using Community Cloud
- The app is public and you do not care if a visitor occasionally has to wake it.
- It is a demo, a teaching tool, or a portfolio piece.
- Your data is small and non-sensitive, and you have exactly zero or one thing to keep private.
- You want to spend zero minutes on infrastructure, which is a completely legitimate priority.
If all four are true, stop reading and go build something.
Hosting Streamlit yourself: the parts that trip people up
Streamlit is a normal Python web application, which makes it easy to host and easy to host slightly wrong. Three things account for most of the failures:
1. It uses WebSockets, so serverless is a poor fit. Streamlit maintains a persistent connection between browser and server for its reactive model. Platforms that scale to zero and charge per request fight this design: every cold start drops sessions, and a "request" is not the unit of work being done. You want a process that stays running, which is the same argument we made for hosting MCP servers.
2. The port is not 8501 on someone else's platform. Streamlit defaults to 8501; your host almost certainly expects something else. Pass it explicitly, and bind to all interfaces rather than localhost:
streamlit run app.py \
--server.port=5000 \
--server.address=:: \
--server.headless=true
On Miget, ingress reaches port 5000 and the network is dual-stack, so binding :: (which accepts IPv4 and IPv6) rather than 0.0.0.0 is the correct choice. --server.headless=true suppresses the first-run email prompt that otherwise hangs a container start - the single most common "my Streamlit deploy just sits there" cause.
3. State lives in memory unless you make it live somewhere else. Streamlit reruns your script on every interaction. Anything you want to survive a restart, a redeploy, or a second replica needs to be in a database or object storage, not in a global variable or a local file. This is not a hosting problem, but it becomes visible the moment you leave a single always-on instance.
Where to host it
Miget - a flat plan from $5/month for 512 MiB / 1 vCPU; the 1 GiB plan at $7 is the comfortable place for most Streamlit apps once you account for pandas. Deploy from a Git push (Python is auto-detected, no Dockerfile required), or bring your own Dockerfile. Postgres is included at $0 on the plan, which matters because most Streamlit apps eventually want somewhere to put data. No sleeping unless you choose the free tier, no per-request meter. Weakness: no free always-on tier - our free tier sleeps after 30 minutes, which is better than 12 hours plus a manual click but is still a sleep.
Hugging Face Spaces - free CPU Basic hardware with 2 vCPU and 16 GB RAM, built for public ML demos, and Streamlit is a first-class Space type. It sleeps on inactivity too, but if your app is a public demo this is the most free compute available anywhere. The constraint is structural: Spaces are shaped for public demos, one app per Space.
Render / Railway / Fly.io - all run Streamlit fine as a normal web service. Render from $7/month per service, Railway usage-billed at $20/vCPU/month (which for an always-on app means you are renting a warm machine by the second - see Railway alternatives), Fly from around $2.02/month per machine if you are comfortable operating more yourself.
A VPS with Docker - the floor. A $6 Hetzner box runs several Streamlit apps behind a reverse proxy, and you own the TLS certificates, the updates, and the uptime. Cheapest in money, most expensive in attention.
Snowflake - the official commercial path, and the right one when the data is already there.
Frequently asked questions
Is Streamlit Community Cloud really free?
Yes, genuinely free with no card, up to 2 cores and 2.7 GB of RAM per app. The costs are behavioral rather than financial: public apps by default with only one private app allowed, sleep after 12 hours of no traffic, and a wake that requires a human to click through an interstitial.
How do I stop my Streamlit app from sleeping?
On Community Cloud you cannot turn the sleep off. People work around it with uptime pingers, which is fragile and arguably against the spirit of a free tier. The real fix is hosting it somewhere that keeps a process running - any paid tier on any platform here does that.
Can I host a private Streamlit app for free?
One, on Community Cloud, at a time - deploying a second private app requires making the first public or deleting it. Beyond that you need paid hosting, and the cheapest predictable option is a small flat plan (from $5/month) or a VPS you already pay for.
Which port should Streamlit listen on?
8501 by default, but override it for your host: --server.port=5000 --server.address=:: --server.headless=true works on Miget and translates directly to any platform that injects a port. The --server.headless=true flag matters more than it looks - without it the first run tries to prompt for an email address and the container appears to hang.
Does Streamlit work on serverless platforms?
Poorly, and for a structural reason rather than a configuration one: Streamlit holds a WebSocket per session, so a platform that scales to zero or bills per request is fighting the framework's design. Use a platform that keeps a process warm.