# Appsmith's Dockerfile fails the build on purpose, and its own links disagree on the branch

> Appsmith is an Apache-2.0 low-code platform for admin panels, internal tools and dashboards, connecting to more than 25 databases and any API, and it deploys by Docker, Kubernetes or AWS AMI. The repository is more revealing than the README about how it is actually built: the image cannot be produced by a plain docker build, the default branch is release while two contribution links point at master, and the env file ships with login, signup and telemetry on.

**appsmithorg/appsmith** — Platform to build admin panels, internal tools, and dashboards. Integrates with 25+ databases and any API.

- Repository: https://github.com/appsmithorg/appsmith
- Website: https://www.appsmith.com
- Stars: 40,970 · Forks: 4,781
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/appsmithorg-appsmith

## The image refuses to build unless the project's own script ran first

The Dockerfile opens with `ARG BASE` and `FROM ${BASE}`, so the base image is injected rather than named. It then copies a prepopulated filesystem from deploy/docker/fs, and before anything else it runs a check block that exits the build on a missing file:

```
if ! [ -f info.json ]; then
  echo "Missing info.json" >&2
  exit 1
fi

if ! [ -f server/mongo/server.jar ]; then
  echo "Missing MongoDB server.jar file. Are you using the build script?" >&2
  exit 1
fi
```

It then copies three build outputs that have to exist first: the client build into an editor directory, the rts package dist, and the mcp package dist.

So a plain `docker build` on a fresh clone fails twice, and the second failure message names the build script for you. The file is an output of that script rather than an entry point to it, which is a legitimate design for a Java, Node and MongoDB image, and a rough one for anyone who arrives at the Dockerfile first.

## The default branch is release and two contribution links point at master

The repository's default branch is release. Read the Contributing section and the branches disagree with each other. The Code of Conduct link is written against the release branch, while the Contribution Guide link and the local development setup link are both written against master.

That mix matters more than it looks for a first-time contributor, because the contributing and local development instructions are the two links a new person actually clicks. Following them lands on a branch that is not the branch releases are cut from, so the setup steps you read may describe a tree that differs from the one you would get by cloning the default.

The consequence is small in the worst case and annoying in the common one. Nothing here suggests the two branches have diverged in a way that breaks the instructions, and the file gives you no way to check. What it does mean is that the branch name in a URL is not a reliable signal about which tree is current, so a contributor reading setup instructions has no basis for deciding whether the guide they followed still applies.

## Three releases in fifteen days, all on the 2.4 line

The release record is dense at the top. v2.4 landed on 2026-09-09, v2.4.1 on 2026-09-17, and v2.4.2 on 2026-09-24. The last commit to the repository is 2026-09-29, five days after the newest tag.

Two patch releases eight and seven days apart is a fast cadence for a platform you self-host and depend on. It is good news in one direction, since fixes land quickly, and a cost in the other, since a version you pinned and validated is behind within a fortnight.

The file offers no stability signal against which to weigh that. There is no long-term support line named, no release channel, and no statement about which versions receive backports. The only handle on versions is the releases page linked from the badge row at the top.

The consequence is that version choice is entirely yours to reason about. For an internal tool that a team can rebuild at will, a fast cadence costs little. For something wired into an operations runbook, you are choosing your own upgrade window because the project has not named one for you.

## The image makes /etc world-writable and strips setuid from everything

One RUN block prepares the filesystem. It finds shell scripts while pruning node_modules and makes them executable, then makes the files under /opt/bin and the Watchtower hooks executable, then strips privilege bits:

```
find / \( -path /proc -prune \) -o \( \( -perm -2000 -o -perm -4000 \) -exec chmod -s '{}' + \) || true
```

After that it creates the mongosh directory and the appsmith-stacks directory, and applies permissions: `chmod ugo+w /etc /appsmith-stacks` and a recursive `chmod -R ugo+w` across /var/run, /.mongodb, /etc/ssl and /usr/local/share.

Read that as a security posture rather than a chore list. Every setuid and setgid binary outside /proc loses its bit, which is a genuine hardening choice, and /etc becomes writable by any user in the container. The trailing `|| true` means a failure to strip passes silently.

The consequence for the person running the container is that it is deliberately not a normal Linux filesystem. Any tool that expects a setuid helper, or that protects its own configuration because /etc is root-owned, will behave differently here, and the differences are invisible until they matter.

## Watchtower hooks are baked into the image you did not choose

Among the final instructions is a label pointing at a hook script inside the image, keyed to the Watchtower container automation tool's lifecycle pre-check, and the earlier block makes every file under /watchtower-hooks executable along with the rest of /opt/bin.

That is a deliberate integration. The image is built to be inspected and replaced by an automated updater, and the pre-check hook runs before an update is allowed to proceed.

