Appsmith

What is Appsmith?

Appsmith is an open-source platform for building internal tools, admin panels and dashboards by connecting to databases and APIs with a drag-and-drop interface. Self-hosting keeps internal data inside your own network.

Best for

Teams building internal dashboards and admin panels

Why choose Appsmith

Appsmith is the pragmatic answer for teams that keep building the same CRUD screens over and over. Instead of writing a React front end to rename a row in a database, you drag out a table, connect it to the query, and wire a button to an update — in an afternoon rather than a sprint. It is the closest open-source match to Retool, and it runs inside your own network, which matters when the database it talks to holds customer records that are not allowed to leave the building.

Replaces

• Retool
• ToolJet
• Budibase

Key features

• Drag-and-drop UI builder
• Connects to SQL databases and REST APIs
• JavaScript for custom logic
• Role-based access control

What to watch out for

Internal tool builders make the first screen easy and the fiftieth screen hard. Once an app grows, you are working inside someone else's abstraction: debugging a strange widget behaviour means reading framework internals, and the JavaScript escape hatches get messy fast. Self-hosting means you own upgrades, and version jumps occasionally need manual database migrations. The commercial edition also holds some governance and audit features, so check what the community edition actually includes for your requirements.

How to deploy

• Docker
• Kubernetes

Getting started

Deploy with Docker Compose and give the database real storage rather than a container-local volume, because every app you build lives in it. Set up authentication immediately — this tool can read any database you connect, so an unauthenticated instance is a data breach waiting to happen. Connect one read-only database user first and build a throwaway app to learn the widget and binding model before touching anything production. Decide on a naming convention for queries and pages on day one; retrofitting order into a tool builder is miserable.

Typical setup

The classic deployment is on a company's internal network, next to the databases it needs to reach: one Docker Compose stack, a Postgres instance, and a reverse proxy behind the corporate VPN. Small teams run it on a single modest VM and consider that sufficient for years. The pattern that works well is one shared instance where each internal team maintains its own folder of applications, connected through least-privilege database users rather than a shared administrative credential.

Who should look elsewhere

Not the tool for a customer-facing product. Internal tool builders assume trusted users, an internal network and an internal tolerance for rough edges; their authentication and performance characteristics are wrong for the public web. Skip it too if your team has no JavaScript capability at all, because the escape hatches are what make it viable past the first five screens.

Project health

• GitHub stars: 40,980
• Last code push: 2026-09-30
• Open issues: 4,494
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.