Deploy AI Dashboard Builder to Cloud

Containerize a Streamlit app with Docker and deploy it live on Render.

Introduction

30 Second Summary

You have built an app that works perfectly on your laptop. Sharing it means asking everyone else to go through the exact same setup process you did before they can even try it.

In this project, you will package your AI Dashboard Builder into a Docker container, deploy it to Render's cloud, and set up automatic deployments so every code change goes live within minutes.

What You'll Build

You will share a public URL with a friend, and they will open your AI-powered dashboard builder in their browser, upload a spreadsheet, and get AI-generated insights without installing a single thing.

By the end of this project, you'll have:

  • A Docker container that bundles your entire app and its dependencies into a portable image that runs the same way on any machine.
  • A live public URL where anyone can open your AI Dashboard Builder and use all its features, including AI-powered analysis.
  • Continuous deployment from GitHub to Render. Push a code change and your live site updates automatically within minutes.
  • Secret Mission: an optional challenge to push your deployment skills even further.

Are there any prerequisites?

This project is Part 3 of the AI-Powered Excel Dashboard series. You need a working Streamlit app with Gemini integration, drag-and-drop panels, and multi-format export from Parts 1 and 2 before starting.

Before We Start

You have built a powerful AI Dashboard Builder across Parts 1 and 2, and it works great on your machine. Before any hands-on work, let's lock in exactly what you are deploying and why containerizing it matters for getting it into production.

Set Up Docker and Render

Your AI Dashboard Builder runs great on your machine, but it depends on your local Python environment and installed packages. Anyone who wants to run your app would need to replicate your exact setup.

In this step, you'll install Docker to package your app into a portable container. You'll also create a Render account to give that container a home on the internet.

In this step, get ready to:
  • Install Docker Desktop with the WSL 2 backend on your Windows machine.
  • Create a Render account connected to your GitHub.
  • Verify your project has a complete requirements.txt.
Install Docker Desktop

Docker Desktop is the application that runs Docker containers on your Windows machine. It bundles the Docker engine, CLI tools, and a graphical interface into a single installer.

What is Docker?

Think of Docker as a shipping container for software. Just like a shipping container holds goods and can be loaded onto any ship, a Docker container holds your app and its entire environment. It runs the same way on any machine.

  • Check if Docker is already installed on your machine by running this command in your terminal:
docker --version

✔️ I see a version number

Docker is already installed. Make sure Docker Desktop is running before you continue. Press the Windows key, type Docker Desktop, and press Enter to launch it if it is not already open.

Skip ahead to the docker run hello-world test below.

ⓧ 'docker' is not recognized

  • Download Docker Desktop for Windows from the official install page.
  • Double-click Docker Desktop Installer.exe to run the installer.
  • When the installer asks which installation mode you prefer, choose per-user installation. This is the recommended option and does not require admin rights.
  • On the Configuration page, check the box labeled Use WSL 2 instead of Hyper-V. This selects WSL 2 as the backend, which is the recommended option for most users.
  • Complete the installation. The installer may prompt you to restart your computer to finish enabling WSL 2 features. If so, restart and then continue from here.
  • After installation, press the Windows key, type Docker Desktop, and press Enter to launch it.
  • Wait for Docker Desktop to finish starting up. The first launch takes a minute or two as it initializes the WSL 2 environment.
  • Confirm Docker is installed by running this command again:
docker --version

You should now see a version number in the output.

Before you run the next command, what do you think will happen when Docker tries to run a container called hello-world?

  • Test that Docker works end to end by running the hello-world container:
docker run hello-world

You should see Hello from Docker! printed in your terminal. This confirms Docker can pull images from the internet and run containers on your machine.

Not seeing 'Hello from Docker!'?

  • Make sure Docker Desktop is running. Look for the Docker whale icon in your system tray at the bottom right of your screen.
  • If you see a permission error, close your terminal and reopen it. Docker needs a fresh terminal session after installation.
  • If you see a message about WSL 2 not being installed, follow the link in the error message to enable WSL 2 on your machine, then restart Docker Desktop.