Nothing in the README mentions Watchtower, Docker Compose, or any update strategy. The installation section is a three-row table linking to Docker, marked recommended, Kubernetes, and AWS AMI guides, and a pointer to the wider installation guides.

So the consequence is that you inherit an update path whether or not you asked for one. If you are running the image under an orchestrator that honours those labels, your Appsmith can be replaced underneath running sessions, and the only description of the pre-check logic is a file path inside the container you are about to start. Read the hook before you let anything manage the container for you.

## Twenty-five env keys, and the four disablers all sit unset

The example env file is the most complete configuration surface in the repository, and it is worth reading as a list of what the platform talks to. It covers Sentry, a Smart Look id, Google and GitHub OAuth client ids and secrets, Segment, a client log level that takes debug or error, five mail settings for host, port, username, password and enablement, two SMTP toggles, three Google Recaptcha keys, and a Pylon in-app chat id with its own disable switch.

Now look at the defaults. `APPSMITH_FORM_LOGIN_DISABLED`, `APPSMITH_SIGNUP_DISABLED` and `APPSMITH_DISABLE_TELEMETRY` are all present and all empty, which means the features they govern are on. The telemetry entry carries a comment that it only takes effect in self-hosted scenarios, alongside a link to documentation about the anonymized data collected.

The consequence is a default posture worth deciding on deliberately. A fresh self-hosted deployment accepts form logins and signups, and reports usage, and the file never tells you which of the two installation routes changes that. If you want the first two closed, you set two variables before the first request, not after.

## Appsmith Agents is the longest prose block and the only part with no repository behind it

The Agents section is marketing copy, and it is longer than the rest of the file combined. It introduces an agentic AI platform that integrates the latest AI models with private and proprietary data at scale, inside the tools teams already use. It says this expands generative AI capabilities for millions of knowledge workers across sales, support, customer success and human resources. It says teams get continuous context to models so they can ask questions and configure automations for their business without model fine-tuning or complex RAG implementations, and it sends you to appsmith.com/ai.

None of that is checkable here. The repository contains no model configuration, no provider list, and no self-hosted install path for Agents.

MCP is the interesting near-miss. It is one of the most common things people look for in a platform like this, the Dockerfile has a dedicated line copying the mcp package dist into the image, and the README never says the word. So a headline integration is visible only as a directory that gets copied, and the feature pitch that does appear is the part with nothing behind it in this tree.

## Conclusion

Choose Appsmith if you want to build internal dashboards and admin panels against many databases without writing a front end, and if the fact that the image has to be produced by the project's own build script rather than by docker build is something you are willing to plan around. Pass on it if you need a self-hosted install with a documented feature parity story, because the file never states what the cloud signup gives you that the self-hosted image does not. Before you deploy, read three things: the Dockerfile, which exits 1 on a missing info.json or MongoDB server.jar and which chmods /etc to world-writable while stripping setuid across the image; the .env.example, where APPSMITH_FORM_LOGIN_DISABLED, APPSMITH_SIGNUP_DISABLED and APPSMITH_DISABLE_TELEMETRY all sit unset; and the branch situation, since the default branch is release while the contribution and local development links point at master.

## FAQ

### what is appsmith

It is an open-source low-code platform for building custom applications such as dashboards, admin panels, customer 360 views, IT automation and service management tools. It streamlines custom application development, deployment and maintenance, and the project describes it as integrating with more than 25 databases and any API.

### how to install appsmith

The file gives two routes: sign up on Appsmith Cloud, or install on your own machine. For self-hosting it names three guides, Docker marked as recommended, Kubernetes, and AWS AMI, plus a link to the full installation guides. The file contains no command of any kind, so the guides are where the commands live.

### Is Appsmith free to use?

The repository is Apache-2.0 licensed and the file calls Appsmith an open-source low-code platform, and it also points to a separate Appsmith Cloud you can sign up for. The file states no price for the cloud and no difference in features between the cloud and the self-hosted image.

### is appsmith self hosted free

The self-hosted route is the three installation guides, Docker, Kubernetes and AWS AMI, and the repository license is Apache-2.0. The file does not describe any feature difference, usage limit or cost for self-hosting compared with the cloud signup, and it does not state what the telemetry setting covers beyond noting it only takes effect in self-hosted scenarios.

### is appsmith open source

Yes by the project's own description. The file calls it an open-source low-code platform, the repository carries an Apache-2.0 license and a LICENSE file, and the source is on GitHub with a contribution guide, a code of conduct, a good first issues query and a security file at the top level.

## Sources

- [Official documentation](https://www.appsmith.com)
- [Official README](https://github.com/appsmithorg/appsmith#readme)
- [Project repository](https://github.com/appsmithorg/appsmith)
- [Release notes](https://github.com/appsmithorg/appsmith/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/appsmithorg-appsmith