Chapter 12: Packaging and deploying Streamlit apps

Introduction

This chapter introduces moving beyond Streamlit Community Cloud by packaging a Streamlit app with Docker, deploying it to AWS Elastic Beanstalk, and giving it a custom HTTPS domain.

• Production deployment roadmap: Describe the chapter's deployment path: package a Streamlit app with Docker, deploy the Dockerized app to AWS Elastic Beanstalk, and add a custom domain and HTTPS. State that the chapter also explains how the app executes in the cloud.
  Why it matters: This roadmap connects the packaging, cloud deployment, and production-facing setup steps that follow.
• Community Cloud limitations: Explain why a developer may need an alternative to Streamlit Community Cloud: an app can be put to sleep after inactivity, and developers may need more control over traffic handling, platform portability, memory, and the runtime environment.
  Why it matters: Recognizing these constraints helps you choose a deployment approach that fits an app moving beyond prototypes and demos.
• Chapter code resources: State that the book's GitHub repository contains this chapter's code in the chapter_12 folder, including a requirements.txt file with exact required Python library versions.
  Why it matters: These resources let you start from the chapter's intended code and dependency versions.

Key terms: Docker, AWS, AWS Elastic Beanstalk, custom domain, HTTPS, Streamlit Community Cloud, deployment, traffic, memory, environment

12.1 Deployment considerations

This section frames the move from Streamlit Community Cloud for small projects to a more professional deployment approach for larger or higher-traffic apps.

• Community Cloud deployment fit: Distinguish the kinds of apps for which Streamlit Community Cloud has been suitable from the more professional deployment situations where it may not be sufficient. State that it has supported free, beginner-friendly testing and sharing of small projects, while startup, internal-company, or relatively high-traffic apps may need another option.
  Why it matters: Choosing hosting based on an app's needs helps you move beyond a convenient development deployment when requirements grow.
• Deployment exploration roadmap: Describe the deployment decision path introduced for this chapter: examine Community Cloud's limitations, consider alternatives ranging from simple to advanced, and select the approach the chapter will implement.
  Why it matters: This roadmap explains why the chapter evaluates options before packaging and deploying an app.

Key terms: Streamlit Community Cloud, deployment, deployment alternatives

12.1.1 Why Streamlit Community Cloud may not work for some users

This section explains why Streamlit Community Cloud suits learning and lightweight apps but may be unsuitable when an app needs branding, capacity, availability, or server control.

• Community Cloud limitations: Describe the main limitations that can make Streamlit Community Cloud unsuitable for a professional or demanding app: no custom domain, resource limits, idle sleep, and limited server customization. Explain how these limitations affect deployment needs.
  Why it matters: Recognizing these constraints helps you choose a deployment platform that fits the app’s real requirements.
• Deployment cost trade-offs: Explain why the Community Cloud limitations exist and why removing them generally costs money. State how a learner can keep experimentation costs low, while noting that registering a custom domain can cost $10 or more per year.
  Why it matters: Deployment choices involve both technical capabilities and ongoing costs.

Key terms: Streamlit Community Cloud, custom domain, resource limits, throttled, idle, high availability, free, Snowflake, deployment costs

12.1.2 Deployment alternatives

This section compares fully managed platforms, infrastructure-as-a-service, and platform-as-a-service options for deploying Streamlit apps, emphasizing their trade-offs and WebSocket support.

• Deployment platform categories: Distinguish fully managed platforms, infrastructure-as-a-service (IaaS), and platform-as-a-service (PaaS) as deployment alternatives for Streamlit apps, including the general convenience-versus-control trade-off among them.
  Why it matters: Choosing the right level of managed infrastructure helps you avoid either unnecessary operational work or insufficient control.
• Managed platform alternatives: Describe the managed alternatives to Streamlit Community Cloud: Render and Heroku offer GitHub-connected, low-setup deployment with paid scaling and fewer idle-app limits, while Streamlit in Snowflake suits internal apps at organizations already using Snowflake.
  Why it matters: These services can retain much of Community Cloud's simplicity when its resource or idle-app limits are unsuitable.
