HTMQL

What is HTMQL?

The fastest path from a SQL database to a working web app

HTMQL is a tool for building business web applications. Applications can be a complete system with navigation, roles, and reports — or exactly one screen that fills a specific gap in a system you already run. If you have a SQL database and need a web interface for it, HTMQL is designed to be the fastest path from that database to a working, deployable application.

It consists of a single compiled executable that you drop next to a folder of plain-text page files, written using standard HTML and SQL. It comes bundled with authentication, authorization controls, PDF generation, email, file handling, database migrations, and more. Your data stays in a SQL database you control. The platform's source code is public. No complex installation, no subscription, no vendor lock-in.

Here is a complete application page

Every page is one .htmql file: a header with SQL commands and settings, and HTML below it. This is a full to-do list. A single page displays all tasks, adds new ones from a form, toggles them complete, and deletes them. There is no controller, no model, no route file, and no custom JavaScript.

{{/*
#10 To Do List
+staff
-guest
GET:tasks:SELECT id, task, done FROM todo ORDER BY id;

POST:!:INSERT INTO todo (task, done) VALUES (@task, 0);
POST:"Task added."
POST:!"Failed to add task."

PUT:!:UPDATE todo SET done=1-done WHERE id=@id;
PUT:""

DELETE:!:DELETE FROM todo WHERE id=@id;
DELETE:"Task deleted."
DELETE:!"Failed to delete task."
*/}}

<title>To Do List</title>

<form method="post" class="f-row">
    <input type="text" name="task" class="flex-grow:1"
           placeholder="Add a new task..." required>
    <button type="submit">Add</button>
</form>

<ul>
{{range .tasks}}
<li class="f-row align-items:center">
    <input type="checkbox" {{if .done}}checked{{end}}
           hx-put="/todo?id={{.id}}" hx-target="#page">
    <span>{{.task}}</span>
    <button hx-delete="/todo?id={{.id}}"
            hx-target="#page">Delete</button>
</li>
{{else}}
<li>No tasks yet.</li>
{{end}}
</ul>

The #10 To Do List line adds this page to the application's navigation menu at position 10. The menu is rendered by the system/header.html template, which wraps every page and can be customized to match your branding and layout.

The +staff and -guest lines control who can access the page based on their role membership. Pages without role decorators follow the default access settings defined in the config. Roles come from OIDC token claims or a local database table, and are checked automatically on every request. No middleware or guard code to write.

GET, POST, PUT, PATCH, and DELETE lines reflect the SQL commands that execute for the respective HTTP methods. Here, POST runs when the form is submitted, PUT when a checkbox is clicked (its done=1-done toggles the completed state), and DELETE when a Delete button is clicked; GET re-renders the page after any write completes. The ! marks a write as critical: if it fails, the SQL transaction rolls back and an error is shown to the user. The quoted strings alongside each method set its success and failure messages. PUT:"" suppresses the success message. Message appearance is controlled by the system/success.html and system/error.html templates.

The checkbox and Delete button use hx-put and hx-delete attributes from htmx, a lightweight JavaScript library bundled with HTMQL that sends any HTTP method directly from HTML attributes. No custom JavaScript, no controller, no model, no route file. One file, top to bottom.

my-app/
├── htmql-server(.exe)
├── config.json
├── pages/
│   ├── index.htmql
│   └── todo.htmql
├── migrations/
│   └── 001_create_todo.sql
└── system/
    ├── header.html
    ├── footer.html
    ├── success.html
    ├── error.html
    └── 404.html

Security

Secure by default

A page format built on raw SQL and HTML raises an obvious question: what about injection? HTMQL is designed so that the safe path is the default path. Every @parameter is passed to the database as a bound parameter — HTMQL never concatenates user input into SQL. Every template value is escaped on output. Page access rules are enforced on the server before any SQL runs. None of this requires configuration; it is simply how the server works.

The same principle applies to everything else the server does. Risky capabilities, such as calling external programs, are off until you deliberately enable them; the server refuses to start without an explicit authentication choice; and secrets can be supplied through environment variables and are redacted from logs and the admin view.

Covered out of the box

• SQL injection — every @parameter is bound, never concatenated, with quote- and comment-aware parsing.
• Cross-site scripting — contextual auto-escaping on every template value; user-entered Markdown is sanitized before rendering.
• Unauthorized access — deny-by-default page authorization enforced server-side, with per-method rules and one-line fail-closed row-level guards.
• Session theft — HttpOnly, SameSite, and Secure/__Host- session cookies; sessions are held server-side with idle and absolute expiry, and optional re-authentication when a session roams to a different network.
• Brute force & floods — login and anonymous-traffic rate limiting on by default; request and connection caps shed overload with a clean 503 instead of falling over.
• Hostile uploads — dangerous file types blocked by default, filenames sanitized, path traversal contained, and stored files can never execute scripts in your site's origin.
• Open redirects & header injection — redirects stay on your site unless a host is explicitly allowlisted; email address headers are sanitized; external programs are invoked without a shell.
• Plaintext traffic — HTTPS with automatic Let's Encrypt certificates and renewal, HSTS under TLS, and baseline security headers on every response.