Appsmith

Last reviewed Aug 26, 2026 · 990 words

One Appsmith container is really 4 processes under a supervisor: a JVM backend, MongoDB, Redis, and an Nginx front. That is why the catalogue's 2 GB minimum is a floor you hit the first time 3 people open a dashboard together, and why I run it with 4 GB and stop worrying. Accept the memory and you get the most polished open-source Retool replacement there is: a drag-and-drop canvas, JavaScript in every property, and app definitions that live in git.

The single image is the right way to run it

Appsmith's official pattern, per the Appsmith docs, is one image with everything inside, and unlike most bundled containers it is worth taking as offered. The compose file is short:

services:
  appsmith:
    image: appsmith/appsmith-ce:latest
    ports:
      - "8080:80"
    volumes:
      - ./stacks:/appsmith-stacks
    restart: unless-stopped

Everything persistent (Mongo data, Redis dump, uploaded assets, the generated config) lands in ./stacks, so backup is that one directory. The container also ships an appsmithctl helper; docker exec appsmith appsmithctl backup produces an archive of the database and configuration that restores cleanly onto a fresh install, and it is the backup I trust over a raw copy of a running Mongo directory. Put a reverse proxy with TLS in front, create the first admin account in the browser, and disable open signups in Admin Settings before you share the URL.

If you already run MongoDB and Redis for other things you can point Appsmith at them through environment variables, but it buys you little and adds 2 things to keep version-compatible. Keep it bundled.

Connect apps to git before the second app exists

Appsmith serialises each application to JSON files and can push them to a git repository. Turn this on for every app from day one, pointing at a repo on your own Forgejo or Gitea. It gives you diffs when someone changes a query, a way back when a widget deletion goes wrong, and branches for trying a redesign without touching what people use. It is also the only sane path to moving an app between a staging and a production Appsmith, since the import and export buttons produce a single JSON blob with no history.

At last check the free tier caps the number of private repositories you can connect, in the low single digits, with public repos unlimited. For a home lab or a small team that cap is fine; for a department with 12 internal tools it is a line item.

Everything between double braces is JavaScript

Widgets have properties, and any property accepts {{ }} with JavaScript inside. A table's data is {{getOrders.data}}; a submit button's Visible property is {{Form1.isValid}}; a text widget shows {{moment(getOrders.data[0].created_at).fromNow()}} because a few libraries are preloaded. When expressions outgrow one line, a JS Object holds named functions the whole page can call, and that is where real logic goes: validate, run 2 queries in sequence, show a toast, refresh a table. Learn storeValue (per-session state that survives page changes) and navigateTo early and most "how do I" questions answer themselves.

The building block that saves the most time is the form-and-table pattern: a table widget bound to a select query, a form widget bound to the table's selectedRow, and an update query fired from the form's submit. That is a CRUD admin page, and it takes about 20 minutes once you have done it twice.

The database user is the security boundary

Appsmith supports 30-odd datasources: PostgreSQL, MySQL, MongoDB, Redis, REST and GraphQL APIs, Google Sheets, S3, and more. It runs SQL with prepared statements on by default, which blocks the obvious injection through a text input, but nothing in the tool stops an editor from writing DELETE FROM customers in a query and wiring it to a button. So the credential does the protecting. Create a role that can SELECT broadly and UPDATE narrowly, never a superuser, and treat any request for a broader grant as a design review.

Appsmith's own access model in the free build is 3 roles (administrator, developer, viewer) applied per workspace. That separates the people who can edit queries from the people who can only click buttons, which covers most teams. Per-app and per-resource permissions are a paid feature.

Where the paid line sits

The code is Apache-2.0, the community edition is complete for building and running apps, and the commercial tier adds what companies eventually ask for: granular role-based access, SSO through OIDC and SAML, audit logs, and Workflows for scheduled and event-driven jobs without a UI. If scheduled jobs are the main need, pair the free edition with n8n instead of paying for a feature you would use once. The automation category lists the neighbours if the low-code canvas is not what you actually wanted.

Update on purpose, not on pull

Because the image bundles a database, latest is a riskier tag here than for a stateless app; a MongoDB engine bump inside the container is a migration, and I have watched one take 10 minutes on a busy instance while everything showed a spinner. Pin a version tag, read the release notes, run appsmithctl backup first, then bump. The general practice is in container updates without fires.

What I'd do

Single appsmith-ce image on a 4 GB machine, ./stacks on a disk that gets backed up, Caddy in front, signups off. Every app git-connected to a private Forgejo repo from its first save, every datasource on a role that cannot drop a table. Prototype the same admin page in ToolJet for a day before choosing, but if the team writes JavaScript comfortably and wants version-controlled apps, Appsmith is where I would land, and where I did.