Chapter 5: Sharing your apps with the world

Introduction

This chapter introduces moving a Streamlit app from local development to public deployment, including hosting choices, external services, secrets, and dependencies.

• Deployment purpose and paths: Explain why deployment makes a locally developed app available to its intended users, and describe that the chapter briefly considers multiple sharing options before using one practical deployment path.
  Why it matters: Deployment is what turns an app on your own machine into something other people can use.
• Community Cloud deployment path: State that the chapter uses Streamlit Community Cloud as the practical path for deploying an app to production, where users can experience it, and that this deployment is presented as free.
  Why it matters: A concrete hosting path lets you take the completed app from local work to a live app users can visit.
• Production configuration concerns: Describe the chapter's production concerns: connecting an app to an external service such as an API, safeguarding confidential values such as API keys, and managing code dependencies.
  Why it matters: A deployed app must safely obtain what it needs to run without exposing sensitive information.

Key terms: deployment, local development, production, Streamlit Community Cloud, API, API keys, secrets, dependencies, requirements.txt

5.1 Deploying apps

This section introduces the need to share the functional Streamlit applications built so far so that other people can experience them.

• Need to share applications: Explain that the Streamlit applications built in the preceding chapters have so far not been experienced by other people, and that the chapter now turns to making them available to others.
  Why it matters: An app becomes useful beyond its creator when other people can access and experience it.

Key terms: Streamlit, applications

5.1.1 What is deployment?

This section defines deployment as hosting a Streamlit app so intended users can reach its continuously running server through an accessible URL.

• Deployment meaning: Explain deployment as making an app available to other people by hosting it somewhere intended users can readily access, rather than only running it locally.
  Why it matters: Deployment is what turns a locally developed Streamlit app into one that other people can use.
• Server access and connections: Describe how a Streamlit user reaches an app by navigating to the URL and port of its running server, causing the browser frontend to connect to that server and create an app instance. Explain that deployment keeps the server running for new connections at a URL other than localhost.
  Why it matters: Users can only load and use a deployed app while its Streamlit server is running and accessible at its URL.

Key terms: deployment, hosting, backend server, frontend, URL, port, localhost, connection

5.1.2 Options for deployment

This section compares local-network, dedicated-server, cloud-platform, and Streamlit Community Cloud deployment options by their reach, operational demands, benefits, and limits.

• Local-network deployment: Describe how running a Streamlit app on a computer connected to a Wi-Fi or LAN lets other devices on that same network open the app through its network URL. Explain that this is temporary, depends on network rules such as firewalls, and exposes the app only to the local network rather than the public internet.
  Why it matters: Local sharing is the quickest way to let nearby users try an app without setting up separate hosting.
• Dedicated server responsibilities: Explain that a dedicated-server deployment runs the app on a separate physical or virtual machine so it can be available continuously and outside the local network. Describe the setup and operational responsibilities, including installing Python and Streamlit, exposing the app port, configuring network access, and maintaining security and software.
  Why it matters: A dedicated server offers deployment control, but the security and maintenance burden can make it unsuitable for a simple public app.
• Cloud deployment tradeoffs: Explain that cloud deployment hosts an app on public-cloud infrastructure such as AWS, Azure, or Google Cloud instead of physical hardware you operate. Distinguish its scalability, availability, security, and reduced infrastructure-maintenance benefits from the potentially increasing resource-based cost as usage grows.
  Why it matters: Cloud platforms can make an app reliable and broadly accessible while shifting much of the infrastructure work to the provider.
• Community Cloud suitability: Describe Streamlit Community Cloud as Snowflake's free, Streamlit-specific publishing option and explain why it is suitable for learning and the deployments in this chapter. State that its compute, memory, and storage limits can require moving a popular or resource-heavy app to a paid cloud provider.
  Why it matters: Community Cloud is the chapter's practical deployment target, but knowing its resource limits helps you recognize when another host is needed.

Key terms: streamlit run, Streamlit server, local URL, network URL, local network, Wi-Fi, dedicated server, physical machine, virtual machine, port

