Apache-2.0 Python framework for turning scripts into interactive data apps, dashboards, reports, chat apps, multipage tools, and deployable analytical interfaces.
by Streamlit · submitted by oktofeesh1·added 2026-06-04·
Streamlit apps execute Python scripts and rerun code from top to bottom on user interaction or code changes, so destructive writes, API calls, database mutations, long jobs, and side effects need explicit guards., Cached data can be global across users, sessions, and reruns, while Session State is scoped to a browser session; teams should avoid accidentally sharing user-specific or sensitive data through global caches., The Streamlit security docs warn that `st.cache_data` and `st.session_state` use Python pickle internally, and that malicious pickle data can execute arbitrary code during unpickling., Cached resources such as database connections and ML models can be shared globally and must be thread-safe, or should be scoped per session when isolation is required., Secrets should not be committed to repositories; Streamlit supports environment variables, local or project secrets files, and platform-specific secret storage., OIDC authentication identifies users but does not provide authorization or delegated OAuth access by itself, so apps still need explicit permission checks for admin actions and user-specific data., Custom components, embedded HTML, iframes, JavaScript, media, file uploaders, and third-party packages should be treated as trusted app code and reviewed before public deployment., Chat elements and LLM integrations can call external APIs and stream long-running responses, so prompts, attachments, generated outputs, rate limits, and provider credentials need operational limits.
Privacy notes
Streamlit apps can process Python source, widget inputs, uploaded files, session state, cached results, DataFrames, SQL queries, database rows, charts, maps, chat prompts, logs, and rendered outputs., Secrets can be loaded from `st.secrets`, TOML files, environment variables, deployment settings, or third-party secret managers; these values should stay out of source control, screenshots, app output, and logs., Community Cloud and other hosted deployment paths can involve GitHub account connection, source repository access, app metadata, runtime logs, dependency installation, secrets configuration, and platform-specific retention policies., OIDC login stores identity information and an identity cookie for the app session; user profile fields, login status, and authorization decisions should be treated as sensitive app data., Global caches, global resources, and persisted session data can expose values across users or reruns if the app does not separate public, shared, and user-specific data deliberately., Custom components, embedded iframes, external APIs, databases, warehouses, LLM providers, and analytics services may receive user inputs, prompts, query results, browser metadata, or credentials depending on app design.
Author
Streamlit
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-04
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
78
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Complete
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
Registry metadata indicates a reviewed listing.
Done
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
8 safety and 6 privacy notes across 2 risk areas. Review closely: credentials & tokens, network access.
2 areas
SafetyNetwork accessStreamlit apps execute Python scripts and rerun code from top to bottom on user interaction or code changes, so destructive writes, API calls, database mutations, long jobs, and side effects need explicit guards.
SafetyCredentials & tokensCached data can be global across users, sessions, and reruns, while Session State is scoped to a browser session; teams should avoid accidentally sharing user-specific or sensitive data through global caches.
SafetyCredentials & tokensThe Streamlit security docs warn that `st.cache_data` and `st.session_state` use Python pickle internally, and that malicious pickle data can execute arbitrary code during unpickling.
SafetyCredentials & tokensCached resources such as database connections and ML models can be shared globally and must be thread-safe, or should be scoped per session when isolation is required.
SafetyCredentials & tokensSecrets should not be committed to repositories; Streamlit supports environment variables, local or project secrets files, and platform-specific secret storage.
SafetyCredentials & tokensOIDC authentication identifies users but does not provide authorization or delegated OAuth access by itself, so apps still need explicit permission checks for admin actions and user-specific data.
SafetyNetwork accessCustom components, embedded HTML, iframes, JavaScript, media, file uploaders, and third-party packages should be treated as trusted app code and reviewed before public deployment.
SafetyCredentials & tokensChat elements and LLM integrations can call external APIs and stream long-running responses, so prompts, attachments, generated outputs, rate limits, and provider credentials need operational limits.
PrivacyCredentials & tokensStreamlit apps can process Python source, widget inputs, uploaded files, session state, cached results, DataFrames, SQL queries, database rows, charts, maps, chat prompts, logs, and rendered outputs.
PrivacyCredentials & tokensSecrets can be loaded from `st.secrets`, TOML files, environment variables, deployment settings, or third-party secret managers; these values should stay out of source control, screenshots, app output, and logs.
PrivacyCredentials & tokensCommunity Cloud and other hosted deployment paths can involve GitHub account connection, source repository access, app metadata, runtime logs, dependency installation, secrets configuration, and platform-specific retention policies.
PrivacyCredentials & tokensOIDC login stores identity information and an identity cookie for the app session; user profile fields, login status, and authorization decisions should be treated as sensitive app data.
PrivacyCredentials & tokensGlobal caches, global resources, and persisted session data can expose values across users or reruns if the app does not separate public, shared, and user-specific data deliberately.
PrivacyCredentials & tokensCustom components, embedded iframes, external APIs, databases, warehouses, LLM providers, and analytics services may receive user inputs, prompts, query results, browser metadata, or credentials depending on app design.
Disclosure: editorial
Safety notes
Streamlit apps execute Python scripts and rerun code from top to bottom on user interaction or code changes, so destructive writes, API calls, database mutations, long jobs, and side effects need explicit guards.
Cached data can be global across users, sessions, and reruns, while Session State is scoped to a browser session; teams should avoid accidentally sharing user-specific or sensitive data through global caches.
The Streamlit security docs warn that `st.cache_data` and `st.session_state` use Python pickle internally, and that malicious pickle data can execute arbitrary code during unpickling.
Cached resources such as database connections and ML models can be shared globally and must be thread-safe, or should be scoped per session when isolation is required.
Secrets should not be committed to repositories; Streamlit supports environment variables, local or project secrets files, and platform-specific secret storage.
OIDC authentication identifies users but does not provide authorization or delegated OAuth access by itself, so apps still need explicit permission checks for admin actions and user-specific data.
Custom components, embedded HTML, iframes, JavaScript, media, file uploaders, and third-party packages should be treated as trusted app code and reviewed before public deployment.
Chat elements and LLM integrations can call external APIs and stream long-running responses, so prompts, attachments, generated outputs, rate limits, and provider credentials need operational limits.
Privacy notes
Streamlit apps can process Python source, widget inputs, uploaded files, session state, cached results, DataFrames, SQL queries, database rows, charts, maps, chat prompts, logs, and rendered outputs.
Secrets can be loaded from `st.secrets`, TOML files, environment variables, deployment settings, or third-party secret managers; these values should stay out of source control, screenshots, app output, and logs.
Community Cloud and other hosted deployment paths can involve GitHub account connection, source repository access, app metadata, runtime logs, dependency installation, secrets configuration, and platform-specific retention policies.
OIDC login stores identity information and an identity cookie for the app session; user profile fields, login status, and authorization decisions should be treated as sensitive app data.
Global caches, global resources, and persisted session data can expose values across users or reruns if the app does not separate public, shared, and user-specific data deliberately.
Custom components, embedded iframes, external APIs, databases, warehouses, LLM providers, and analytics services may receive user inputs, prompts, query results, browser metadata, or credentials depending on app design.
Prerequisites
Python environment with Streamlit and project dependencies installed for the selected local, Codespaces, Snowflake, Community Cloud, or self-hosted deployment path.
App architecture plan for Streamlit's top-to-bottom rerun model, widgets, forms, fragments, callbacks, Session State, caching, multipage routing, and long-running operations.
Data and connection plan for local files, DataFrames, SQL databases, Snowflake, APIs, credentials, environment variables, secrets, and external service quotas.
Deployment plan for dependency installation, remote `streamlit run`, secrets handling, configuration, authentication, authorization, static assets, logging, and app sharing.
Security review for custom components, embedded HTML or iframes, chat or LLM integrations, uploaded files, user-specific state, and public-facing app permissions.
## Editorial notes
Streamlit is useful when Claude-adjacent teams need quick internal tools, data review apps, dashboard prototypes, evaluation viewers, report generators, LLM demos, and analytical interfaces without building a full frontend stack. Its Python-first execution model makes it straightforward for agents and developers to generate, inspect, test, and iterate on app code that stays close to the underlying data workflow.
This entry covers the open-source Streamlit framework. It is distinct from Marimo, Gradio, Chainlit, DuckDB, and Polars. Marimo focuses on reactive notebooks that are stored as pure Python and can run as scripts or apps. Gradio focuses on machine-learning demos and model interfaces. Chainlit focuses on conversational AI apps. DuckDB is an embedded analytical SQL database. Polars is a DataFrame query engine. Streamlit focuses on turning Python scripts into interactive web apps for data, dashboards, reports, chat, and internal tools.
## Source notes
- The official repository describes Streamlit as a faster way to build and share data apps.
- The README says Streamlit transforms Python scripts into interactive web apps and can be used for dashboards, reports, and chat apps.
- The README highlights Pythonic development, fast interactive prototyping, live editing, widgets, DataFrames, charts, layouts, multipage apps, the app gallery, Streamlit Components, Community Cloud, and Apache-2.0 licensing.
- The Get Started docs cover installation on Windows, macOS, and Linux, as well as browser-based development with GitHub Codespaces or Streamlit in Snowflake.
- The Get Started docs say the fundamentals cover displaying and styling data, charts and maps, interactive widgets, layouts, caching, and themes.
- The caching docs say Streamlit reruns scripts from top to bottom on user interaction or code change, and that caching helps avoid rerunning long functions or recreating objects.
- The `st.cache_data` API docs say cached data can be global across users, sessions, and reruns or scoped to a current session, and that cached objects are stored in pickled form.
- The `st.cache_resource` API docs say cached resources can be global or session-scoped, global resources are shared across users and reruns, and global resources must be thread-safe.
- The Session State docs say each browser tab is a session, Streamlit reruns scripts on interaction, and Session State persists variables between reruns for a user session and across pages in a multipage app.
- The multipage app docs describe `st.Page`, `st.navigation`, and the simpler `pages/` directory mechanism for creating multiple app pages.
- The secrets-management docs say unencrypted secrets should not be committed to repositories and describe local, project, environment-variable, and platform-specific secret options.
- The security reminders warn about protecting secrets, keeping `.gitignore` updated, and avoiding untrusted pickle data when using `st.cache_data`, `st.session_state`, or deprecated cache behavior.
- The authentication docs say Streamlit supports OIDC with providers such as Google Identity, Microsoft Entra ID, Okta, and Auth0, and explains `st.login`, `st.user`, and `st.logout`.
- The chat elements docs describe `st.chat_input`, `st.chat_message`, `st.status`, and `st.write_stream` for conversational apps and streamed outputs.
- The app testing docs describe headless app tests through `streamlit.testing.v1.AppTest`, including simulated user input and rendered-output inspection that can run with tools such as pytest.
- The deployment docs describe installing Python, Streamlit, and dependencies, securely handling secrets, and remotely starting apps with `streamlit run`.
- The repository is `streamlit/streamlit`, is Apache-2.0 licensed, active, and maintained by the Streamlit project.
## Duplicate check
Checked current `content/tools/`, `content/mcp/`, agents, hooks, rules, skills, commands, guides, collections, open pull requests, live issue state, and repository-wide content for `Streamlit`, `streamlit/streamlit`, `github.com/streamlit/streamlit`, `docs.streamlit.io`, `streamlit.io`, `Python data apps`, `dashboards`, and `chat apps`. Existing mentions are contextual references inside Python data-science rules and the Marimo distinction notes; no dedicated Streamlit tools entry, source URL duplicate, target file, issue duplicate, semantic duplicate, or open duplicate PR was found.
## Disclosure
Editorial listing. No paid placement or affiliate link is used. Streamlit is Apache-2.0 open-source software; Streamlit Community Cloud, Streamlit in Snowflake, Snowflake services, GitHub Codespaces, databases, warehouses, LLM providers, custom components, cloud hosts, and downstream deployment services may have separate licenses, billing, terms, privacy obligations, and access controls.
About this resource
Editorial notes
Streamlit is useful when Claude-adjacent teams need quick internal tools, data review apps, dashboard prototypes, evaluation viewers, report generators, LLM demos, and analytical interfaces without building a full frontend stack. Its Python-first execution model makes it straightforward for agents and developers to generate, inspect, test, and iterate on app code that stays close to the underlying data workflow.
This entry covers the open-source Streamlit framework. It is distinct from Marimo, Gradio, Chainlit, DuckDB, and Polars. Marimo focuses on reactive notebooks that are stored as pure Python and can run as scripts or apps. Gradio focuses on machine-learning demos and model interfaces. Chainlit focuses on conversational AI apps. DuckDB is an embedded analytical SQL database. Polars is a DataFrame query engine. Streamlit focuses on turning Python scripts into interactive web apps for data, dashboards, reports, chat, and internal tools.
Source notes
The official repository describes Streamlit as a faster way to build and share data apps.
The README says Streamlit transforms Python scripts into interactive web apps and can be used for dashboards, reports, and chat apps.
The README highlights Pythonic development, fast interactive prototyping, live editing, widgets, DataFrames, charts, layouts, multipage apps, the app gallery, Streamlit Components, Community Cloud, and Apache-2.0 licensing.
The Get Started docs cover installation on Windows, macOS, and Linux, as well as browser-based development with GitHub Codespaces or Streamlit in Snowflake.
The Get Started docs say the fundamentals cover displaying and styling data, charts and maps, interactive widgets, layouts, caching, and themes.
The caching docs say Streamlit reruns scripts from top to bottom on user interaction or code change, and that caching helps avoid rerunning long functions or recreating objects.
The st.cache_data API docs say cached data can be global across users, sessions, and reruns or scoped to a current session, and that cached objects are stored in pickled form.
The st.cache_resource API docs say cached resources can be global or session-scoped, global resources are shared across users and reruns, and global resources must be thread-safe.
The Session State docs say each browser tab is a session, Streamlit reruns scripts on interaction, and Session State persists variables between reruns for a user session and across pages in a multipage app.
The multipage app docs describe st.Page, st.navigation, and the simpler pages/ directory mechanism for creating multiple app pages.
The secrets-management docs say unencrypted secrets should not be committed to repositories and describe local, project, environment-variable, and platform-specific secret options.
The security reminders warn about protecting secrets, keeping .gitignore updated, and avoiding untrusted pickle data when using st.cache_data, st.session_state, or deprecated cache behavior.
The authentication docs say Streamlit supports OIDC with providers such as Google Identity, Microsoft Entra ID, Okta, and Auth0, and explains st.login, st.user, and st.logout.
The chat elements docs describe st.chat_input, st.chat_message, st.status, and st.write_stream for conversational apps and streamed outputs.
The app testing docs describe headless app tests through streamlit.testing.v1.AppTest, including simulated user input and rendered-output inspection that can run with tools such as pytest.
The deployment docs describe installing Python, Streamlit, and dependencies, securely handling secrets, and remotely starting apps with streamlit run.
The repository is streamlit/streamlit, is Apache-2.0 licensed, active, and maintained by the Streamlit project.
Duplicate check
Checked current content/tools/, content/mcp/, agents, hooks, rules, skills, commands, guides, collections, open pull requests, live issue state, and repository-wide content for Streamlit, streamlit/streamlit, github.com/streamlit/streamlit, docs.streamlit.io, streamlit.io, Python data apps, dashboards, and chat apps. Existing mentions are contextual references inside Python data-science rules and the Marimo distinction notes; no dedicated Streamlit tools entry, source URL duplicate, target file, issue duplicate, semantic duplicate, or open duplicate PR was found.
Disclosure
Editorial listing. No paid placement or affiliate link is used. Streamlit is Apache-2.0 open-source software; Streamlit Community Cloud, Streamlit in Snowflake, Snowflake services, GitHub Codespaces, databases, warehouses, LLM providers, custom components, cloud hosts, and downstream deployment services may have separate licenses, billing, terms, privacy obligations, and access controls.
Apache-2.0 Python framework for turning scripts into interactive data apps, dashboards, reports, chat apps, multipage tools, and deployable analytical interfaces.
Apache-2.0 reactive Python notebook stored as pure Python for reproducible experiments, SQL-backed data workflows, script execution, app deployment, and AI-assisted editing.
Apache-2.0 Python framework for building production-ready conversational AI apps with chat lifecycles, messages, steps, actions, elements, authentication, persistence, and integrations.
Open-source Python AgentOS and multi-agent framework, evolved from AutoGen, for building conversable agents, group chats, swarms, human-in-the-loop workflows, tool use, RAG, code execution, and provider-backed agent systems.
✓Streamlit apps execute Python scripts and rerun code from top to bottom on user interaction or code changes, so destructive writes, API calls, database mutations, long jobs, and side effects need explicit guards.
Cached data can be global across users, sessions, and reruns, while Session State is scoped to a browser session; teams should avoid accidentally sharing user-specific or sensitive data through global caches.
The Streamlit security docs warn that `st.cache_data` and `st.session_state` use Python pickle internally, and that malicious pickle data can execute arbitrary code during unpickling.
Cached resources such as database connections and ML models can be shared globally and must be thread-safe, or should be scoped per session when isolation is required.
Secrets should not be committed to repositories; Streamlit supports environment variables, local or project secrets files, and platform-specific secret storage.
OIDC authentication identifies users but does not provide authorization or delegated OAuth access by itself, so apps still need explicit permission checks for admin actions and user-specific data.
Custom components, embedded HTML, iframes, JavaScript, media, file uploaders, and third-party packages should be treated as trusted app code and reviewed before public deployment.
Chat elements and LLM integrations can call external APIs and stream long-running responses, so prompts, attachments, generated outputs, rate limits, and provider credentials need operational limits.
✓Marimo notebooks execute Python and SQL, can write files, query databases, call APIs, access object storage, install packages, and start web servers, so notebooks should be treated as trusted project code.
Reactive execution automatically tracks variable dependencies and can run downstream cells after upstream changes; expensive, destructive, or side-effectful cells need lazy runtime, disabled cells, startup autorun, and manual-run policies.
The docs note that Marimo tracks variable definitions and references statically, not arbitrary mutations across cells, so mutable shared state should be designed carefully to avoid misleading results.
App mode uses `marimo run` to serve notebooks as web apps with code hidden by default, but public deployments still need authentication, authorization, rate limiting, reverse proxy policy, and traceback disclosure review.
Disabling token protection, passing access tokens in URLs, or exposing edit servers can give unauthorized users access to notebook execution and should be avoided outside controlled environments.
SQL cells can interpolate Python values, query local files and remote databases, and use engines or extensions such as DuckDB, so SQL strings, credentials, object paths, and output destinations should be reviewed before automation.
Built-in AI and copilot features may inspect notebook code, prompts, tool context, and referenced variable values; provider selection, API keys, local model behavior, and cost controls should be configured deliberately.
Package-management features can serialize requirements and auto-install dependencies into notebook-specific environments, so teams should pin, review, and scan packages before sharing or deploying notebooks.
✓Chainlit apps run Python code in response to user chat events, actions, lifecycle hooks, MCP tool calls, and integrations, so app functions should be treated as trusted server code.
The docs say Chainlit applications are public by default; private apps require an authentication secret and at least one authentication callback.
Authentication identifies users, but app code still needs explicit authorization checks for admin controls, private chat history, user-specific data, file access, and external tool execution.
Steps can expose intermediate reasoning, tool inputs, tool outputs, and chain-of-thought-style traces depending on configuration, so production apps should decide whether to show full steps, only tool calls, or hide them.
Actions trigger Python callbacks from clickable UI controls, and Ask APIs can block code while requesting text, files, actions, or forms; handlers should validate user input and guard side effects.
MCP support can connect to SSE, streamable HTTP, and stdio tool providers, discover tools, and execute them, so tool permissions, command-line tools, credentials, and network reachability need review.
Deployment docs note that production runs should use headless mode, host binding must be intentional, and Docker deployments commonly need `--host 0.0.0.0`; reverse proxies and websockets need explicit configuration.
Environment variable docs warn against hardcoding API keys and recommend keeping `.env` out of version control; public apps should not ship the maintainer's own provider keys to broad audiences.
✓AG2 agents can converse, call tools, execute code, use retrieval systems, run browser workflows, and coordinate group chats; require explicit permissions and approval gates for high-impact actions.
The upstream install docs and examples commonly involve provider credentials; keep API keys, config files, notebooks, and `.env` files out of commits and support tickets.
Code execution, Docker, Jupyter, browser-use, and RAG extras can touch local files, network services, notebooks, databases, and external websites; scope them tightly before granting agent access.
Multi-agent conversations can continue through nested chats, swarms, group chats, and custom reply handlers; define termination, escalation, retry, and human takeover behavior.
Track the release roadmap before upgrading because deprecations and the v1.0 transition can change which APIs should be used for new work.
Privacy notes
✓Streamlit apps can process Python source, widget inputs, uploaded files, session state, cached results, DataFrames, SQL queries, database rows, charts, maps, chat prompts, logs, and rendered outputs.
Secrets can be loaded from `st.secrets`, TOML files, environment variables, deployment settings, or third-party secret managers; these values should stay out of source control, screenshots, app output, and logs.
Community Cloud and other hosted deployment paths can involve GitHub account connection, source repository access, app metadata, runtime logs, dependency installation, secrets configuration, and platform-specific retention policies.
OIDC login stores identity information and an identity cookie for the app session; user profile fields, login status, and authorization decisions should be treated as sensitive app data.
Global caches, global resources, and persisted session data can expose values across users or reruns if the app does not separate public, shared, and user-specific data deliberately.
Custom components, embedded iframes, external APIs, databases, warehouses, LLM providers, and analytics services may receive user inputs, prompts, query results, browser metadata, or credentials depending on app design.
✓Marimo workflows can process notebook source code, cell outputs, variable values, DataFrames, SQL queries, schemas, database rows, object-store paths, generated apps, CLI arguments, logs, and exported artifacts.
User configuration can store runtime, server, completion, and AI-provider settings, while app configuration can live inside notebook files; secrets should stay in environment variables or secret stores rather than committed notebooks.
AI-assisted editing can send prompts, notebook context, code, schemas, and referenced in-memory values to configured hosted providers, or to local model services when those are selected.
Database and remote-storage workflows can expose connection strings, credentials, table names, bucket names, object keys, query text, sample rows, and download paths to notebooks, logs, cloud services, and deployed apps.
Token login, query-parameter access tokens, Basic auth headers, reverse-proxy headers, and server logs should be handled as sensitive operational data.
✓Chainlit apps can process chat messages, prompts, chat history, steps, tool inputs and outputs, user sessions, uploaded files, elements, human feedback, tags, metadata, logs, API calls, and generated artifacts.
Enabling data persistence stores and uses chat and element data that is otherwise not persisted by default; teams should define retention, deletion, access, export, and monitoring policies.
Authentication can store user identity, unique identifiers, headers, OAuth profile data, login state, and auth tokens that should be scoped and protected as sensitive application data.
The user session is unique to a user and a chat session; shared globals can leak state across users, as the docs warn in their user-session example.
Environment variables, `.env` files, model provider keys, vector database keys, OAuth secrets, MCP credentials, and deployment settings should stay out of committed code, screenshots, logs, and persisted chat artifacts.
Multi-platform deployments such as web app, Copilot embed, Teams, Slack, Discord, custom React frontends, and Chainlit integrations may pass chat content and metadata through additional platforms with separate privacy terms.
✓Prompts, messages, tool arguments, tool outputs, code snippets, notebook state, retrieved documents, vector-store contents, provider responses, traces, and execution logs may contain sensitive user or workspace data.
Do not expose secrets, API keys, private file paths, customer records, internal documents, database rows, or raw exceptions through agent messages, logs, notebooks, screenshots, or public examples.
Provider extras and retrieval integrations can route data through OpenAI, Anthropic, Google, AWS, local model servers, databases, vector stores, browser automation, or other third-party services.
If AG2 is used for code execution or browser automation, define which files, domains, credentials, downloads, screenshots, and logs can be read or retained.
Prerequisites
Python environment with Streamlit and project dependencies installed for the selected local, Codespaces, Snowflake, Community Cloud, or self-hosted deployment path.
App architecture plan for Streamlit's top-to-bottom rerun model, widgets, forms, fragments, callbacks, Session State, caching, multipage routing, and long-running operations.
Data and connection plan for local files, DataFrames, SQL databases, Snowflake, APIs, credentials, environment variables, secrets, and external service quotas.
Deployment plan for dependency installation, remote `streamlit run`, secrets handling, configuration, authentication, authorization, static assets, logging, and app sharing.
Python environment and package-management plan for the selected notebook, app, script, SQL, visualization, and optional AI features.
Notebook execution model for reactive dependency graphs, deterministic cell ordering, lazy or stale runtime behavior, disabled cells, startup autorun, and side-effectful cells.
Data access plan for local files, DataFrames, SQL cells, databases, warehouses, cloud object storage, remote filesystems, environment variables, and credentials.
Deployment and access-control plan for edit servers, read-only apps, token or password protection, reverse proxies, ASGI middleware, public sharing, rate limits, and error reporting.
Python environment with Chainlit, model provider SDKs, vector or database clients, agent frameworks, deployment runtime, and frontend customization dependencies installed as needed.
Chat lifecycle design for `on_chat_start`, `on_message`, messages, steps, actions, elements, commands, user sessions, chat profiles, chat settings, streaming, ask-user flows, and testing.
Authentication and authorization plan for public-by-default apps, `CHAINLIT_AUTH_SECRET`, password auth, OAuth, header auth, user identifiers, admin actions, and user-specific data.
Data plan for chat history, human feedback, data persistence, open-source data layers, tags, metadata, file elements, generated artifacts, and retention policies.
Python 3.10 or newer and a Python environment managed with pip, uv, or another package manager.
Model provider credentials for the selected provider extra, such as OpenAI, Anthropic, Gemini, Bedrock, Mistral, Ollama, Groq, xAI, or another supported route.
A secrets strategy for provider keys, AG2 config files, `.env` files, notebooks, and example `OAI_CONFIG_LIST`-style credentials.
A reviewed execution boundary for code execution, Docker, Jupyter, browser-use, RAG, retrieval, database, and external tool extras.