Publish privately
Publish your app so only the people you invite can open it — for internal tools, client previews, and betas.
An internally published app is live at its usual address, but only the people you choose can open it. Everyone else is asked to sign in, and turned away if they are not on your list.
Who can open it
- You and your collaborators
- Anyone with edit access to the project can open the app.
- Invited users
- People you add by email. They can use the app but cannot open the project. Each one signs in with a Floot account on the address you invited, creating one if they do not have it yet.
It suits internal tools such as dashboards and admin panels, client previews before launch, and beta tests with a small group. Search engines are told not to index the app.
A sign-in in front of your app, not instead of it
The Floot sign-in decides who can reach the app at all. If your app has accounts of its own, people still sign in to the app as usual once they are through.
Floot decides who gets in, but does not record what people do once they are inside. To see how your testers used the app, look at what it saves in its own database (the Data tab under Services), or ask your assistant to record the actions you care about, such as each item a tester saves and when.
Internal publish or your own sign-in?
Both keep people out, but in different places. Internal publish puts the lock in Floot itself, in front of your whole app: someone you have not invited is turned away before they reach any of your pages, files or endpoints, so a mistake in your app's code cannot let them in. A sign-in your app has of its own is part of the app: everyone reaches it, and the app decides page by page who sees what.
When to publish internally
- Tools for your team: an admin panel, a dashboard over your business data, a CRM or an operations tool.
- Client previews: show a client the work before it goes live.
- Beta tests: let a few people try a new app, or a new version of one, before anyone else sees it.
- Tools just for you: a personal tracker or assistant nobody else should open.
There is nothing to build: no sign-up page, no passwords, no reset emails. The app still knows who each person is (see Knowing who is signed in).
When to give the app its own sign-in
- Apps for the public: anyone can sign up, without an invite and without a Floot account.
- Pages that should stay open: a landing page, pricing or a blog that people and search engines can find, with the private parts behind a login.
- More people than the invite limit: internal publish allows 5 invited people with Free, 20 with Pro and 50 with Power, across all your apps.
- Paid products: subscriptions, plans and roles tied to your app's own user accounts.
- Your own sign-in screen: your brand, and the sign-in options you choose, such as email or Google. See Sign-in for your app's users.
| Internal publish | Your own sign-in | |
|---|---|---|
| Who can get in | Only people you invite | Anyone you let sign up |
| What they need | A Floot account on the invited address | Nothing from Floot |
| What is locked | The whole app | The pages you choose |
| What you build | Nothing | Sign-up, sign-in and password reset, built by your assistant |
| How many people | Free 5, Pro 20, Power 50 | No limit |
The two also work together. Publish a public app internally while it is still in beta: testers sign in to Floot to reach it, then to the app's own accounts as usual, so you can try its plans and roles with real people. When you launch, publish it from the Web tab and the app's own sign-in takes over.
Publish internally
- 1
Open the Internal publish tab
Open your project on floot.com, click Publish, and choose the Internal publish tab next to Web.
- 2
Add the people you want
Under Invited users, add their email addresses. You can include a personal note and choose whether to email them now. Floot writes the rest of the invite: a link to the app and how to sign in with the invited address.
Invited users are listed on the Publish screen. The email icon opens the invite dialog, where you can add more people and send them the link. - 3
Click Publish internally
If the app is public right now, Floot asks you to confirm before making it private. Switching a live app between public and private takes it offline for a few minutes while Floot moves it, so pick a quiet time. Anyone still waiting for an invite gets it when the publish finishes.
Going private is a publish like any other, so it also puts your latest changes live. To check the result, open the app's address in a private browser window: it should now ask for a sign-in.
Later changes reach your testers the same way. They see what you last published, not your preview, so publish internally again whenever you want them to try a fix.
Your assistant keeps it private
Your assistant can publish updates to a private app, and it stays private. Only you can switch an app between public and private, on the Publish screen.
Private mobile apps
Internal publish covers the iOS and Android app too. On the Internal publish tab, turn on Publish mobile app before you click Publish internally, and Floot builds the app along with the private website. Only the same people can use it.
- It opens on a Sign in with Floot screen. On iPhone it uses Safari's sign-in: anyone already signed in to Floot in Safari taps Continue and is in. On Android it uses the phone's browser the same way.
- People stay signed in. They sign in again only after 30 days without opening the app, and at the latest 90 days after they first signed in.
- Removing someone signs them out of the app too, within about an hour. So does Sign out others under Sessions on their Floot account page, used from a browser.
- Share it through TestFlight and Google Play internal testing. A public App Store or Google Play listing does not fit an app only invited people can use.
Private mobile builds count toward your monthly app builds like any other build, and need the same store connections — see Creating mobile apps. Only a publish with Publish mobile app on makes a build:
| What you want | Publish mobile app | Uses an app build |
|---|---|---|
| Let invited people use the website | Off | No |
| Put a fix live on the private website | Off | No |
| Give testers a new iPhone or Android build | On | Yes |
| Keep testing the build testers already have | No publish needed | No |
iPhone testers need two invites
Your invite on the Publish screen lets someone sign in to the app. To install it, they also need a TestFlight invite, which you send in App Store Connect under TestFlight: Floot adds only the Apple ID you connected. People on your App Store Connect team can go in an internal group. Anyone else, such as friends or beta users, goes in an external group, and Apple has to approve the build for external testing before they can install it.
Keep it private for good
To make sure the app is never published publicly by mistake, click the project name in the top-left to open the project's Settings page, and in the Visibility card click Turn on next to Only allow internal publish. You confirm by typing a short phrase, and the same goes for turning it off. The Web tab on the Publish screen is then unavailable, every publish (yours or your assistant's) stays private, and the project's preview links open only for people signed in to Floot who have access to the project. Turning it on closes everything a preview link opened before: links already shared stop working within about a minute, and so does the access they gave to the preview's backend; the preview's backend then answers only those signed-in people (the one exception is an endpoint that exports flootPreviewPublic, for webhooks, which must check its caller itself); and the preview's storage files move to a private address. That is what lets an app use the Floot sign-in as its only login. Only the project owner can turn it on or off, and an app that is live in public has to be published internally first. Copies of the project keep the setting.
Signing out
Someone who opens an internal app stays signed in to it in that browser, for up to 7 days before Floot checks their sign-in again. On a computer other people use, end it one of these ways:
- A sign-out button in the app. Ask your assistant to "add a sign-out button that uses the Floot sign-out link", then publish internally again. The button signs that browser out of the app right away and opens a Floot page with Log out of Floot. Click that too: while the browser is still signed in to Floot, the app opens again without asking.
- Log out of Floot. On floot.com, open the account menu and choose Log out. Apps opened from that browser stop working within about an hour, in every tab.
- From another device. If you left a browser signed in somewhere else, open your Floot account page and click Sign out others under Sessions. The apps open in those other browsers stop working within about an hour.
Knowing who is signed in
Everyone who opens an internal app has signed in to Floot, so the app can tell who each person is without a login of its own. No sign-up page, no passwords, no user table to keep in step with your invite list. Ask your assistant to use the signed-in Floot user, for example:
- Each person's own records: "show each person only the requests they submitted"
- A record of who did what: "record who approved each expense, and when"
- Roles: "only Maria and Sam can open the admin page"
- A personal touch: "greet people by their email and remember their settings"
The app learns two things about the person: a permanent ID for their Floot account and their email address. Your assistant stores records under the ID, which never changes, rather than the email, which a person can change on their Floot account. Floot tells the app who the person is on its server, where nobody using the app can change it, so the app does not have to take their word for it.
Who gets in, and what they can do
Who can open the app is still decided on the Publish screen. What each person can do inside it, such as which pages they see or what they can change, is up to the app: ask your assistant to set up the roles you need.
In the preview
The preview knows who is signed in too, so you can try all of this before you publish. When you work on the project on floot.com, the app sees you. A preview link acts as the person it was made for, so a link you made and forward to someone acts as you. Someone who opens a link you shared by email is seen only when they are signed in to Floot with the address you sent it to; otherwise the app sees no one. With Only allow internal publish turned on, preview links stop working: only people signed in to Floot who have access to the project get in, and each is seen as themselves.
When there is no signed-in person
Only a person opening the app has a Floot sign-in. These have none:
- An app published publicly
- Endpoints made reachable without the Floot sign-in, such as webhooks (see below)
- Scheduled jobs and background tasks
- Calls from another of your apps through connected apps
The parts of your app that need a signed-in person refuse to answer there instead of opening up to everyone. So if you later publish the app publicly, those parts stop working rather than showing one person's data to anybody with the link. That also means something that works in the preview can stop working once the app is public: that is expected, and the fix is to publish it internally or to give the app a login of its own.
Webhooks and other services
Services that call your app from their own servers, such as a Telegram bot's webhook, a calendar feed or a script with an API key, cannot sign in to Floot. Ask your assistant to make those endpoints reachable without the Floot sign-in. It marks each one in its code, and each one must check who is calling, for example with the webhook's secret or an API key. Everything else stays private.
For the same reason, other services cannot open your app's stored files by their usual address. To send a file to one, such as an image for a Telegram message or an AI model, your assistant gives it a temporary signed link instead.
Limits
- Free accounts can invite 5 people in total, across all their apps, Pro 20 and Power 50. Someone already invited to another of your apps does not count twice, and collaborators never count.
- To invite more people, contact support@floot.com. If you are already over the limit, everyone keeps access; only new invites are refused.
- Removing someone cuts off their access to the app's backend and data within about an hour.
Test new features while the public app stays up
Internal publish makes the whole app private, so everyone using the public version loses access. To try new features with a few people while your public app keeps running, duplicate the project, publish the copy internally and invite your testers to it. Duplicating needs a paid plan.
- Give the copy its own database. Choose Duplicate schema only for empty tables or Duplicate with full data for a copy of your data. The default, Share database, points the copy at your real data, so a tester's test order would land in your live app.
- Check what the copy still shares. Connected integrations, such as API keys and payment or email services, are shared with the original and live straight away, and the copy's scheduled jobs start running when you publish it. Switch off anything that would send real emails, take payments or change outside data.
- Invite your testers again. Invited users and collaborators are not copied. The copy also starts without an app store connection, so testing it as a separate iPhone app means connecting the store and giving it its own app ID.
Making it public again
Open Publish. A private app opens on the Internal publish tab, whose button keeps it private, so switch to the Web tab and click Publish update, or click Make it public on the Internal publish tab. Floot asks you to confirm, then republishes the app with your latest changes for anyone with the link. Switching between public and private, in either direction, leaves the site unreachable for a short while. Custom domains work the same on a private app as on a public one.
Private publishing covers the published app. The preview link your assistant hands you works the way it always does — see Sharing your projects.