DavidApps

Put an app behind sign-in, choose who gets in, and see every decision afterwards.

DavidApps answers one question in front of every app you run: may this person open it right now. You choose how each app asks that question. Everything after that — people, groups, the sign-in page, the history — works the same way whichever way you picked.

Three ways to protect an app

Wall it off

Nothing changes inside the app. The check happens in front of it, so an app with no sign-in screen and no user table gets one anyway. People sign in with Google, GitHub, Discord, or a magic link. A small private app can use a shared password instead, an expiring share link for one visitor, or a bypass token for CI.

Start at Protect an app, which has the exact addressing rules to copy and what each way in actually does.

Standard OpenID Connect, for an app that already owns its user session and just wants DavidApps to say who someone is. The app receives a stable ID for each person that is specific to that app, and it can quietly restore a recent DavidApps session on the paths you choose, so a returning visitor never sees a sign-in screen at all.

Sign in with DavidApps covers Auth.js, Better Auth, any ordinary OpenID client, Vercel, and the optional SDK, including the silent path and what happens when it fails.

For an app that has to keep the sign-in code it already has. DavidApps identifies the person in front, hands the app a signed one-use handoff, and the app turns that into its own native session. The app's user table, session model, and framework stay exactly as they are.

Auto-login walks through the three files and one model this takes.

Who gets in

Access is decided per app. You can grant it to one person, to a group you made, or to a role in your team, and a deny always beats every allow. Invite someone by email and they can open the app as soon as they accept. The Access screen shows the rule that decided each answer, not just the answer.

Read Groups and access.

Each app gets its own sign-in page: which surfaces carry the colour, where the column sits, how round the buttons are, your own logo, and how much movement the page makes when it opens. You edit it beside a live preview of the real page, at three widths.

Read Sign-in page.

Doing it without the dashboard

Eleven operations are available to an API key, and each one is exactly one HTTP call and exactly one MCP tool, so an agent can set an app up end to end without a person clicking through screens. Both faces authenticate with the same API keys, obey the same scopes, and land in the same history.

Those eleven are not the whole dashboard. Session and role administration — ending someone's sessions, banning them, changing a platform role — is a separate surface that an API key cannot reach, and it stays in the dashboard.

Read the HTTP API and MCP tools.

What you can see afterwards

History records every change anyone made, newest first, plus selected access outcomes: getting into an app without an account, and asking to be let in, being turned away, joining the team, or agreeing to let an app see who you are. Complete sign-in and visit history is not recorded yet. Removing someone from a group, denying them, or ending their session takes effect in under a minute on a walled-off app. Apps that hold their own tokens pick the change up when those tokens next refresh, within fifteen minutes.

Where this stands

Everything described here is built and tested in this repository, and every page is written against the code rather than a plan. Two things are deliberately not done yet, and no page pretends otherwise:

The @davidapps/protocol, @davidapps/sdk-better-auth, @davidapps/sdk-core, @davidapps/sdk-next, and @davidapps/mcp packages are built, packed, and install-verified locally, but they are not published to a package registry. Install them from the workspace or from a packed tarball.
No production deployment has been made. The addressing rules the dashboard hands you are correct for the service they name, and that service is not running yet.

If you want the internal version of all of this — what runs where, which key signs what, and which risks are still open — read Architecture. It is the one page that uses internal vocabulary.

On this page