• WebSocket hosting requirement: Explain why a prospective hosting platform must support WebSockets for a Streamlit app, and distinguish Google App Engine Flexible from Google App Engine Standard on that requirement.
  Why it matters: A deployment target without WebSocket support will not run a Streamlit app successfully.

Key terms: fully managed platforms, infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), Render, Heroku, Streamlit in Snowflake, GitHub repository, scaling, WebSockets, Google App Engine (Flexible)

12.1.3 Our approach

This section justifies a learning-focused deployment path: containerize a Streamlit app with Docker, deploy it through AWS Elastic Beanstalk, and make it production-ready with a custom domain and HTTPS.

• Chosen deployment path: Describe the chapter's chosen deployment path: package the app with Docker, deploy it to AWS Elastic Beanstalk, then add a custom domain and HTTPS.
  Why it matters: This roadmap connects the packaging, cloud deployment, and production-readiness work that follows.
• Learning-first platform choice: Explain why the chapter chooses Docker and AWS Elastic Beanstalk instead of the easiest hosting route: the chosen path teaches the underlying realities of cloud deployment rather than hiding them behind a simple platform abstraction.
  Why it matters: Understanding this trade-off helps you see the goal as transferable deployment knowledge, not merely getting one app online quickly.
• Production deployment benefits: Explain the distinct benefits of Docker, Elastic Beanstalk, and production finishing: Docker creates a reproducible portable image, Elastic Beanstalk manages infrastructure while exposing key cloud internals, and a custom domain plus HTTPS support professionalism, trust, and secure connections.
  Why it matters: These benefits explain how the selected tools produce an app that runs consistently and is suitable to share with real users.

Key terms: Docker, AWS Elastic Beanstalk, custom domain, HTTPS, Render, Heroku, AWS, Elastic Beanstalk, reproducible image, dependencies

12.2 Packaging the app using Docker

This section introduces packaging a Streamlit app with Docker so it runs consistently locally and in cloud environments.

• Docker packaging purpose: Explain why Docker is used to package a Streamlit app for deployment: cloud environments can differ from a local machine, while a portable self-contained package behaves consistently wherever it runs.
  Why it matters: Consistent packaging reduces environment-specific failures when moving an app from local development to the cloud.
• Containerized app contents: Describe what is packaged into the Docker container for this app: Python, the required libraries, and the app code, all running together inside the portable container.
  Why it matters: A container includes the runtime and dependencies the app needs instead of assuming they already exist on the target machine.
• Docker packaging workflow: Trace the section's planned Docker workflow: learn Docker basics, examine the app in a container, create a Dockerfile that specifies how to build it, and run the containerized app locally before later cloud deployment.
  Why it matters: The Dockerfile makes the container build repeatable, and local execution verifies the packaged app before deployment.

Key terms: Docker, portable, self-contained unit, cloud, local machine, container, Python, required libraries, app code, Dockerfile

12.2.1 Intro to Docker

This section introduces Docker as a way to package a Streamlit app and its environment consistently, and explains how to install Docker Desktop.

• Docker environment consistency: Explain how Docker prevents environment-related failures when a Streamlit app moves from one machine to another, including missing dependencies, Python-version differences, and operating-system compatibility.
  Why it matters: Docker lets an app carry the environment it needs instead of relying on each user’s machine to be configured identically.
• Dockerfile image and container: Describe the relationship among a Dockerfile, a Docker image, and a container: the Dockerfile defines the app environment, Docker builds it into an image, and the image runs in a container that behaves like a mini-computer.
  Why it matters: Distinguishing these three pieces makes it possible to package, run, and later deploy the app correctly.
• Layered reusable images: Describe how Docker constructs an image layer by layer from Dockerfile instructions, such as choosing a base operating system, installing Python and packages, copying code, and running the app.
  Why it matters: The layered build model explains why an image is a reusable, versioned package that can be shared or deployed where Docker is installed.