Help me troubleshoot Docker Desktop on Windows

Create a Render account

Render is a cloud platform that hosts your containers on the internet. It takes your Docker image and gives it a public URL, handling networking and security certificates so you do not have to manage any infrastructure.

  • Open the Render sign-up page in your browser.
  • Sign up using your GitHub account. Select the GitHub option and authorize Render to access your repositories when prompted.

After authorizing, you land on the Render Dashboard. Your GitHub repos are now accessible to Render for deployments.

Why sign up with GitHub?

Signing up with GitHub connects your code repositories to Render automatically. Later in this project, Render will watch your repo and redeploy whenever you push new code. Signing up with a different method would require connecting GitHub separately.

Verify your requirements.txt

Your project needs a requirements.txt file listing every Python package it depends on. Docker uses this file to install the right packages inside the container.

  • Open your AI Dashboard Builder project folder in your code editor or file explorer.
  • Look for a file named requirements.txt in the root of the project.

If you already have a requirements.txt, skip to the verification step below. If you do not have one, activate your project's virtual environment (the one you used in Parts 1 and 2) and create the file by running this command:

pip freeze > requirements.txt

What does this command do?

The pip freeze command lists every Python package installed in your active virtual environment, along with its exact version number. The > requirements.txt part writes that list into a file. This guarantees the container gets the exact same packages as your local environment.

  • Open requirements.txt and confirm it includes streamlit and google-generativeai in the list.

You should see both package names listed alongside their version numbers, plus any other packages your app uses.

Missing packages in requirements.txt?

  • Make sure you activated your project's virtual environment before running pip freeze. The command captures whatever is installed in the active environment. If you ran it in the system Python, the file will contain the wrong packages.
  • If streamlit or google-generativeai is missing, activate your virtual environment and install them with pip install streamlit google-generativeai, then run pip freeze > requirements.txt again.

Help me fix my requirements.txt for my Streamlit project

Your tools are ready and your dependencies are locked down. Next up, you'll write a Dockerfile and build your first container.

Containerize Your App with Docker

Your tools are in place. Docker Desktop is running, Render is connected to GitHub, and your requirements.txt is verified. Now comes the real question: how do you share your app with someone who doesn't have your exact Python setup?

Right now, anyone who wants to run your app needs to install Python, create a virtual environment, install every dependency, and configure environment variables manually. A Docker container bundles all of that into a single image that runs the same way everywhere.

In this step, get ready to:
  • Create a Dockerfile, a .dockerignore, and a Streamlit production config.
  • Build a Docker image from your project.
  • Run your app inside a container and verify it works at http://localhost:8501.
Create a Dockerfile and .dockerignore

A Dockerfile is a recipe that tells Docker exactly how to build your app's container image. It specifies which base image to start from, how to install dependencies, and how to start your app.

  • In your project's root directory, create a new file named Dockerfile (no file extension) and add the following content:
# Start from a lightweight Python 3.12 image
FROM python:3.12-slim

# Set the working directory inside the container
WORKDIR /app

