Appsmith

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the internal tool I actually need instead of a hosted Appsmith: a few screens over my own database, with the permissions and the audit log a builder charges for.

Read this first: the product you are replacing is open source, and self-hosting it is a real answer. What the paid tier sells is single sign-on, granular permissions and audit logs. If you need a general canvas that colleagues drag widgets onto, self-host. If you need four screens over your own data, build them — a builder is a very expensive way to render a table.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- Your existing database through its own driver, plus SQLite for this tool's own state
- No client-side framework
- Caddy in front

THE DATA MODEL, MEANING THIS TOOL'S OWN
- users: id, email, name, is_active, created_at, last_seen_at
- roles: id, name, description
- permissions: id, role_id, resource, action, scope_json — resource is a screen or a query, action is read, write or run
- sessions: id, user_id, token_hash, ip_hash, user_agent_bucket, created_at, expires_at, revoked_at
- audit_log: id, actor_id, action, resource, target_id, before_json, after_json, ip_hash, at — append-only, enforced by a trigger
- queries: id, name, sql, params_json, is_mutation, requires_role, description — every query named, versioned and reviewed, never assembled from user input
- exports: id, actor_id, query_id, row_count, at — an internal tool is how data walks out of a company; every export is a row

AUTHENTICATION
- Single sign-on through OIDC against whatever identity provider is in use, which is the only sane answer for staff accounts
- A local fallback with magic links for the case where there is no provider
- Sessions with a short life and a refresh, revocable centrally, and a list of a user's sessions they can end
- No shared logins, ever, because an audit log with a shared account in it answers nothing

PERMISSIONS
- Role-based, checked on the server for every screen and every query, never in the browser
- Row-level scope where it matters: a support agent sees the customers in their region, expressed as a scope predicate joined into the query
- The default is deny. A new screen is invisible until a role is granted it
- A page that shows exactly what each role can do, generated from the permissions table rather than written by hand and left stale

THE SCREENS
- A list screen: filters, sorting, pagination, and a column set defined in code
- A detail screen: fields, related records, and the actions allowed on this record
- An action is a named mutation with its own permission, its own confirmation, and its own audit entry. Never a free-form SQL box in production — that is the thing internal tools are breached through
- Bulk actions with an explicit count in the confirmation: 'this will refund 214 orders'
- Every destructive action is reversible or requires typing something to confirm

QUERIES
- SQL written in files, parameterised, reviewed like any other code
- Read queries run against a replica or a read-only connection where one exists
- A statement timeout on everything and a row limit on every list, because one unbounded query on a big table takes the database down and the internal tool takes the company with it
- Slow queries logged with their parameters redacted

THE AUDIT LOG, WHICH IS WHAT IS BEING BOUGHT
- Every read of sensitive data, every mutation, every export, every permission change
- Before and after values for mutations, with sensitive fields hashed rather than stored
- Searchable by actor, by target, by time
- Nothing in it is ever updated or deleted; retention is long and stated

THE INTERFACE
- Dense and plain: tables that align, a header with who you are and what you can do, keyboard navigation for the list screens
- Fast on a laptop over a poor connection — no bundle, no spinner
- Dark and light

OPERATIONS
- .env: DATABASE_PATH, TARGET_DATABASE_URL, BASE_URL, OIDC_ISSUER, OIDC_CLIENT_ID, OIDC_CLIENT_SECRET, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once
- The tool reachable only behind whatever the company already uses — a VPN, an identity-aware proxy — with public exposure a deliberate decision
- Nightly backup of this tool's database, restore script
- Health endpoint

WHAT MATTERS MOST
Permissions and the audit log. Build deny-by-default, the server-side check on every query, and the append-only log before a single screen looks good. An internal tool is a permanent standing route into the company's data, and the difference between one that is safe and one that is not is entirely in those two things.

Give me the repository, migrations, .env.example, three example screens over a seed schema, and a README with deploy steps behind Caddy and the network placement spelled out.