• Docker Desktop installation: State how to install Docker Desktop: download it from the Docker website, run the installer, select the recommended settings when prompted, and use its interface to view, pause, or stop running containers.
  Why it matters: Docker Desktop provides the local Docker installation needed to build and run the app container in the following sections.

Key terms: Docker, consistent environment, dependencies, Python version, operating system, Dockerfile, Docker image, container, layers, Dockerfile instructions

12.2.2 The app in a container

This section explains the layered Docker environment in which a Streamlit app runs and how its container connects to the host through ports and mounted volumes.

• Container execution architecture: Describe the layers that run a Streamlit app in Docker: the app runs in a container managed by Docker Engine, and Docker Engine uses a Linux kernel supplied by a Linux virtual machine in Docker Desktop.
  Why it matters: This mental model helps you understand what Docker supplies around your app and what is provided by the host system.
• Self-contained application environment: Explain what the app container includes—minimal Linux userspace, Python, Streamlit, application code, and dependencies—and why packaging these together lets the app run consistently wherever Docker is installed.
  Why it matters: A self-contained environment reduces differences between machines that can otherwise cause an app to fail after it is moved.
• Host-container connections: Distinguish port forwarding from volume mounting: port forwarding sends traffic from a host port such as 8502 to the Streamlit server on container port 8501, while a mounted volume shares host files with the container for items such as secrets and configuration without embedding them in the container.
  Why it matters: These two connections let a contained app be reachable and use needed external files without baking sensitive configuration into its image.

Key terms: Docker container, Docker Engine, Docker Desktop, Linux kernel, Linux virtual machine, container, minimal Linux distribution, Python, Streamlit, dependencies

12.2.3 Creating a Dockerfile

This section builds a Dockerfile for a Streamlit app and explains how its instructions package the app, dependencies, network settings, and startup command into an image.

• Dockerfile image recipe: Explain that a Dockerfile is a sequence of instructions used to build a Docker image, and that each instruction creates a cached layer representing filesystem changes.
  Why it matters: Understanding the Dockerfile as a layered recipe helps you package and change an app deliberately.
• Dependency-first image construction: Describe the Dockerfile sequence that starts from python:3.12-slim, sets /app as the working directory, copies requirements.txt, installs dependencies with pip, and then copies the application code. Explain why dependencies are installed before the rest of the code.
  Why it matters: This ordering gives the container its Python environment while making rebuilds faster when only application code changes.
• Streamlit container networking: Explain how EXPOSE 8501 documents Streamlit's default runtime port, while the STREAMLIT_SERVER_PORT, STREAMLIT_SERVER_HEADLESS, and STREAMLIT_SERVER_ADDRESS environment variables configure the server to use port 8501, avoid opening a browser, and accept connections from outside the container.
  Why it matters: These settings allow a Streamlit server in a container to be reachable by users rather than only from inside the container.
• Container startup and configuration: Describe how the final streamlit run command starts the app's entrypoint, such as main.py, and state that Streamlit configuration can be supplied through STREAMLIT_ environment variables, .streamlit/config.toml, or streamlit run flags.
  Why it matters: Knowing both the startup command and configuration choices lets you adapt the image to a different Streamlit app or server setting.

Key terms: Dockerfile, Docker image, Docker container, instruction, layer, layer caching, python:3.12-slim, base image, Docker Hub, WORKDIR

12.2.4 Excluding files from an image

This section prevents sensitive and unnecessary local files from being copied into a Docker image by configuring a .dockerignore file.

• Secrets in Docker images: Explain why copying secrets.toml into a Docker image is a security vulnerability. State that images are shareable artifacts and that secrets can remain embedded in image layers, where someone obtaining or exposing the image may extract them.
  Why it matters: Keeping secrets out of an image prevents credentials from traveling with a distributable application artifact.
