Run any Skill in Manus with one click

streamlit-private-configure

Stars0

Forks0

UpdatedJune 4, 2026 at 20:21

Reconfigure an existing streamlit-private project — switch the auth provider (e.g. Clerk → WorkOS) or hosting provider (e.g. Railway → Render), or regenerate deployment assets, while preserving the user's application code. Use when the user wants to "change auth provider", "switch hosting", or "regenerate my streamlit-private config".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

DecisionNerd

DecisionNerd/streamlit-private

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	streamlit-private-configure
description	Reconfigure an existing streamlit-private project — switch the auth provider (e.g. Clerk → WorkOS) or hosting provider (e.g. Railway → Render), or regenerate deployment assets, while preserving the user's application code. Use when the user wants to "change auth provider", "switch hosting", or "regenerate my streamlit-private config".

streamlit-private: configure

Reconfigure an already-initialized project by running streamlit-private init --force. This regenerates the manifest and generated assets for new provider choices without changing the user's application code.

When to use

The repo already has a streamlit-private.yaml and the user wants to switch the auth provider (Clerk → WorkOS / Auth0) or hosting provider (Railway → Render / Fly.io).
The user wants to regenerate or upgrade the generated deployment assets.

If the repo is not yet initialized, use streamlit-private-init instead.

Hard rules

Preserve application code. --force regenerates only generated assets and the manifest; it must never modify the user's Streamlit pages or business logic. Do not edit app files yourself.
Do not reimplement the CLI. Run the command; do not hand-edit the manifest or assets.
--force is destructive to generated files only. Confirm with the user which providers they want before running it.

Steps

Confirm the repo is already initialized (a streamlit-private.yaml exists). If not, switch to the streamlit-private-init skill.
Ask the user which providers they want (auth and/or hosting) if they haven't said.
Run:
```
uvx streamlit-private init --force
```
and answer the provider prompts with the user's choices (or surface the prompts to them).
Confirm what changed: report the new auth/hosting providers from streamlit-private.yaml and remind the user to update provider secrets in .env.example / their host's environment variables.
Suggest re-deploying with the streamlit-private-deploy skill so the new configuration takes effect.

Notes

Switching providers is a configuration + regenerate operation, never an application rewrite.
New provider secrets are usually required after a switch; the deploy step will need them set on the hosting provider.

More from this repository

same repository

streamlit-private-deploy

DecisionNerd/streamlit-private

Deploy a streamlit-private project to a managed host (Railway first; Render/Fly.io later) and return the private, authenticated URL. Use when the user wants to "deploy my Streamlit app", "ship it", "put it online privately", or "deploy to Railway".

2026-06-050

streamlit-private-access-requests

DecisionNerd/streamlit-private

List and act on pending access requests for a privately deployed Streamlit app — approve (add the user to the organization) or reject them via streamlit-private. Use when the user (an admin) wants to "approve access requests", "see who's requested access", or "let someone in".

2026-06-040

streamlit-private-init

DecisionNerd/streamlit-private

Initialize a Streamlit app for private deployment with streamlit-private — scaffold a new app or wrap an existing Streamlit repo, adding a gateway, deployment assets, and a manifest without touching application code. Use when the user wants to "make my Streamlit app private", "set up streamlit-private", or "add auth to my Streamlit app".

2026-06-040

streamlit-private-invite

DecisionNerd/streamlit-private

Invite a user to a privately deployed Streamlit app's organization via streamlit-private, so they become a member and gain access. Use when the user (an admin) wants to "invite someone", "add a user", or "give my colleague access" to the app.

2026-06-040

streamlit-private-troubleshoot

DecisionNerd/streamlit-private

Diagnose a failed streamlit-private deployment or broken private access — missing provider secrets, proxy/WebSocket issues, auth/membership problems, or a misconfigured manifest. Use when the user says "my deploy failed", "the app won't load", "sign-in is broken", or "the page is blank / keeps reconnecting".

2026-06-040

name	streamlit-private-configure
description	Reconfigure an existing streamlit-private project — switch the auth provider (e.g. Clerk → WorkOS) or hosting provider (e.g. Railway → Render), or regenerate deployment assets, while preserving the user's application code. Use when the user wants to "change auth provider", "switch hosting", or "regenerate my streamlit-private config".

streamlit-private: configure

When to use

The repo already has a streamlit-private.yaml and the user wants to switch the auth provider (Clerk → WorkOS / Auth0) or hosting provider (Railway → Render / Fly.io).
The user wants to regenerate or upgrade the generated deployment assets.

If the repo is not yet initialized, use streamlit-private-init instead.

Hard rules

Preserve application code. --force regenerates only generated assets and the manifest; it must never modify the user's Streamlit pages or business logic. Do not edit app files yourself.
Do not reimplement the CLI. Run the command; do not hand-edit the manifest or assets.
--force is destructive to generated files only. Confirm with the user which providers they want before running it.

Steps

Confirm the repo is already initialized (a streamlit-private.yaml exists). If not, switch to the streamlit-private-init skill.
Ask the user which providers they want (auth and/or hosting) if they haven't said.
Run:
```
uvx streamlit-private init --force
```
and answer the provider prompts with the user's choices (or surface the prompts to them).
Confirm what changed: report the new auth/hosting providers from streamlit-private.yaml and remind the user to update provider secrets in .env.example / their host's environment variables.
Suggest re-deploying with the streamlit-private-deploy skill so the new configuration takes effect.

Notes

Switching providers is a configuration + regenerate operation, never an application rewrite.
New provider secrets are usually required after a switch; the deploy step will need them set on the hosting provider.