5.2 Deploying the to-do list app to Streamlit Community Cloud

This section introduces deploying the chapter 4 to-do list app to free, Streamlit-specific Community Cloud so it is accessible on the internet.

• Community Cloud deployment purpose: Explain that this section deploys the earlier to-do list app to Streamlit Community Cloud so anyone with an internet connection can access it.
  Why it matters: Deployment turns a locally built Streamlit app into something other people can use online.
• Community Cloud suitability: Describe why Streamlit Community Cloud is presented as a good deployment choice: it is free, custom-built for Streamlit, and easy to use.
  Why it matters: These characteristics explain why Community Cloud is a practical starting point for sharing a Streamlit app.

Key terms: Streamlit Community Cloud, deployment, to-do list app

5.2.1 Prerequisites

This section prepares a developer to deploy on Streamlit Community Cloud by setting up GitHub access, a personal access token, and a connected Community Cloud account.

• Deployment account prerequisites: State the tools and accounts required before deploying an app to Streamlit Community Cloud: git, a GitHub account, a Streamlit Community Cloud account, and a connection between the GitHub and Community Cloud accounts.
  Why it matters: These prerequisites let Community Cloud access the repository containing the app to be deployed.
• Git and GitHub distinction: Distinguish git from GitHub, explaining that git is the distributed version-control system while GitHub is a web platform that hosts Git repositories, including repositories with files, directories, and revision history.
  Why it matters: Keeping the tool separate from the hosting platform makes the deployment setup and repository workflow clearer.
• Personal access token setup: Describe creating a GitHub personal access token for command-line authentication and pushing code: navigate to Personal Access Tokens and generate a classic token, select the Repo scope, add a purpose note and expiration, then copy and securely store the generated token.
  Why it matters: The token is the password alternative used to authenticate when pushing the app code to GitHub.
• Token expiration tradeoff: Explain the security tradeoff of a PAT expiration date: a shorter expiration reduces the time a compromised token remains valid, but requires more frequent token rotation; an expired token must be replaced.
  Why it matters: Choosing an expiration deliberately balances credential security against maintenance effort.
• Community Cloud account connection: Describe creating a Streamlit Community Cloud account by signing up at streamlit.io/cloud with the GitHub account, or separately connecting GitHub through Workspaces and Connect GitHub Account if the account was not created with GitHub credentials.
  Why it matters: Community Cloud needs an authorized GitHub connection to deploy apps from GitHub repositories.

Key terms: git, GitHub, Streamlit Community Cloud, GitHub account, Community Cloud account, Git repository, version control, revision history, personal access token, PAT

5.2.2 Deployment steps

This section deploys the chapter 4 to-do app by placing its code in GitHub and configuring Streamlit Community Cloud to run it.

• Three-step deployment workflow: Describe the three-step deployment workflow for the to-do list app: create a GitHub repository, push the local code to it, and tell Streamlit Community Cloud where to find and run that code.
  Why it matters: This is the basic path that makes a locally developed Streamlit app accessible on the internet.
• Git repository publication: Trace how the local to-do app is published to GitHub: initialize Git in the directory containing todo_list.py and task.py, stage and commit the files, add the GitHub repository as origin, and push the current branch upstream.
  Why it matters: Community Cloud needs the app code in the remote GitHub repository before it can deploy it.
• Community Cloud app configuration: Explain how to configure Community Cloud to deploy the app: create an app, provide the GitHub repository, the branch containing the code, and the app entry-point path todo_list.py, choose an app URL, and click Deploy.
  Why it matters: These settings tell Community Cloud exactly which version of which file it should execute for visitors.
• Community Cloud inactivity behavior: State that free Streamlit Community Cloud apps shut down after roughly 12 hours without access and may need time to wake up when someone next visits them.
  Why it matters: This explains why a deployed app may initially show a wake-up message instead of loading immediately.

Key terms: GitHub repository, Streamlit Community Cloud, deployment, git init, staging area, commit, remote, origin, personal access token, Create an App