• Docker ignore configuration: Describe how a .dockerignore file excludes files and directories from being copied into a Docker image during the build. State that it uses ignore patterns similarly to .gitignore, and that this section places it beside the Docker build context to exclude .streamlit/ and metadata such as .git and .gitignore.
  Why it matters: A .dockerignore file keeps sensitive and irrelevant local files out of the image created from the project directory.

Key terms: secrets.toml, Docker image, image layers, COPY . ., .dockerignore, .gitignore, pattern matching, .streamlit/, Docker build process

12.2.5 Building an image and running a container

This section builds and runs the Fact Frenzy Docker image, connects its Streamlit port to the host, and supplies excluded secrets at runtime with a volume mount.

• Image build and container startup: Explain how a Dockerfile is used to build the fact-frenzy image and how that image is used to start a container. Distinguish build-time Dockerfile instructions from the CMD that runs Streamlit only when the container starts.
  Why it matters: This distinction lets you tell whether Docker is preparing an image or actually launching your Streamlit app.
• Host-to-container port mapping: Describe why a Streamlit server running on port 8501 inside a container is not directly reachable from the host browser, and how the -p host-port:container-port option forwards traffic to it. Trace how host port 8502 reaches Streamlit on container port 8501 through localhost:8502.
  Why it matters: Port mapping is what makes a web app running inside a container accessible from your own browser.
• Runtime secrets volume mount: Explain why secrets.toml is excluded from the Docker image and how mounting the host .streamlit folder with -v makes those secrets available inside the container at runtime. Describe the host-path:container-path form using ./.streamlit/:/app/.streamlit.
  Why it matters: Mounting secrets at runtime avoids baking sensitive values into an image while still allowing the app to use them.

Key terms: Dockerfile, Docker image, Docker container, CMD, docker build, docker run, host machine, container machine, -p, port mapping

12.2.6 Adding a Docker Compose configuration

This section replaces repeated Docker build-and-run commands with a Docker Compose configuration that starts the Streamlit app with its required ports and secrets mount.

• Docker Compose purpose: Explain how Docker Compose serves as a configuration manager for Docker by storing container setup instructions in a file rather than requiring long terminal commands each time.
  Why it matters: Docker Compose makes a repeatable app setup easier to run correctly.
• Compose file configuration: Describe the docker-compose.yml configuration for the Fact Frenzy app: it defines the fact-frenzy-app service, builds from the Dockerfile in the current directory, maps host port 8502 to container port 8501, and mounts the host .streamlit directory at /app/.streamlit in the container.
  Why it matters: These settings make the containerized Streamlit app reachable locally while supplying its Streamlit secrets configuration.
• Compose application startup: State that the Docker Compose startup command builds the image when needed and starts the container using the configured port mapping and volume mount, making the app available at http://localhost:8502 with secrets configured.
  Why it matters: Starting through Compose applies the saved configuration consistently in one step.

Key terms: Docker Compose, configuration manager, docker-compose.yml, YAML, service, fact-frenzy-app, build: ., ports, docker compose up, http://localhost:8502

12.3 Deploying to AWS Elastic Beanstalk

This section introduces deploying a Dockerized Streamlit app to AWS Elastic Beanstalk and previews the concepts and steps that make the deployment understandable.

• AWS deployment purpose: Explain that the goal is to move the Dockerized Streamlit app from local execution to online hosting so people can access it from anywhere, using AWS Elastic Beanstalk rather than Streamlit Community Cloud.
  Why it matters: Online deployment makes the app accessible beyond the developer’s own machine.
• Elastic Beanstalk learning path: Describe the planned path through the section: an overview of AWS and Elastic Beanstalk, a mental model of deployment internals, AWS account setup, and making the app live. State that Elastic Beanstalk is chosen as a balance between convenience and control.
  Why it matters: Knowing the path and mental model helps deployment commands and configuration feel purposeful rather than mysterious.