# Install system-level tools needed by some Python packages
RUN apt-get update && apt-get install -y \
    build-essential \
    curl \
    && rm -rf /var/lib/apt/lists/*

# Copy and install Python dependencies first (caches this layer)
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy the rest of your app code into the container
COPY . .

# Set the port Streamlit will listen on
ENV PORT=8501

# Document which port the container exposes
EXPOSE 8501

# Let Docker monitor app health automatically
HEALTHCHECK CMD curl --fail http://localhost:$PORT/_stcore/health

# Launch Streamlit when the container starts
CMD streamlit run app.py --server.port=$PORT --server.address=0.0.0.0 --server.headless=true

What does this Dockerfile do?

  • FROM python:3.12-slim starts from an official Python image, giving your container Python without you installing it.
  • WORKDIR /app creates and switches to an /app folder inside the container. Streamlit requires a working directory that is not the root folder.
  • build-essential and curl are system tools. Some Python packages need C compilation to install, and curl powers the health check.
  • requirements.txt is copied and installed BEFORE the rest of your code. Docker caches this layer, so rebuilds skip the slow pip install step if your dependencies have not changed.
  • CMD launches Streamlit bound to 0.0.0.0 so it accepts connections from outside the container.

Using a different script name?

If your main Streamlit script is not named app.py, update the filename in the CMD line to match your actual script name.

  • Save Dockerfile.
  • Confirm the file exists by running:
ls Dockerfile

You should see Dockerfile printed in the output.

Don't see Dockerfile?

  • Make sure the file is named exactly Dockerfile with a capital D and no file extension. Some editors add .txt automatically.
  • Check that your terminal is in your project's root directory, the same folder that contains requirements.txt.
  • Still stuck? Help me find or create my Dockerfile in the right location.

✔️ Awesome, I've got everything!

Great. Make sure you have saved Dockerfile before moving on.

ⓧ I'd like to double check the full code

Here is the complete Dockerfile for comparison:

FROM python:3.12-slim

WORKDIR /app

RUN apt-get update && apt-get install -y \
    build-essential \
    curl \
    && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

ENV PORT=8501

EXPOSE 8501

HEALTHCHECK CMD curl --fail http://localhost:$PORT/_stcore/health

CMD streamlit run app.py --server.port=$PORT --server.address=0.0.0.0 --server.headless=true

Next you need a .dockerignore file. This works like .gitignore but for Docker. It tells Docker which files to skip when copying your project into the container, keeping the image small and preventing secrets from being baked in.

  • Create a file named .dockerignore in your project's root directory (the same folder as Dockerfile) and add the following content:
.git
.gitignore
__pycache__
*.pyc
*.pyo
.env
.venv
venv
env
*.md
.streamlit/secrets.toml
.github

What does .dockerignore do?

Each line is a pattern Docker will skip during COPY . .. The .env and .streamlit/secrets.toml entries prevent your API key from ever being baked into the image.

Virtual environment folders (.venv, venv, env) and cache files (__pycache__) are excluded because the container installs its own clean dependencies from requirements.txt.

  • Save .dockerignore.

✔️ Awesome, I've got everything!

Great. Make sure .dockerignore is saved in your project's root directory.

ⓧ I'd like to double check the full code

Here is the complete .dockerignore for comparison:

.git
.gitignore
__pycache__
*.pyc
*.pyo
.env
.venv
venv
env
*.md
.streamlit/secrets.toml
.github

Finally, you need a Streamlit config file that tells Streamlit to run in headless mode. Without this, Streamlit tries to open a browser window inside the container, which fails.

  • Create a .streamlit folder in your project's root directory if it does not already exist. Then create a file named config.toml inside it and add the following content:
[server]
headless = true

[browser]
gatherUsageStats = false

What does this config do?

  • headless = true stops Streamlit from trying to auto-open a browser. Containers do not have a desktop environment, so this prevents a startup error.
  • gatherUsageStats = false disables anonymous usage statistics for a cleaner production setup.
  • Save config.toml.
  • Confirm all three new files exist by running:
ls Dockerfile .dockerignore .streamlit/config.toml

You should see all three file paths printed without any errors.

✔️ Awesome, I've got everything!

Great. Make sure config.toml is saved inside the .streamlit folder.

ⓧ I'd like to double check the full code

Here is the complete .streamlit/config.toml for comparison:

[server]
headless = true

[browser]
gatherUsageStats = false
Build the Docker image

Your recipe is written. Now Docker needs to follow it to create the actual image. Think of building as Docker reading your Dockerfile line by line, executing each instruction, and saving the result as a portable snapshot of your app.

  • Build the Docker image by running this command in your project's root directory:
docker build -t dashboard-app .

What does this command do?

  • docker build tells Docker to read the Dockerfile and build an image from it.
  • -t dashboard-app gives the image the name dashboard-app so you can reference it later.
  • The . at the end tells Docker to use the current directory as the build context (where to find the Dockerfile and your app files).

The first build takes a few minutes as Docker downloads the python:3.12-slim base image and installs your dependencies. You will see each Dockerfile instruction execute in the terminal output.

  • Wait for the build to complete. The final lines should show a success message with your image tagged as dashboard-app.
  • Confirm the image exists by running:
docker images dashboard-app

You should see a row listing dashboard-app with its image ID and size.

Build failed?

  • If you see a "no such file or directory" error for requirements.txt, make sure your terminal is in the same folder as your Dockerfile and requirements.txt.
  • If pip install fails for a specific package, check that your requirements.txt does not contain any packages that only work on Windows. Remove those entries and rebuild.
  • If Docker itself is not found, make sure Docker Desktop is running. You can check the system tray for the Docker whale icon.
  • Still stuck? Help me debug my Docker build error.
Run the container locally

Your image is built. Now you can start a live container from it, passing your Gemini API key in as an environment variable. This is exactly how cloud platforms like Render will run your app.

  • Start a container from your image by running this command:
docker run -p 8501:8501 -e GOOGLE_API_KEY=your-api-key-here dashboard-app

What does this command do?

  • -p 8501:8501 maps port 8501 inside the container to port 8501 on your machine. This lets your browser reach the Streamlit app running inside the container.
  • -e GOOGLE_API_KEY=your-api-key-here passes the API key into the container's environment at runtime. Replace your-api-key-here with your actual Gemini API key. The key is never baked into the image.

Your terminal is now taken over

The docker run command keeps the container running in the foreground, so your terminal will show Streamlit logs. Leave it running and open a browser in a separate window.

Before you open the browser, think about what you expect to see. Your entire app, its dependencies, and its Python runtime are all inside the container now. Should it look any different from when you ran the app directly?

  • Open http://localhost:8501 in your browser.

Your AI Dashboard Builder loads and works identically to when you ran it directly with streamlit run. That is the entire point of containerization. The app does not know or care that it is running inside Docker.

  • Upload a test file and confirm the AI analysis features respond.

App not loading in the browser?

  • If the page does not load, check your terminal for error messages. A common cause is port 8501 already being used by another Streamlit instance. Stop any other Streamlit processes first.
  • If the app loads but AI features fail, double-check that you replaced your-api-key-here with your actual Gemini API key in the docker run command.
  • If the container exited immediately, run docker logs followed by the container ID to see what went wrong. The container ID appears in the terminal output when you ran docker run.
  • Still stuck? Help me get my Dockerized Streamlit app running locally.

Your app is now running inside a portable container. Anyone with Docker installed could run the exact same image and get the exact same result. Next up, you will push this container to Render so the whole world can reach it through a public URL.

Deploy to Render

Your Streamlit app runs perfectly inside a Docker container. You proved that in the last step by running it locally and testing every feature.

The problem is that only you can access it. Render hosts your Docker image on the internet with a public URL, handling networking and TLS certificates for you.

In this step, get ready to:
  • Push your Docker configuration files to GitHub.
  • Create a web service on Render from your repository.
  • Visit your app's public URL for the first time.
Push your Docker files to GitHub

Your Dockerfile, .dockerignore, and .streamlit/config.toml exist only on your local machine right now. GitHub needs these files so that Render can pull them when it builds your image.

  • Add the Docker configuration files to your repository and push them to GitHub by running these commands:
git add Dockerfile .dockerignore .streamlit/config.toml
git commit -m "Add Docker configuration for production deployment"
git push origin main

What do these commands do?

  • git add stages the three new files so Git knows to include them in the next commit.
  • git commit saves a snapshot of the staged files with a descriptive message.
  • git push origin main sends the commit to your GitHub repository on the main branch.
  • You should see output confirming the push to origin/main. Your Docker files are now on GitHub.

Push failed?

  • If you see a "not a git repository" error, make sure your terminal is inside your project folder.
  • If you get an authentication error, confirm your GitHub credentials are set up correctly. You may need to use a personal access token instead of a password.
  • If Git says there is nothing to commit, the files may already be tracked. Run git status to check.

Still stuck? Help me troubleshoot my git push to GitHub.

Create a Render web service

With your Docker files on GitHub, Render can pull your repository and build the image automatically.

  • Return to the Render Dashboard at https://dashboard.render.com.
  • Click + New in the top-right corner.
  • Select Web Service.
  • Select your AI Dashboard Builder GitHub repository from the list.
  • In the Language field, select Docker.
  • Under instance type, choose Free.
  • Click Create Web Service.

Why set Language to Docker?

Your app is written in Python, but you want Render to build it using your Dockerfile instead of its built-in Python runtime. Setting the Language to Docker tells Render to look for a Dockerfile in your repository and use it to build the image.

Render starts building your Docker image immediately. You can see the build logs streaming on the service's Events page.

What is happening during the build?

Render clones your repository, reads your Dockerfile, and builds the image using BuildKit. This is the same process you ran locally with docker build, but it happens on Render's servers instead of your machine.

The build takes 2-4 minutes as Render downloads the Python base image, installs your dependencies, and copies your app code.

Watch the build and open your live URL
  • Watch the build logs on the Events page in the Render Dashboard until the build completes.

When the build finishes, Render starts your container and assigns it a public URL. You can find this URL at the top of your service page. It follows the format your-service-name.onrender.com.

Before you click the URL, what do you think you will see? Will your AI Dashboard Builder load and work perfectly?

  • Click your service URL at the top of the page to open your app in a new tab.

The app either crashes on startup or loads but fails when you try the AI features. This is not a bug in your code.

Why did this happen?

When you ran the container locally, you passed your API key using the -e GOOGLE_API_KEY=... flag. That flag only applied to your local docker run command.

Render's environment is a completely separate machine. It has no access to your local environment variables. The GOOGLE_API_KEY does not exist there because you never configured it in Render. You can confirm this by checking the deploy logs on the Events page, where you will see errors related to the missing API key or failed authentication.

Build itself failed?

If the build did not complete at all (before the app even tried to start), check these common causes:

  • Make sure your requirements.txt was pushed to GitHub. Run git status to check. If it was not committed, add and push it.
  • Confirm that the Language field in your Render service is set to Docker, not Python or another option.
  • Check that your Dockerfile has no typos. Compare it against the version you tested locally.

Help me troubleshoot my Render build failure.

Your app is deployed but broken. That missing API key is exactly what the next step fixes.

Configure Secrets and Go Live

In the last step, you deployed your app to Render and hit a wall. The build succeeded, but the app either crashed on startup or failed when you tried the AI features.

The missing piece is your Gemini API key. It exists on your local machine but not in Render's environment. In this step, you will configure the key securely in Render and bring your app fully online.

In this step, get ready to:
  • Add the Gemini API key to Render's secure environment variables.
  • Verify the live app works end to end in production.
Add the API key in Render

Your app reads the Gemini API key from an environment variable called GOOGLE_API_KEY. Locally, you passed this with the -e flag when running the container. In Render, you configure environment variables through the dashboard instead.

  • In the Render Dashboard, click on your service name to open its detail page.
  • Click Environment in the left pane.
  • Under Environment Variables, click + Add Environment Variable.
  • In the Key field, enter GOOGLE_API_KEY.
  • In the Value field, paste your actual Gemini API key.
  • From the save dropdown, select Save, rebuild, and deploy.

Render immediately triggers a new build and deploy with your environment variable injected. Watch the deploy logs to track the progress.

Why inject secrets at runtime?

Anything baked into a Docker image lives in every copy of that image. If you push the image to a registry or share it, the key goes with it.

Environment variables injected at runtime stay outside the image and your Git history. You can rotate keys without rebuilding the image or changing any code.

Can't find the Environment tab?

Make sure you clicked on your service name first, not on the overall Render Dashboard home page. The Environment tab appears in the left pane only after you open a specific service.

If you do not see the + Add Environment Variable button, scroll down within the Environment page. It sits under the Environment Variables heading.

Still stuck? Help me find where to add environment variables in Render.

Verify the live app

The deploy takes 2-3 minutes. Once it finishes, your app has the API key available in its runtime environment.

Before you open the URL, think about this: will the AI features work this time? What changed between the failed deploy and this one?

  • In the Render Dashboard, wait for the latest deploy to show a completed status.
  • Click your service URL (it ends in .onrender.com).

Your AI Dashboard Builder loads completely this time. The GOOGLE_API_KEY environment variable now exists inside the container, so the Gemini-powered features can authenticate.

  • Upload a test CSV file and run the AI analysis to confirm the Gemini-powered features work.
  • Test the drag-and-drop panels and try exporting a dashboard.
  • Copy the URL and open it in a different browser or an incognito window to confirm anyone with the link can access your app.

Every feature that worked locally now works on the live site. Your app is deployed to production.

Why test in incognito?

Opening the URL in a different browser or incognito window proves the app is truly public. It simulates what another person would see when they visit your link, with no cached data or saved sessions from your development work.

App still not loading?

Check the deploy logs in the Render Dashboard for error messages. A failed status means the build or start command encountered an issue.

Confirm the Key field is exactly GOOGLE_API_KEY with no extra spaces. A mismatched key name means your app cannot find the value.

Make sure you pasted the full API key with no missing characters. If you are unsure, delete the variable, re-add it, and select Save, rebuild, and deploy again.

Free tier services spin down after 15 minutes of inactivity. The first request after a spin-down takes about a minute to respond. Wait and try again.

Still stuck? My Render deploy completed but the app still shows errors when I use the AI features.

Your AI Dashboard Builder is live on the internet for anyone to use. Next up, you will experience continuous deployment by pushing a code change and watching your live site update automatically.

Experience Continuous Deployment

Your AI Dashboard Builder is live on the internet with a working API key. Anyone with your Render URL can open the app and use every feature you built.

Updating the app is a different story. If you want to change a feature or fix a bug, you would have to manually rebuild and redeploy every single time.

Render eliminates that manual step with continuous deployment. It watches your GitHub repository and automatically rebuilds whenever you push new code to the main branch.

In this step, get ready to:
  • Make a visible change to your Streamlit app.
  • Push the change to GitHub and watch Render auto-deploy.
  • Confirm the update is live without any manual intervention.
Make a visible change to your app

To prove the deployment pipeline updates your live app automatically, you need a visible change that you can spot on the live site after a push.

  • Open your main Streamlit script (app.py or whatever your file is named) in your code editor.
  • Find the section of your code where the sidebar is defined.
  • Add this line near the top of your sidebar code:
# Version label for cloud deployment
st.sidebar.caption("v2.0 - Cloud Edition")

What does this code do?

st.sidebar.caption() adds a small text caption to the sidebar. This gives you a visible marker that proves the auto-deploy worked when you check the live site later.

  • Save app.py.
Push and watch the auto-deploy

Your change is saved locally. Now you need to push it to GitHub so Render can pick it up.

  • Commit and push your change to GitHub by running these commands:
git add .
git commit -m "Update app for cloud deployment"
git push origin main

What do these commands do?

  • git add . stages all changed files for commit.
  • git commit -m "Update app for cloud deployment" creates a snapshot of your changes with a descriptive message.
  • git push origin main sends your commit to your GitHub repository. Render watches this repository and starts a new build as soon as it detects the push.
  • Switch back to the Render Dashboard in your browser.
  • Open your service's page.

Within seconds, Render detects the new commit and starts a new build. You can see your commit message in the build logs.

  • Watch the build logs until the deploy completes. The rebuild takes 2-3 minutes.

Build not starting?

  • Confirm your Render service has auto-deploy enabled. In your service's Settings page, check that the Auto-Deploy option is enabled.
  • Make sure you pushed to the main branch. Render only watches the branch you connected during service creation.
  • Why isn't Render detecting my GitHub push and starting a build?
Confirm the live update

The build has finished and Render deployed your updated container.

  • Before you refresh the page, think about what you expect to see on the live site. What should be different from last time you visited?
  • Click your service URL in the Render Dashboard (your-service-name.onrender.com) to open the live app.

The sidebar now shows the "v2.0 - Cloud Edition" caption you just added. You pushed code to GitHub, and minutes later your production app updated automatically.

What is continuous deployment?

You just experienced the full CI/CD loop in action. Continuous deployment means every code change that reaches your main branch is automatically built, tested, and released to production.

The path from code change to production update is fully automated. No manual rebuilds, no manual triggers, no manual uploads.

  • Copy the URL and open it in a different browser or an incognito window to confirm anyone with the link can access your updated app.

Don't see your change?

  • The deploy may still be in progress. Check the Render Dashboard for the deploy status before refreshing.
  • Try a hard refresh in your browser (Ctrl+Shift+R on Windows) to bypass any cached content.
  • If the app shows an error page, check the deploy logs in the Render Dashboard for build failures. A syntax error in your code change can cause the container to crash on startup.
  • I pushed my code but my Render app does not show the changes I made.

Secret mission

Add a CI Pipeline with GitHub Actions

Right now, every push to GitHub goes straight to production. If you accidentally push broken code, your live app breaks. In this Secret Mission, you'll add a GitHub Actions CI pipeline that runs linting and build checks before Render deploys, transforming your workflow from "push and pray" to "push, verify, then deploy."

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses Render's free tier, so there are no ongoing monetary costs beyond local disk space consumed by Docker images.

Resources you used:

  • Render free web service (hosted at your-service-name.onrender.com, $0/month, spins down after 15 minutes without traffic).
  • Docker images stored locally on your machine (dashboard-app and hello-world).

Keep everything running

No action needed. Choose this if you are still actively building or want to keep your app accessible.

  • Your Render service stays live at no cost. It automatically sleeps after 15 minutes without inbound traffic and wakes when someone visits the URL.
  • You get 750 free instance hours per month, which is plenty for a personal project.
  • Docker images remain on your local machine. They consume disk space but do not incur any charges.

Pause - I'll come back to this later

Stop your Render service to free up instance hours while keeping your configuration intact.

  • In the Render Dashboard at https://dashboard.render.com, click your service.
  • Click Suspend Service to stop the service entirely.
  • You can resume the service anytime from the same page.
  • Docker images on your local machine can stay as they are. They do not consume any resources while idle.

Delete - I don't want to use this again

Remove all project resources and start fresh.

  • In the Render Dashboard at https://dashboard.render.com, open your service and delete it to remove it from Render entirely.
  • Remove the Docker images from your local machine and reclaim disk space by running these commands in your terminal:
docker image rm dashboard-app
docker image rm hello-world
  • Reclaim additional space from unused containers, networks, and dangling images by running:
docker system prune

What does docker system prune do?

This command removes all unused containers, networks, and dangling images from your machine. It frees up disk space that Docker accumulated during builds and test runs throughout this project.

That's a Wrap!

That's a Wrap!

Nice work! You've taken your AI Dashboard Builder from running on your local machine to live on the internet, accessible to anyone with a link.

You've learned how to:

  • Containerized a Streamlit app with Docker, creating a portable image that runs identically on any machine.
  • Deployed the containerized app to Render with a public URL and configured secure environment variables to keep your API key out of source code and Git history.
  • Experienced continuous deployment by pushing a code change to GitHub and watching the live site update automatically within minutes.
  • Completed an optional Secret Mission to push your skills even further.

Ready to quiz yourself?