Everything your app can do once it is online

After the first emailed link, a colleague can save a passkey with Face ID, a fingerprint or the device PIN and skip the email next time. If they choose "Not now", that browser remembers.

Colleagues use the work or personal Google or Microsoft account they already have, instead of waiting for a link.

Your choice, set by asking Claude. The app can be private (you and the people you list), open to everyone in your workspace, open to anyone with an email at your company's domain (Pro and up), or public with no sign-in (Pro and up). Before an app goes public, Haechy shows you the pages and endpoints anyone could open without signing in, and it goes public only when you confirm. Free apps always require sign-in. The number of different people who can sign in across your apps is 5 on Free, 25 on Pro, 125 on Team and 500 on Business.

Adding people is a sentence in the chat ("give Priya and Tom access to the leave tracker"). If someone who isn't on the list tries to open the app, you get an email asking whether to let them in, at most once a day per person.

How sharing and sign-in work Give colleagues access without accounts

Your app can send notifications, approvals and summaries with nothing to set up with an email service. It can email people who have access to that app, and nobody else. Monthly allowance: 300 on Free, 5,000 on Pro, 15,000 on Team, 50,000 on Business. Sign-in emails don't count against it.

If you have a task board, a queue or a booking calendar, ask Claude to make it update on everyone's screen the moment one person changes something. Every plan. The starter apps don't do this out of the box, so ask Claude for it. Live updates

Each app's database is backed up every night. Free keeps 7 days of nightly copies you can restore, and Pro, Team and Business keep 30, plus weekly copies for 90 days. "Restore yesterday's data" is a sentence to Claude, and a safety copy is taken first. Backups cover the database. Stored files and the app's code are separate things (see below). Backups and restore

On Free, an app that nobody has opened for 15 minutes goes to sleep and wakes in a few seconds on the next visit. A scheduled run wakes it too. Paid plans keep apps running, up to a memory allowance per plan.

Every time you publish a change it becomes a numbered version with who, when and a one-line note. "Put it back how it was yesterday" works. The newest 20 versions are kept, and a rollback is itself a version, so you can undo the undo. A rollback moves the app's code only. Your data stays as it is, and restoring data is a separate request. Safe changes

After each publish Haechy opens the app's home page and up to 10 pages you name, and reports what each one answered, with hints from the app's log when something looks wrong (a missing table, a missing setting, a blocked outside service). It checks that pages load. It doesn't sign in as a person or run a browser.

Before an app goes online, on every plan, Haechy looks for API keys and passwords typed into the code, for .env-style files, for packages with known vulnerabilities or malware, and for risky code such as request input run as a command or as SQL. A key or .env file always stops the publish and says which file and line, and where the key should go instead. A malicious package, a critical vulnerability in a package the app runs with, or input passed straight to a command or query stops it too, unless the workspace owner or an admin allows that exact finding. It also lists the outside services the code calls, with whether you have approved each. It doesn't find every bug. Keep API keys out of the app Claude builds

Keys and settings you give Claude are stored encrypted, apply within seconds, and are never shown again. Only their names are listed.

An app can't reach anything on the internet until a person approves that exact service. Claude can ask for it, with a reason in plain English, but only you can approve (or an admin on Team and Business). Free allows 5 approved services per app, paid plans have no limit, and each one is still approved by a person. Decide what your app can reach

Claude can read what the running app printed, which is how it finds out why a page failed and fixes it.

Ask "how much of my plan have I used?" and Claude shows storage, email, apps and people against the limits. You are warned at 80 percent of a limit, and nothing that is running gets switched off when you reach one. Plan limits

Pick US (N. Virginia), EU (Ireland), UK (London) or Australia (Sydney) for each app. The app, its database, its backups, its stored files and its kept versions are stored in that region. Free uses one region per workspace, and paid plans can choose per app. The first app in a new region can take a few minutes to start.

Some services we use to send email, verify phone numbers and take payments process data outside your chosen region. See our sub-processors.

All regions

The Connections page lists every outside service an app can reach, why it was asked for, who asked, who approved and when, and any blocked attempts. You can approve, deny or switch one off there.

Ask Claude for "a page I can send to IT" and you get a read-only summary of one app: who can sign in and how, where its data is kept, which outside services are approved, the result of the last check, backup schedule and retention. It shows counts rather than email addresses unless you choose otherwise, and never shows a key or password. Anyone who has the link can open it, so share it like you would share a document link, and you can turn it off at any time. For IT

Every app runs in its own sandbox with a read-only filesystem, no root access and its own private network. Its database login opens that app's database and no other.

The database belongs to the app, and Claude can read a record for you ("who has more than 20 days left?") or fix one. It reads up to 200 rows at a time, and before it changes anything it will suggest taking a backup.