Key terms: Dockerized app, AWS, AWS Elastic Beanstalk, Streamlit Community Cloud, Elastic Beanstalk, mental model, convenience, control

12.3.1 An overview of AWS

This section introduces AWS as an on-demand cloud platform, identifies the AWS services used for deployment and HTTPS, and motivates Elastic Beanstalk as a simpler alternative to assembling raw services yourself.

• AWS cloud computing model: Explain AWS as Amazon's cloud computing platform where developers rent digital infrastructure on demand instead of buying and maintaining physical servers. Describe the kinds of resources AWS can provide, including computing power, storage, databases, and automatic scaling.
  Why it matters: This model explains what infrastructure runs a deployed Streamlit app and why cloud deployment avoids operating your own servers.
• AWS service deployment roles: Describe the roles of EC2, S3, IAM, and AWS Certificate Manager in this chapter's deployment: EC2 hosts the Dockerized Streamlit app on virtual machines, S3 temporarily holds app code, IAM authenticates access and controls secure service-to-service permissions, and Certificate Manager supports HTTPS for a custom domain.
  Why it matters: Knowing which service handles hosting, code storage, access control, and certificates makes the later deployment architecture understandable.
• Raw AWS service complexity: Explain that AWS services are flexible building blocks that can be combined for different infrastructure needs, but deploying directly with those raw services is complex and challenging. State that this complexity is why the chapter turns to Elastic Beanstalk.
  Why it matters: This explains why Elastic Beanstalk is useful instead of manually assembling every AWS infrastructure component.

Key terms: Amazon Web Services, AWS, cloud computing platform, on demand, automatic scaling, EC2, Elastic Cloud Compute, S3, Simple Storage Service, IAM

12.3.2 Introducing Elastic Beanstalk

This section introduces AWS Elastic Beanstalk as a managed, Docker-friendly platform that deploys and operates a Streamlit app without requiring manual infrastructure setup.

• Elastic Beanstalk purpose: Explain that AWS Elastic Beanstalk deploys and manages web applications on AWS while hiding much of the underlying infrastructure configuration.
  Why it matters: It lets you deploy an app with AWS capabilities without personally setting up every hosting component.
• Managed infrastructure responsibilities: Describe the infrastructure work Elastic Beanstalk bundles together, including servers, networking, load balancing, monitoring, and scaling, instead of requiring manual AWS configuration.
  Why it matters: Understanding what the platform manages clarifies why it can make AWS deployment much simpler.
• Docker and CLI deployment: Describe how Elastic Beanstalk can accept a Dockerfile for the app and can be managed from the terminal with the EB CLI, while remaining customizable when needed.
  Why it matters: These features connect the containerized app to a practical, terminal-driven deployment workflow.

Key terms: Elastic Beanstalk, AWS, underlying infrastructure, EC2 instances, load balancer, networking rules, monitoring, scaling, EC2, Docker

12.3.3 A mental model of the deployed app

This section establishes a mental model of how a Docker-packaged Streamlit app runs on AWS Elastic Beanstalk and how a browser request travels through its infrastructure.

• Deployed request flow: Trace a typical browser request through the deployed app: from the URL to the load balancer, an EC2 instance, its Docker container, the Streamlit app, and back through the load balancer to the browser. Explain that the Streamlit app inside the container processes the request as it did locally and generates the response.
  Why it matters: This flow lets you understand where requests go when your app is no longer running only on your computer.
• Load balancer traffic routing: Describe the load balancer's role as the initial recipient of web traffic on port 80, and later port 443 for HTTPS, forwarding requests to EC2 instances and balancing traffic when multiple instances are running.
  Why it matters: The load balancer is the public traffic entry point and distributes work across the app instances.
• Elastic Beanstalk managed infrastructure: Explain that Elastic Beanstalk automatically provisions and configures the EC2 instances, S3 storage, Docker environment, load balancer, networking rules, and app-health monitoring for this deployment. State that it can replace failed instances.
  Why it matters: Elastic Beanstalk removes much of the manual infrastructure setup and helps keep the deployed app running.

