Skip to main content

​
Overview

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.

​
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.
You can always change visibility later from the app’s settings — it’s not a permanent choice.

​
Changing visibility later

Open your app, go to Settings → General, and pick a new visibility. You’ll get a confirmation dialog that spells out what changes.
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.
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 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.) Being able to edit an app is separate: that requires the Apps permission (apps:write) on their organization role.
  • 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: 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: 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.
Custom domains require their own DNS setup and TLS cert provisioning. See the Custom Domains guide for setup steps.

​
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), 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.

​
Surfaces and project visibility

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.
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.