5.3 Deploying an app that uses an external service

This introduction explains why real-world Streamlit apps commonly need third-party libraries and external APIs, and previews adding and deploying those dependencies in the to-do app.

• External application dependencies: Explain why practical applications often require third-party libraries or other software beyond Python and Streamlit, unlike the self-contained to-do list app deployed previously.
  Why it matters: Most useful apps build on software created by others, so deployment must account for more than the app's own code.
• External service APIs: Describe why an app connects to an external API and give examples of services it might obtain through one, such as dictionary validation, currency exchange rates, or news headlines.
  Why it matters: APIs let an app use useful internet-based capabilities and data that the app does not provide by itself.
• To-do app deployment extension: State that the section will add external-service and dependency complexity to the existing to-do list app and deploy the changed app correctly.
  Why it matters: The upcoming work applies deployment to a more realistic app rather than only a self-contained one.

Key terms: third-party libraries, Python, Streamlit, external service, application programming interface (API), API, to-do list app, Streamlit Community Cloud, deployment

5.3.1 A joke of the day to entertain users

This section motivates adding a daily joke to the to-do app and explains the API, HTTP, and Dad Jokes API details needed to obtain one from an external service.

• External-service API contracts: Explain what an API is in the context of an external service and how it differs from the backend API contract used inside the unit converter app. Describe why API documentation is the reliable source for learning a particular API's structure and requirements.
  Why it matters: External APIs let an app obtain capabilities and data, such as fresh jokes, without building and maintaining those services itself.
• HTTP request structure: Describe how an HTTP client sends a request to a server and receives a response. Distinguish GET requests, which put request information in the URL and normally have no body, from POST requests, which can send a body or payload.
  Why it matters: Understanding requests, URLs, parameters, headers, and responses makes it possible to connect a Streamlit app to web APIs.
• API URL and response conventions: Describe the common API request pattern of a base address plus an endpoint, with optional key-value parameters and headers. State that an API commonly returns a response in JSON that code can parse.
  Why it matters: These conventions help a developer identify the address, options, authentication information, and returned data involved in an API call.
• Dad Jokes API access: State how this example accesses the API Ninjas Dad Jokes API: create an account, obtain the shared API key, send a GET request to api.api-ninjas.com/v1/dadjokes, and provide the key in the X-Api-Key HTTP header. Explain that the default response is one random joke and that the documented limit parameter is not used because it is a paid feature.
  Why it matters: These are the concrete service requirements the next steps use to retrieve a fresh joke for the deployed to-do app.

Key terms: API, external service, API documentation, contract, HTTP, HTTP client, HTTP request, HTTP response, GET, POST

5.3.2 Using the requests library to connect to an API

This section shows how to install and use Python’s requests library to call a web API, read its response, and supply an API key in an HTTP header.

• Requests library setup: Describe how to install the requests library and verify that it is available in the Python environment. State that requests is a user-friendly Python library for HTTP communication with web APIs.
  Why it matters: Installing and confirming the library lets your app communicate with web-based services instead of only running local Python code.
• HTTP GET response handling: Explain how requests.get sends an HTTP GET request and that it returns a Response object representing the server response. Describe using response.text to retrieve the response body as a string.
  Why it matters: This is the basic pattern for bringing data returned by an external API into Python code.
• API key request header: Describe passing the API Ninjas key in an X-Api-Key HTTP header by supplying a regular Python dictionary through the headers argument of requests.get. Explain that including this header allows the joke API to return an actual joke.
  Why it matters: APIs commonly require credentials, and supplying them in the expected request header is necessary for authorized responses.

Key terms: requests, HTTP, pip show requests, requests.get, Response, response.text, response body, HTTP request, X-Api-Key, headers

5.3.3 Incorporating jokes in the app

This section adds a joke-of-the-day feature to the to-do app by fetching, displaying, and caching a joke from an external API.

• Joke API helper function: Describe how the separate jokes.py module uses generate_joke to request a joke from the Dad Jokes API and return usable joke text. Explain that the API URL is a configurable constant and the function receives the API key.
  Why it matters: Keeping the external-service code in its own helper module makes the to-do app easier to organize and change.