Key terms: load balancer, EC2 instances, Docker container, Docker image, Streamlit app, port 80, port 443, HTTPS, Elastic Beanstalk, S3 storage

12.3.4 Creating and preparing an AWS account

This section prepares an AWS account for Elastic Beanstalk deployment by explaining AWS service permissions, creating command-line credentials, and assigning an EC2 instance role.

• AWS account setup and costs: Describe how to create an AWS account and use the AWS Management Console to find services and monitor charges. Explain that Elastic Beanstalk itself is not billed directly, while its underlying services are, and that load balancing and auto-scaling can exceed the free tier.
  Why it matters: An AWS account and cost awareness are prerequisites for deploying without unexpected charges.
• AWS service permission relationships: Explain why Elastic Beanstalk, EC2, and S3 require explicitly configured permissions to cooperate during deployment. Trace the deployment interactions: Elastic Beanstalk uploads code to S3 and starts EC2 instances, while EC2 downloads code from S3 and reports health to Elastic Beanstalk.
  Why it matters: Deployment works only when each AWS service is authorized to perform its particular part of the workflow.
• IAM user command-line credentials: Describe creating an IAM user, attaching the listed Elastic Beanstalk, EC2, and S3 policies, and generating an access-key ID and secret access key for command-line access. Justify using this IAM user's keys instead of creating long-term access keys for the root user, and state that the secret pair must be stored safely because AWS will not show it again.
  Why it matters: The Elastic Beanstalk command-line workflow needs programmatic credentials that avoid exposing unrestricted root access.
• EC2 instance profile role: Describe creating the IAM role or instance profile that lets deployed EC2 instances access S3 and report to Elastic Beanstalk. State the role setup choices: AWS service as the trusted entity, EC2 as the use case, AWSElasticBeanstalkWebTier as the permission policy, and aws-elasticbeanstalk-ec2-role as the role name.
  Why it matters: The deployed EC2 instances need their own limited AWS identity to retrieve application code and communicate health information.
• Automatic Elastic Beanstalk permissions: State that this setup manually creates the EC2-side role, while Elastic Beanstalk permissions are created automatically later when the eb create command runs.
  Why it matters: This prevents unnecessary attempts to manually configure a second permission set before environment creation.

Key terms: AWS Management Console, free tier, Elastic Beanstalk, EC2, S3, Billing and Cost Management, permissions, health, IAM, IAM user

12.3.5 Modifying your app setup for Elastic Beanstalk

This section adapts a Dockerized Streamlit app for Elastic Beanstalk by provisioning secrets on the host, mounting them into the container, and keeping deployment secrets out of source control and images.

• Elastic Beanstalk secret provisioning: Explain why the local .streamlit folder mount does not work on Elastic Beanstalk and how an .ebextensions configuration supplies secrets.toml instead. Describe that Elastic Beanstalk processes configuration files in .ebextensions before the application starts.
  Why it matters: Elastic Beanstalk needs a server-side way to make secrets available because you cannot directly place local files on its filesystem.
• Secrets file configuration details: Describe what secrets_file.config creates: the /var/app/secrets/.streamlit/ directory and a secrets.toml file containing the existing secret values. State that the configuration sets permissions to 644 and assigns the file owner and group to webapp, and that multiline content requires a pipe plus consistent indentation.
  Why it matters: The configuration must create the expected file at the expected path with valid content and usable permissions.
• Elastic Beanstalk Compose adjustments: Describe the two docker-compose.yml changes for Elastic Beanstalk: map host port 80 to container port 8501, and mount /var/app/secrets/.streamlit into the container instead of the local .streamlit directory. Trace how the prepared host directory is then mounted when Docker Compose starts the containers.
  Why it matters: These changes let Elastic Beanstalk reach the Streamlit app on its expected port while the container receives the secrets prepared on the host.
