Snowflake Workspaces give you two ways to work on a Streamlit in Snowflake (SiS) app as a team: shared workspaces, where everyone edits inside Snowsight, and git-backed workspaces, where Git is the syncing mechanism between Snowsight and everyone's local machine. Git-backed workspaces are the better fit when part of your team is comfortable in a terminal and part of your team prefers building visually inside Snowsight.

This guide walks through a single realistic scenario with two collaborators working on the same app:

Both are editing the same streamlit_app.py, in the same repository, on the same branch, and Git is what keeps them in sync.

A small Cortex-powered Streamlit app (prompt pills that call ai_complete()) that ends up with contributions from both a Snowsight-only user and a command-line-only user, deployed as a shared Streamlit in Snowflake app.

The diagram below summarizes how the two personas hand off work through Git over the course of this guide:

Before either collaborator touches the app, someone with elevated privileges connects the Snowflake account to GitHub. This is a one-time, account-wide step; once it's done, any user with USAGE on the resulting objects can create git-backed workspaces against that GitHub organization or user.

Run this as a role that can create secrets in a schema you control (this does not require ACCOUNTADMIN):

This step requires ACCOUNTADMIN, or a role explicitly granted the account-level CREATE INTEGRATION privilege, making it the one part of this guide a typical developer role cannot run:

Scope API_ALLOWED_PREFIXES to your own GitHub username (or org) rather than all of https://github.com, since it's a prefix match: https://github.com/<your_github_username> covers every repository you own.

You can sanity-check that Snowflake can actually reach your fork before going into Snowsight:

SHOW GIT BRANCHES should return your main branch with a commit hash, and LS should list streamlit_app.py, requirements.txt, README.md, and .streamlit/config.toml, the four files in the sample app. This is a throwaway check; drop it once confirmed:

Marcus works entirely from the terminal. He starts by cloning his fork and creating a feature branch that both collaborators will work on:

At this point the branch exists on GitHub with the same four files as main; nothing has changed yet. Pushing an unmodified branch first means Priya has something to select when she creates her workspace in the next section.

Priya has never touched the app before and doesn't use git day-to-day. She does everything from Snowsight.

1. Sign in to Snowsight.

2. In the navigation menu, select Projects » Workspaces.
3. Select Add new » Create new workspace, then choose Git workspace from the menu. This opens the Create workspace from Git repository dialog.

4. Paste the repository URL: https://github.com/<your_github_username>/simple-streamlit-app. The Workspace name field auto-fills from the repo name.
5. From the API integration menu, select github_git_api_integration (or the OAuth integration your admin configured).
6. Choose an authentication method. The dialog offers three:
   • OAuth2: sign in to GitHub directly (default if an OAuth integration is configured)
   • Personal access token: if you followed the Setup section
   • Public repository: no credentials at all, available whenever the repo is public; read-only, so Push stays disabled. This is fine for quickly previewing this guide, but Priya needs OAuth2 or a personal access token to complete the commit-and-push steps below

7. Select Create. Give it a moment, then confirm the workspace actually exists. The UI can show the Files/Changes tabs as if creation succeeded even when it didn't fully persist. If reopening Projects » Workspaces doesn't show it, redo the dialog.
8. Once the workspace opens, use the branch selector at the bottom of the screen (shows main by default) to switch to feature/collab-tutorial, the branch Marcus pushed. If it doesn't appear in the list yet, select Fetch all first to pull the latest remote branches, then look again.

1. Open streamlit_app.py in the file browser. A banner appears: "This file looks like a Streamlit app, but is missing configuration." Clicking plain Run at this point executes the file as a generic Python script and fails with ModuleNotFoundError: No module named 'streamlit', so don't click it yet.

2. Select Convert to Streamlit app from the banner. In the confirmation dialog, leave Move into a new app folder checked and keep the default folder name (or set your own).

3. Confirm. Workspaces moves streamlit_app.py and .streamlit/config.toml into that folder and generates two new files alongside them: pyproject.toml and snowflake.yml (the container-runtime Streamlit app config). All four show up as A (added) in the file tree.