• Response parsing and fallback: Explain how generate_joke checks for a successful HTTP response, parses its JSON body, and extracts the joke string. Describe the fallback behavior when the API response is not successful.
  Why it matters: Checking the response and handling failure lets the app still show something useful when the external API does not return a joke.
• Joke display integration: Describe how todo_list.py imports generate_joke, calls it with an API key, and displays the returned joke in an st.info box near the task completion metric. State that the placeholder argument must be replaced with the real API key.
  Why it matters: This is the connection that turns the API helper into a visible feature in the Streamlit app.
• Session-cached joke: Explain why calling generate_joke directly on every rerun creates a new joke and unnecessary API usage, and describe storing the joke in st.session_state only when it is absent. State that the app then displays the stored joke, so it remains unchanged during interactions and changes on a page refresh.
  Why it matters: Caching the joke in session state prevents ordinary user clicks from rapidly consuming the API's monthly call quota.

Key terms: jokes.py, generate_joke, Dad Jokes API, API_URL, API key, requests.get, status code, requests.codes.ok, response.json(), JSON

5.3.4 Accessing an API key safely with st.secrets

This section moves an API key out of Streamlit app code into a local secrets.toml file and accesses it safely through st.secrets.

• Secret-handling security rule: Explain why API keys and other credentials must not be embedded in application code, particularly code committed to a public repository. Describe the financial or security risk of exposing an API key and the rule to keep secrets out of code.
  Why it matters: Keeping credentials out of source code prevents other people from using your accounts or services.
• Streamlit secrets configuration: Describe how Streamlit makes a secret available through st.secrets: place the value in .streamlit/secrets.toml during local development, then read the corresponding nested value from st.secrets in the app. Explain that deployed secrets are configured directly in Streamlit Community Cloud rather than committed with the code.
  Why it matters: This lets an app use a required API credential without exposing that credential in its source code.
• TOML secret lookup: Trace the jokes API key from the jokes_api section and api_key entry in secrets.toml to the expression st.secrets["jokes_api"]["api_key"] in Python. Describe the TOML structure as sections and key-value pairs that map to a nested dictionary-like structure.
  Why it matters: Matching the TOML structure to the st.secrets lookup lets the app retrieve the intended secret correctly.
• Secrets file location: Describe where the .streamlit directory must be placed: in the directory from which streamlit run is executed. Explain why placing it at the repository root works for Community Cloud, which effectively runs the command from that root.
  Why it matters: Putting the secrets directory in the command's working directory allows Streamlit to find local secrets reliably.

Key terms: API key, secret information, credential, public GitHub repository, st.secrets, secrets.toml, .streamlit, Streamlit Community Cloud, TOML, jokes_api

5.4 Deploying changes to Streamlit Community Cloud

This section explains that Community Cloud normally redeploys pushed GitHub changes automatically, but dependency and secret-handling changes require additional deployment configuration.

• Automatic GitHub redeployment: Describe how changes to an already deployed Streamlit app reach Streamlit Community Cloud. State that you commit the changes and run git push to update the GitHub repository, which Community Cloud automatically picks up.
  Why it matters: This is the basic workflow for publishing ordinary updates to a deployed app.
• Dependency and secret deployment setup: Explain why this app's recent changes make a simple Git push insufficient by itself. State that production needs the requests library installed, secrets.toml must not be pushed to GitHub, and the API key must instead be configured directly in Streamlit Community Cloud.
  Why it matters: A deployment can fail or expose credentials unless dependencies and API secrets are handled separately from the application code.

Key terms: git push, GitHub repo, Streamlit Community Cloud, requests, third-party library, secrets.toml, API key

5.4.1 Using a requirements.txt file to manage Python dependencies

This section explains how a requirements.txt file keeps Python dependencies compatible between development and Streamlit Community Cloud production environments.

