App Visibility

OverviewCopy Anchor Link

Every Stardeck app has a visibility setting that controls who can reach it once it's deployed. If the app also has Surfaces, project visibility still dominates: a public Surface inside an internal or private app stays internal. Surfaces can be public or internal only — there is no per-Surface private access setting.

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.

New apps start publicCopy Anchor Link

Every new app is created Public, whether you create it in the dashboard or your coding agent creates it with create_app. To make it internal or private, change it in settings once the app exists.

Changing visibility laterCopy Anchor Link

Open your app, go to Settings → General, and pick a new visibility. You'll get a confirmation dialog that spells out what changes.

Your coding agent can change it too, with the update_app_settings tool. A change to visibility asks you to confirm first.

If you flip a public app to internal or private:

• The public URL stops serving your app.
• App users who signed up on your deployed app's login page 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 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 and assigned team members.

Who can access an appCopy Anchor Link

Team members, collaborators, and app users reach an app differently. Roles and app-only access are covered in Members & Roles. Editing an app is separate from reaching it, and needs the Edit Apps permission (apps:write) on the person's organization role or on their Team role for that app.

The key distinction between internal and private is whether being a team member alone grants access. Internal apps are for the whole team; private apps need an invite or an assignment. To assign a team member, see Give a team member a specific app.

An internal app can narrow this further. Under Settings → General → Access permission, pick a Required Permission: only team members whose organization role holds it can open the app.

Opening internal or private appsCopy Anchor Link

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

• Your dashboard — click the app to launch it.
• Settings → Domain — the Domain tab under Deployments has a button that opens the app in a new tab: Visit Site when a custom domain is assigned, Visit Default URL otherwise.

Either path runs an access check and signs you in with your Stardeck account. The app opens inside the Stardeck frame. To give people who can't edit the app the whole window (a POS on an iPad, a wall dashboard), turn off Show app shell in Settings → General. People who can edit the app always see the frame. See Add to Home Screen.

Custom domainsCopy Anchor Link

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 team members can reach the custom domain. Unauthenticated visitors are sent through Stardeck to sign in first.
• Private + custom domain — only the people who can open the private app 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.

What your end-users seeCopy Anchor Link

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), 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 app user sign-ups — everyone who opens the app is already signed in to Stardeck, and the app sees them as a Stardeck user.

Surfaces and project visibilityCopy Anchor Link

An app can expose several Surfaces (customer site, admin, POS, and so on). Each Surface has its own public or internal posture, but it cannot override a tighter project visibility:

For launch URLs, shell mode, and in-app permission warnings, see Surfaces.