Datasette Apps 0.3a0: Letting LLMs Safely Build HTML Apps Inside the Data Platform

When a Data Platform Starts to "Grow" Apps

Datasette has always been a tool on the "data layer" side: turning SQLite databases into browsable, queryable web interfaces. The Datasette Apps plugin tries to go one level up—allowing users to host and edit custom HTML apps inside Datasette.

The 0.3a0 alpha release doesn't add ground-breaking new capabilities. Its value lies in polishing the path of "generating apps with an LLM" to be safer and smoother. The official notes put it plainly: apps can be written by hand, but creating them via Datasette Agent with an LLM is easier. This release is precisely about improving that integration.

Datasette is an open-source data tool developed by Simon Willison. Its core idea is to publish SQLite database files directly as browsable, queryable, API-accessible web interfaces, commonly used for data journalism, open data publishing, and internal data exploration. It doesn't process data itself; it acts as a "publishing layer on top of the database." Datasette Agent is a conversational extension in the same ecosystem, allowing users to interact with the database in natural language and invoke various tools to accomplish tasks. Plugins are Datasette's extension mechanism; the community and official team add capabilities such as exports, authentication, and visualizations through plugins, and Datasette Apps is one of them. Understanding this ecosystem is key to seeing why all the changes described here revolve around "Agent invoking tools."

Starting with #: App References Become Part of the Conversation

The most visible change is the # symbol in the chat input box. When a user types # in a Datasette Agent conversation, autocomplete for app names is triggered, with candidates drawn from apps the current user has permission to view.

The significance of this design isn't just saving a few keystrokes. It elevates "apps" to first-class citizens in the conversation—users can reference an app much like @-mentioning someone, letting the Agent know exactly which object the context points to. The autocomplete scope is constrained by permissions, which also prevents users from seeing app names they shouldn't.

A related detail: the "View app" button shown by Agent tools, as well as links generated from # references, now open the app full-screen within the Datasette Agent panel. Apps are no longer an appendage requiring a page jump to view; they're a view embedded in the workflow.

Authorization for Stored Queries: Delegating Permission Checks to Tools

The real centerpiece of this release is the permission model. Two new tools, app_add_stored_queries() and app_remove_stored_queries(), let the Agent manage which stored queries an app is allowed to call.

The key constraint: granting write queries requires user approval first. Read queries are relatively permissive; write operations require a human nod. This is a pragmatic tiering—the LLM can freely compose read-only data, but as soon as data modification is involved, a human must step in.

The behavior of app_create() has been tightened accordingly. It now checks two things before creating an app: whether each requested stored query actually exists, and whether the current user has permission to view it. If write queries are involved, the creation flow first asks for user approval, and only then actually generates the app.

This mechanism solves an easily overlooked problem: when an LLM generates an app, it often "casually" references queries, and if those queries don't exist or the user lacks access, the app will error out at runtime or even exceed permissions. Moving validation forward to the creation stage means failures happen earlier and are more controllable.

Stored queries are pre-defined, named SQL queries in Datasette, declared via configuration such as datasette.yaml. They can take parameters and be exposed as read-only pages or API endpoints. Their key value: callers can only execute explicitly written SQL and cannot concatenate arbitrary statements, making them naturally suited as controlled interfaces for apps to read data. At the same time, Datasette's permission system can set visibility for individual stored queries—for example, allowing access only to specific roles. This is precisely why "which stored queries an app is allowed to call" becomes a security boundary requiring authorization—granting write queries effectively gives the app the ability to modify data, which is the fundamental reason this release requires human approval.

Why These Changes Matter

Looking at these three updates together reveals the Datasette team's judgment on "LLM-generated apps": capability expansion must go hand in hand with permission contraction.

On one hand, the Agent can do more—add or remove stored query authorizations for apps, create apps, and be precisely referenced via #. On the other hand, every operation involving data writes requires human confirmation, and query existence and visibility are verified at creation time. This "open up first, then set gates" approach is more sustainable than simply restricting the Agent's capabilities.

For scenarios building internal tools on a data platform, this direction is worth referencing. Letting an LLM rapidly generate app prototypes is tempting, but if it's connected to a real database with write permissions, the lack of an approval step is a hidden risk. Datasette Apps' approach embeds approval into the creation and authorization flows rather than relying on after-the-fact auditing.

Version Positioning and Real-World Limitations

It's important to be clear: 0.3a0 is an alpha release, features are still iterating rapidly, and interfaces and behavior may change. Its current core scenario is "hosting custom HTML apps inside Datasette," not being a general-purpose app development platform; without Datasette's data and permission system, these capabilities don't hold up.

Additionally, this update relies heavily on Datasette Agent. If users don't use Agent conversations to create or manage apps, the benefits of # autocomplete and query authorization tools are greatly diminished—manual app creation is still a viable path, just without these integration optimizations.

For those already using Datasette to manage SQLite data and wanting an LLM to help build lightweight frontends, this release is worth following; for those who only use Datasette as a database browser, it's fine to keep watching for a future stable release.

One-line Summary

Datasette Apps 0.3a0 adds # references and stored-query authorization approval for LLM-generated apps.

Paragraph Summary

The Datasette Apps 0.3a0 alpha release focuses on polishing the integration experience of "generating apps with an LLM" rather than adding ground-breaking features. The most visible change is that typing # in the chat input box autocompletes and references apps the user has permission to view; reference links and the "View app" button open apps full-screen in the Datasette Agent panel. The core change is in the permission model: two new tools, app_add_stored_queries() and app_remove_stored_queries(), let the Agent manage which stored queries an app can call, with granting write queries requiring user approval first; app_create() also verifies query existence and user visibility before creation, requesting approval first when write queries are involved. The overall approach is capability expansion alongside permission contraction, embedding approval into creation and authorization flows rather than after-the-fact auditing. This release is still alpha and relies heavily on Datasette Agent.