• Development-production dependency consistency: Explain why an app's development and production environments need compatible versions of every third-party Python dependency. Describe how using a library feature unavailable in production, or potentially changed in a future release, can cause a deployed app to fail.
  Why it matters: Matching dependencies prevents an app that works on your computer from breaking after deployment.
• Requirements file dependency installation: Describe what requirements.txt contains and how pip and Streamlit Community Cloud use it. State that its lines declare Python modules with compatible version specifications or ranges, that pip install -r requirements.txt installs them, and that Community Cloud automatically installs listed libraries when the file is in the GitHub repository.
  Why it matters: The file gives the deployment platform a repeatable specification for installing the libraries your app needs.
• Dependency version specification workflow: Describe how to create a focused requirements.txt for this app: identify imported external dependencies, determine versions with pip show or generate a file with pip freeze and remove unneeded lines, then save the file at the root of the local Git repository. Distinguish unpinned package names, exact version pins, and minimum-version constraints, including their tradeoff between certainty and receiving future improvements.
  Why it matters: Choosing and recording appropriate dependency versions makes deployments reproducible without unnecessarily blocking safe library updates.
• Community Cloud preinstalled packages: State why this particular app may still run without requirements.txt in Community Cloud, while explaining why the file is still recommended. Mention that Community Cloud preinstalls streamlit and requests because Streamlit requires streamlit and depends internally on requests, but most projects need additional libraries and exact versions can still be pinned.
  Why it matters: Knowing the platform defaults explains why a simple app may deploy without a dependency file, but not why dependency management can be skipped.

Key terms: development environment, dev, production environment, prod, dependencies, requests, requirements.txt, pip, pip install -r requirements.txt, GitHub repository

5.4.2 Using .gitignore to protect secrets.toml

This section shows how to keep a local Streamlit secrets.toml file out of Git commits with .gitignore, including how to stop tracking it if it was already committed.

• Ignoring local secrets directory: Explain how a repository-root .gitignore file prevents secrets.toml from being committed by telling Git to ignore the .streamlit directory. State that the secrets file remains local beside the code rather than being stored in the Git repository.
  Why it matters: Keeping secrets out of the repository prevents API keys from being exposed to anyone who can view the code.
• Removing previously tracked secrets: Describe what to do when Git was already tracking the .streamlit folder before it was added to .gitignore: remove the directory from Git’s index with git rm -r --cached .streamlit/. Explain that this stops Git tracking it while allowing the local directory to remain available.
  Why it matters: Adding a file to .gitignore is not enough if the secret-containing directory is already tracked by Git.
• Deployment consequence of excluded secrets: Trace the immediate result of committing and pushing the changes after excluding .streamlit: the production app updates, but it cannot access its API key and shows an error. State that another configuration step is therefore needed before the deployed app works properly.
  Why it matters: This makes clear why protecting a local secret requires a separate way to supply that secret in production.

Key terms: .gitignore, .streamlit, secrets.toml, Git repository, commit, Git index, tracked, git rm -r --cached .streamlit/, git push, GitHub

5.4.3 Configuring secrets in Community Cloud

This section shows how to place a development API secret into Streamlit Community Cloud so the deployed app can use it in production.

• Community Cloud secrets configuration: Describe how to configure an app's secret in Streamlit Community Cloud by opening the app's Settings, selecting Secrets, pasting the development machine's secrets.toml contents into the Secrets textbox, and saving.
  Why it matters: A deployed app needs its API key configured in Community Cloud to access the external service without exposing the key publicly.
• App Settings access routes: State the two ways described to reach an app's Settings in Streamlit Community Cloud: through Manage App on the deployed app's public URL or through the app list on streamlit.io.
  Why it matters: Knowing either route lets you reach the configuration page needed to manage a deployed app's secrets.

Key terms: App Settings, Secrets, Secrets textbox, secrets.toml, Streamlit Community Cloud, Manage App, public URL, app list, Settings

5.5 Summary

This section summarizes how to deploy Streamlit apps, manage their code and dependencies, and protect credentials when using Community Cloud and external services.