Who signs in, what each person can reach, and what is allowed to leave your organization — you set all of it, in a handful of switches rather than a project.
Security you switch on and verify, not a posture you have to take our word for.
Members sign in with a passkey held by their own device, or through your identity provider if you use SSO. There is no password to phish, reuse across sites, or lose in someone else's breach — because there is no password. A new Free org signs in with emailed codes until it buys a plan.
Once your org has bought a plan, a one-time code to your address resolves the account, then the passkey proves it. A browser you mark as trusted can skip the code, never the passkey. Members on SSO use your identity provider's MFA instead.
Point sign-in at your own OIDC provider and members arrive through it, so joiners and leavers stay one process and MFA policy stays where you already manage it.
Set how long a session lasts before it re-asserts the passkey — anywhere from 12 hours to 14 days — instead of living with a default someone else picked.
Somebody leaves, or something looks wrong: suspend them and their sessions stop working straight away rather than when a token happens to expire. Their history stays intact and reactivating is one click.
Email invites you send outside the org are time-limited, and you set the ceiling on how long any of them may live. Switch org sharing off and every invite already out there stops working immediately.
Getting in is not the same as getting at everything. Reach is granted per app, per collection, and per capability — and the log says who granted it.
Owner, editor, data editor and viewer. A new app is reachable by its owner and nobody else: access is a thing you grant, never something membership confers.
Put people in groups and grant the group, so access follows the team rather than a list you maintain by hand — and revoking is the same one move.
Partition a collection so each person reads and writes only their own records inside one shared app. Everyone uses the same tool; nobody reads anyone else's rows.
A deployed app cannot read your member directory, email anyone outside your organization, or go public until an admin allows it — per app, off by default, and never something the AI that built it can grant itself. Even mail to your own members waits for the app's owner to turn it on.
Machine credentials for scripts and CI, limited to named collections with read and write set separately, rotated with a grace window so nothing breaks mid-cutover.
Grants, invitations, member changes, publishes, backups, keys and plan changes, each with actor, target and time, kept for 90 days and filterable in the console.
Described by what it protects rather than how it is configured — naming our infrastructure would tell an attacker where to aim and tell you nothing useful.
TLS on everything — your browser to us, and every hop your data takes once it is with us. Nothing about your app or its data crosses a network in the clear.
Stored files, published app source and app backups are held in object storage that encrypts every object at rest.
An app's files are private to that app: only people who can open it can load them. Nothing a browser could run as code is accepted — no HTML, JavaScript, CSS or SVG — and every file is checked to really be what its name says. Each is served under a sandbox, so even a file that slipped past those checks could not run.
API keys, tokens, invite links and personal links are stored one-way hashed — we can check what you present but cannot reproduce it. The few secrets that must stay reversible are encrypted under a key held outside the database.
Your organization is the boundary, and each published app is served from its own opaque origin. One app's code cannot reach another app's data, or call the dashboard as whoever is viewing it.
Stripe hosts checkout, and Link, operated by Stripe, sells the subscription as merchant of record. Card details never reach Appabl's servers and are never stored by us.
Deleting an app removes its versions, stored files, collections and documents. You can also hold a collection to a rolling window, so records past it are cleared out for you instead of accumulating forever.
Every app keeps its own history, so a bad publish or a wrong bulk edit is something you reverse rather than something you rebuild.
One snapshot holds your app's published versions and every document in its collections, taken together. Restore it and the code and the data belong to the same moment — not today's database sitting behind last month's app.
Apps are snapshotted every day without you asking, skipping the ones nothing changed in. Deleting an app through your AI takes one first, automatically, and the dashboard offers one before it deletes — so changing your mind is a restore, not a support ticket.
Published versions are kept, and rolling back just moves the live one to whichever you pick. No redeploy, no rebuild, and the version list stays exactly as it was.
A restore rebuilds the app as a new one rather than writing over what you have, so you can open both and compare before you move anyone across. The app you are rescuing is never at risk from the rescue.
Send us what you found and how to reproduce it. We will acknowledge your report and keep you posted as we work it. We will not pursue legal action against anyone researching in good faith who gives us a reasonable window to fix the issue before going public.
Connect your AI, describe a tool, and share it with your team. Free to start, no card required.
Appabl is available only in the United States. It is not available in any other country.