Skip to main content

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.

​
Overview

Every Stardeck app has a visibility setting that controls who can reach it once it’s deployed:
VisibilityWho can accessWhere it’s served
PublicAnyone on the internetYour public app URL (e.g. your-app.stardeck.site)
InternalEveryone in your organizationInside Stardeck, at an internal URL
PrivateYou and invited collaboratorsInside 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.
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.
  • App editors — 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 membersApp editorsEnd-users (deployment sign-ups)
PublicCan accessCan accessCan access (if sign-ups are enabled)
InternalCan accessCan access❌ Cannot access
Private❌ Cannot accessCan 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 on your dashboard — click an app card to launch it.
  • Settings → General → Visit Site — 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.
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.
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.