How Collaboration and Sharing Work in LLMStack

LLMStack lets you share a built app either publicly with anyone on the internet or privately with specific people, and it separates those people into viewer and collaborator roles so multiple users can modify and build the app together. This applies to apps you have already assembled in the no-code builder; the sharing and permission controls described here govern who can open the app and who can change it.

Two ways to share an app

LLMStack's permission model gives you a binary choice at the top level:

• Public sharing — the app is available to everyone on the internet. Useful for demos, internal tools you want anyone to reach, or a chatbot you want to distribute widely.
• Restricted access — the app is limited to certain individuals you name. Useful when the app touches private data or is meant for a defined team.

The distinction matters because LLMStack apps are often connected to your own data — web URLs, sitemaps, PDFs, audio, PPTs, Google Drive, or Notion imports. If an app is grounded in material you would not publish, restricted access is the setting that keeps it from being reachable by anyone with the link.

Roles: viewer vs. collaborator

Within the people you grant access to, LLMStack distinguishes two roles:

The practical consequence is that sharing an app and co-building an app are separate grants. You can hand someone a working app without handing them the ability to alter its prompts, model chain, or data connections. Conversely, a collaborator is someone you are treating as a co-builder, so grant that role only to people you would let edit the app directly.

Building collaboratively

Because collaborator access allows multiple users to modify and build the same app, LLMStack is set up for team construction rather than a single author publishing a finished artifact. The platform is built on React and describes itself as a no-code way to build generative AI apps, chatbots, and agents, so the people you invite as collaborators do not need to write code to participate in the build.

A reasonable division of labor looks like this:

1. One person assembles the first working version — model chain, data sources, and the app surface.
2. That person shares it as a collaborator with teammates who will refine prompts, swap or add model providers, or adjust which data sources feed the app.
3. Everyone iterates on the same app rather than passing files around.
4. When the app is ready for an audience that should not edit it, those users are added as viewers or the app is made public.

Choosing a sharing setting

• Use public sharing when the app contains nothing sensitive and you want zero-friction access — a public demo, a marketing chatbot, a general-purpose helper.
• Use restricted access with viewer role when the app should be used but not changed, and only by a known set of people.
• Use restricted access with collaborator role when the person is genuinely part of the build and you are comfortable with them changing the app.

What to check before you share

• What data the app is connected to. LLMStack supports importing your own data from web URLs, sitemaps, PDFs, audio, PPTs, Google Drive, and Notion. Public sharing exposes whatever the app can surface from those sources.
• Which model providers the app chains. LLMStack supports major providers including OpenAI, Cohere, Stability AI, and Hugging Face; sharing an app shares access to its behavior, so confirm the chain is one you are willing to expose.
• Who actually needs edit rights. Default to viewer unless the person is building with you.

The site's own framing — "share apps publicly with everyone on the internet or restrict access to only certain individuals using our granular permission model" — is the whole mechanism: one public/restricted switch, plus a role assignment per person. Everything else about collaboration follows from those two decisions.