• Deployment secret file protection: Explain why .ebextensions/secrets_file.config must receive the same protection as secrets.toml: it contains the secret values and must not be committed to version control or included in the Docker image. State that .ebextensions/ belongs in both .gitignore and .dockerignore, and .elasticbeanstalk/ should also be added to both before eb init creates it.
  Why it matters: A deployment configuration that embeds secrets can leak them just as easily as the original Streamlit secrets file.

Key terms: .ebextensions, secrets_file.config, secrets.toml, Elastic Beanstalk, EC2 instance, /var/app/secrets/.streamlit/, content, 644, webapp, pipe (|)

12.3.6 Creating an Elastic Beanstalk app

This section walks through initializing an Elastic Beanstalk application with the EB CLI, creating and deploying an environment, and redeploying later code changes.

• EB CLI initialization: Describe how running `eb init` from the app root configures an Elastic Beanstalk application through an interactive wizard. Explain the key choices: AWS region, IAM access credentials, application name, Docker platform, and SSH key-pair setup.
  Why it matters: Initialization gives Elastic Beanstalk the application configuration and AWS access it needs before an environment can be deployed.
• Environment creation and deployment: Trace how `eb create` creates a live Elastic Beanstalk environment and deploys the Dockerized app to it. Describe the environment name, DNS prefix, application load balancer choice, and the AWS resources Elastic Beanstalk provisions behind the scenes.
  Why it matters: Creating the environment turns the configured project into a publicly reachable application managed by AWS.
• Deployment access and updates: Explain how to access the deployed app using its Elastic Beanstalk URL or `eb open`, and how to redeploy later application changes with `eb deploy` from the app directory.
  Why it matters: The CLI workflow provides a quick way to verify a release and publish subsequent code changes.

Key terms: EB CLI, eb init, AWS region, access key ID, secret access key, Elastic Beanstalk application, eb create, Elastic Beanstalk environment, DNS prefix, application load balancer

12.4 Adding a custom domain and HTTPS

This section introduces why a deployed Elastic Beanstalk app needs a custom domain and HTTPS before explaining how to add both.

• Custom domain purpose: Explain why replacing an Elastic Beanstalk URL with a custom domain gives an app a more memorable and professional web address.
  Why it matters: A recognizable domain makes it easier and more credible to share your app with users.
• HTTPS transport security: Explain that HTTPS encrypts data exchanged between users and the app, whereas an HTTP-only app can expose submitted information such as login credentials to network snoopers.
  Why it matters: HTTPS protects users' sensitive information and avoids browser warnings or blocking for insecure sites.

Key terms: custom domain, Elastic Beanstalk URL, HTTP, HTTPS, encryption, certificate, load balancer

12.4.1 Adding a domain

This section explains why a custom domain is needed for practical HTTPS and how to register one and point its www address to an Elastic Beanstalk app through DNS.

• Custom domain need for HTTPS: Explain why a custom domain gives an Elastic Beanstalk app a more professional, shareable address and is needed to obtain a practical CA-signed SSL certificate for HTTPS.
  Why it matters: A custom domain lets visitors reach your app at a memorable address and enables trusted HTTPS setup.
• Domain registration and DNS management: Describe the role of a domain registrar: it checks name availability, registers the domain after payment, and provides access to DNS management settings.
  Why it matters: You need control of the domain's DNS settings before you can direct visitors to your deployed app.
• CNAME routing to Elastic Beanstalk: Describe how to point the www host of a custom domain to an Elastic Beanstalk app by adding a CNAME DNS record whose target is the app's Elastic Beanstalk URL, disabling proxying or forwarding initially, and allowing time for DNS propagation.
  Why it matters: The CNAME record is what makes visits to your custom web address reach the Streamlit app running on AWS.

Key terms: custom domain, HTTPS, SSL certificate, Certificate Authority, CA, Elastic Beanstalk domain, domain registrar, domain registration, DNS, DNS management dashboard