4. Now select Run (or Cmd+Enter / Ctrl+Enter). This launches a private development app that only Priya can see, running on the account's compute pool.
5. Confirm the app loads: a title, an info banner, three example prompt pills, and a text area.

Priya wants to make the app's intro copy clearer. She edits the st.title and st.info lines in streamlit_app/streamlit_app.py (the file's new path after the conversion step above):

becomes:

She saves and re-runs to confirm the new copy shows up in the preview.

1. Select Changes at the top of the folder view.
2. Because the conversion step moved files, this commit includes more than just the copy edit: streamlit_app.py and .streamlit/config.toml show as D (deleted) at the repo root, and streamlit_app/streamlit_app.py, streamlit_app/.streamlit/config.toml, streamlit_app/pyproject.toml, and streamlit_app/snowflake.yml show as A (added). The file move and the new config files are captured in the same set of changes as Priya's copy edit.

3. Enter a commit message, for example: Convert to Streamlit app and clarify intro copy.
4. Select Push.

The change is now on feature/collab-tutorial in GitHub. Marcus hasn't touched his laptop yet, and he already has Priya's change waiting for him.

Back on the command line, Marcus fetches Priya's commit:

He sees Priya's commit (Convert to Streamlit app and clarify intro copy) and notices the file layout changed: streamlit_app.py moved from the repo root into a streamlit_app/ folder, alongside a new pyproject.toml and snowflake.yml. The updated st.info line is now in streamlit_app/streamlit_app.py.

Marcus adds a fourth prompt pill, a code change that's easier for him to make in his own editor than in a browser:

He commits and pushes:

Marcus's commit is on GitHub, but Priya's workspace doesn't have it yet, since Workspaces doesn't auto-sync remote changes.

1. Back in Snowsight, open the workspace and select Changes.
2. Select the down arrow next to Pull, and confirm there are no local uncommitted edits first.
3. Select Pull to fetch and merge Marcus's commit.
4. Open streamlit_app/streamlit_app.py and confirm the fourth prompt pill (What is a Snowflake git-backed workspace?) is now present.

5. Select Run again to confirm the app shows four pills instead of three.

So far, both collaborators have only seen a private development app, Priya's preview and nobody else's. Deploying publishes the current workspace code to a real STREAMLIT object other roles can access.

1. In the workspace's project pane toolbar, select Deploy.
2. Review the settings: app title, target database and schema, compute pool, and the query warehouse.

3. Select Deploy.

Verify from SQL (the app's name is auto-populated from the app folder, streamlit_app, not the repository name):

Keep in mind the split between the two states: editing the workspace code afterward does not change the deployed app until you deploy again, and changing the deployed app's settings does not persist across future deploys. See Streamlit in Snowflake in Workspaces for the full development-app-versus-deployed-app model.

Keep any changes you want to retain in GitHub before removing tutorial resources. Coordinate with your collaborator so neither person loses uncommitted work.

1. Drop the Snowflake objects you created in this guide. Replace <db>.<schema> with the database and schema you picked in the Deploy dialog. The API integration requires ACCOUNTADMIN, the same role you used to create it in Setup. Skip the integration and secret if you used an existing OAuth integration instead.

   USE ROLE ACCOUNTADMIN;
   
   DROP STREAMLIT IF EXISTS <db>.<schema>.STREAMLIT_APP;
   DROP GIT REPOSITORY IF EXISTS my_db.my_schema.simple_streamlit_app_check;
   DROP API INTEGRATION IF EXISTS github_git_api_integration;
   DROP SECRET IF EXISTS my_db.my_schema.github_pat;
   

2. Delete the simple-streamlit-app workspace from Projects » Workspaces once its changes are pushed to GitHub.

3. Delete the feature branch from your fork once you have merged or saved the work you want to keep:

   git push origin --delete feature/collab-tutorial
   

4. Revoke the GitHub personal access token you created for this guide under GitHub » Settings » Developer settings » Personal access tokens.

Congratulations! You've successfully connected a Snowflake account to a GitHub repository, created a git-backed workspace, and walked through a full collaboration loop between a Snowsight-only user and a command-line Git user editing the same Streamlit in Snowflake app, ending with a deployed, shareable app that carries commits from both of them.

Documentation:

Additional Reading: