> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stardeck.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# App Visibility

> Control who can access your deployed app — the open internet, your whole organization, or an invite-only set of collaborators.

## Overview

Every Stardeck app has a **visibility** setting that controls who can reach it once it's deployed:

| Visibility   | Who can access                | Where it's served                                   |
| ------------ | ----------------------------- | --------------------------------------------------- |
| **Public**   | Anyone on the internet        | Your public app URL (e.g. `your-app.stardeck.site`) |
| **Internal** | Everyone in your organization | Inside Stardeck, at an internal URL                 |
| **Private**  | You and invited collaborators | Inside Stardeck, at an internal URL                 |

Pick the one that matches what you're building:

* **Public** — customer-facing sites, marketing pages, SaaS products, storefronts.
* **Internal** — tools for your whole team: admin consoles, KPI dashboards, internal wikis, staff portals.
* **Private** — tools for a specific group: a POS for one store, a partner-facing dashboard, a personal scratchpad you haven't shared yet.

## Choosing visibility when you create an app

When you create a new app, you'll see a visibility picker in the creation dialog. It defaults to **Public**.

<Note>
  You can always change visibility later from the app's settings — it's not a permanent choice.
</Note>

## Changing visibility later

Open your app, go to [**Settings → General**](https://www.stardeck.ai/projects/~/dashboard/project/general), and pick a new visibility. You'll get a confirmation dialog that spells out what changes.

<Warning>
  **Changing visibility changes your app's URL.** Public apps live on the public apps domain (e.g.
  `your-app.stardeck.site`); internal and private apps live on a separate internal subdomain. Any
  existing bookmarks or links pointing at the old URL will stop working after you flip.
</Warning>

If you flip a **public** app to **internal** or **private**:

* The public URL stops serving your app.
* Users who signed up on your deployed app's login page (deployment users) will lose access — they can't sign into Stardeck, so they can't reach an internal or private app.
* Your app gets a new URL on the internal apps domain.

If you flip an **internal** or **private** app to **public**:

* Your app becomes reachable to anyone on the internet.
* Sign-up settings for end-users reactivate — review [**Authentication**](https://www.stardeck.ai/projects/~/dashboard/config/auth) settings to make sure the right sign-up behavior is configured.
* The app moves to the public apps domain and gets a new URL.

If you flip between **internal** and **private**:

* The URL stays the same (both live on the internal apps domain).
* Access rules change: internal opens up to the whole org; private locks down to invited collaborators only.

## Who counts as a "collaborator"?

Stardeck has two ways people can have access to an app:

* **Organization members** — anyone in your Stardeck organization. They have access to all of your org's apps by default. (Members with an **app-only** role are the exception: they only reach apps they're explicitly assigned — see [Members & Roles](/members-and-roles).)
* **Project members** — external collaborators you invite to a specific app. They don't need to be in your organization.

Visibility determines how these roles interact with an app:

|              | Org members     | Project members | End-users (deployment sign-ups)      |
| ------------ | --------------- | --------------- | ------------------------------------ |
| **Public**   | Can access      | Can access      | Can access (if sign-ups are enabled) |
| **Internal** | Can access      | Can access      | ❌ Cannot access                      |
| **Private**  | ❌ Cannot access | Can access      | ❌ Cannot access                      |

The key distinction between internal and private is whether **organization membership alone** grants access. Internal apps are for the whole org; private apps require an explicit invite.

## Opening internal or private apps

Internal and private apps don't have a public URL to bookmark directly. Open them through Stardeck:

* [**Pinned Apps rail**](https://www.stardeck.ai/dashboard) on your dashboard — click an app card to launch it.
* [**Settings → General → Visit Site**](https://www.stardeck.ai/projects/~/dashboard/project/general) — opens the app in a new tab.

Either path runs an access check, authenticates you against Stardeck, and forwards you to the deployed app full-viewport. There's no Stardeck chrome around the app — it owns the whole window, which makes it suitable for real business apps (POS on an iPad, full dashboards, etc.).

## Custom domains

You can point a custom domain at an app of any visibility. The custom domain inherits the app's access rules:

* **Public + custom domain** — anyone on the internet can reach the custom domain, same as today.
* **Internal + custom domain** — only org members can reach the custom domain. Unauthenticated visitors are sent through Stardeck to sign in first.
* **Private + custom domain** — only invited collaborators can reach the custom domain. Same sign-in flow.

When you set a custom domain, Stardeck prefers it as the stable URL for the app. Bookmarking the custom domain works across the full sign-in + app-use flow — the URL bar stays on your branded domain throughout.

<Note>
  Custom domains require their own DNS setup and TLS cert provisioning. See the [Custom Domains
  guide](/custom-domains) for setup steps.
</Note>

## What your end-users see

If you're running a **public** app, your end-users sign in through the deployed app's own sign-in page (configured under [**Settings → Authentication**](https://www.stardeck.ai/projects/~/dashboard/config/auth)), at your public URL or custom domain. Nothing about that flow changes — visibility is a setting that governs who else can reach the app, not how your app's own users log in.

If you're running an **internal** or **private** app, there are no deployment sign-ups — everyone who opens the app is already signed in to Stardeck, and the app sees them as a Stardeck user.

***

*Visibility is about access control on your deployed app, not on who can edit the app itself in Stardeck. For collaborator permissions inside the app builder, see [Members & Roles](/members-and-roles).*