12.4.2 Creating a certificate

This section explains why HTTPS certificates are needed and shows how to request and validate an AWS ACM certificate for a custom domain.

• HTTPS certificate purpose: Explain how HTTPS encrypts communication between users and an app, and how a digital certificate lets a browser verify that the server belongs to the requested domain.
  Why it matters: A trusted certificate protects users from unencrypted traffic and from impostors intercepting their connection.
• ACM certificate request settings: Describe how to request a certificate in AWS Certificate Manager (ACM), including selecting a public certificate, entering the custom domain, choosing DNS validation, and using the RSA 2048 key algorithm.
  Why it matters: Selecting the appropriate ACM request options produces a certificate that can secure the public Streamlit app.
• DNS ownership validation: Trace how DNS validation proves control of the domain: copy ACM's provided CNAME name and value into the domain's DNS configuration, then wait for AWS to check the record and change the certificate from Pending Validation to Issued.
  Why it matters: Adding ACM's validation record is the step that allows the Certificate Authority to issue a trusted certificate for the domain.

Key terms: HTTP, HTTPS, digital certificate, man-in-the-middle attack, Certificate Authority (CA), AWS Certificate Manager (ACM), public certificate, Fully Qualified Domain Name, DNS validation, RSA 2048

12.4.3 Adding the certificate to your load balancer

This section attaches an ACM certificate to an Elastic Beanstalk load balancer so a custom-domain Streamlit app serves secure HTTPS traffic.

• Load balancer HTTPS termination: Explain how the Elastic Beanstalk load balancer sits between users and the app, distributes traffic across EC2 instances, and handles HTTPS encryption before forwarding traffic to the app.
  Why it matters: Terminating HTTPS at the load balancer secures user connections without making the Streamlit app handle encryption itself.
• HTTPS listener configuration: Describe how to add an HTTPS listener in the Elastic Beanstalk console: edit Instance Traffic and Scaling, add port 443 with protocol HTTPS, select the ACM certificate, use the stated SSL policy and default process, then apply the changes.
  Why it matters: This listener connects the issued certificate to the deployed infrastructure and makes secure HTTPS requests possible.
• Secure domain verification: State that, after the Elastic Beanstalk environment finishes updating, visiting the custom domain with https:// should show the browser's indication of a secure connection.
  Why it matters: Browser verification confirms that the certificate and HTTPS listener are serving the custom-domain app securely.

Key terms: load balancer, EC2 instances, HTTPS, encryption, Elastic Beanstalk, AWS Management Console, Configuration, Instance Traffic and Scaling, Listeners, port 443

12.5 Go forth and develop!

This concluding section frames Streamlit as a launchpad for building, sharing, and iterating on real Python web apps, while encouraging continued technical growth.

• Streamlit as a development launchpad: Explain how Streamlit enables Python developers to turn ideas into interactive web apps quickly, share them effectively, and iterate boldly.
  Why it matters: This is the central value proposition that can guide you in choosing Streamlit for future projects.
• Practical Streamlit application range: Describe the kinds of real applications the book says Streamlit can support, including internal tools, prototypes, data exploration and dashboards, CRUD interfaces, games, and AI-powered bots.
  Why it matters: Recognizing this range can help you identify useful problems that are suitable for a Streamlit app.
• Continued software development growth: Describe the broader development practices and learning directions the section encourages: user-centered design, separation of concerns, testing, deployment, trade-off awareness, and potentially deeper Python, architecture, or frontend skills.
  Why it matters: Building a useful app is stronger when you also consider maintainability, users, testing, deployment, and the next skills your goals require.

Key terms: Streamlit, pure-Python web apps, interactive applications, launchpad, internal tool, prototype, data dashboard, CRUD interface, trivia game, AI-powered support bot

12.6 Summary

This summary recaps deployment choices, Docker packaging, Elastic Beanstalk deployment, and custom-domain HTTPS for Streamlit apps.