FarmBot Web App: the Rails, TypeScript and MQTT stack behind a garden robot

Three pieces: interface, API, and the realtime channel

The FarmBot web app is a web based user interface, a RESTful JSON API, and a Dockerised MQTT server. The API stores data such as user account information, farm designs, sequences, authorization tokens and a variety of other resources, and the MQTT server facilitates realtime messaging from the browser to the device.

That last capability is the one that makes this more than a CRUD application. A robot on a garden does not want a polling loop with a lag between a command and a blade moving, so the browser talks to the device over a message broker and the state on screen is a live view rather than a periodic refresh.

The stack is unusual enough to be worth spelling out, because it is not one framework. The backend is Ruby on Rails, and the frontend is TypeScript built with Bun, and the whole thing is arranged as a set of Docker services. The repository layout shows it directly, with app/ and config/ and db/ for the Rails side, frontend/ for the TypeScript side, docker_configs/ with the Dockerfiles, and separate docker-compose.yml and Procfile entries for running it.

The release history shows a project on a steady release cadence, with v15.30.6 on 2026-09-17, v15.30.5 on 2026-09-04 and v15.30.4 on 2026-08-20, and the last push to the staging branch on 2026-10-15. The primary language is TypeScript, the licence is MIT, and the hosted instance is at my.farm.bot.

Note the default branch is staging, not main, and the project says so in its own contribution guidance, which is the kind of detail that matters if you are about to open a pull request against the wrong branch.

The README spends most of its length telling you not to self-host

This is the most unusual thing about the project, and it is deliberate rather than an accident of documentation.

The section headed I own a FarmBot, do I need this? answers no. If you are an owner of a FarmBot kit you do not need to download or self-host the software, because FarmBot Inc provides a free-to-use instance of the web app at my.farm.bot, which the README recommends to all owners, and it points at the getting started instructions for that instance.

The self-hosting section repeats it in stronger terms. Hosting your own server requires an understanding of how Ruby on Rails applications and databases operate, and the README states that self-hosting the web app will not provide a more stable user experience and may result in accidental security issues or data loss. It then gives the only handful of use cases where running a third party server may be necessary, and there are exactly two: development of new features, bug fixes and pull requests, and independent security research and auditing.

The warnings go further. If you are not a Ruby on Rails developer or have never written a Ruby on Rails application, use my.farm.bot instead of trying to self-host, because running a server is a non-trivial task that may require hundreds of hours of setup and maintenance time. Self-hosting requires an intermediate background, three to five years of experience, in Ruby, SQL and Linux system administration.

And the support section closes the door explicitly. Technical support for self hosting is beyond the scope of the basic technical support that FarmBot Inc provides with each kit, and if you pursue self-hosting you will need to operate your server independently of FarmBot Inc technical support, with the note that they do not have the resources to help novice developers learn to set up servers, environments and configurations.

That is a rare thing to find in a README, a project stating that the majority of its users should not use the thing the repository contains.

Local setup, environment variables and encryption keys

For the people the README does address, the local setup section is specific.

Self-hosted installations are recommended to be installed on a fresh Ubuntu server using the instructions provided in local_setup_instructions.sh, and those instructions are regularly checked and updated to ensure they work. At this time the project cannot provide assistance for running the web app in different environments.

The tone about issues follows the same line. If you raise an issue indicating that you have not followed the setup instructions, looked through past issues, or done a cursory internet search for basic help, expect the issue to be closed and to be pointed at the setup instructions.

The configuration section is marked important and starts with a blunt sentence. Your server will not run without setting environment variables first. You set them directly from your shell or server management tool, or by writing a .env file in the server's base directory, and example.env lists all the variables that must be set.

Encryption keys are auto-generated if they are not present, and can be reset with:

rake keys:generate

If ENV RSA_KEY is set, that is used in place of the .pem files, which the README says is useful for environments like Heroku and Docker where file system access is not allowed. That is a sensible detail to have thought about, because a container platform that mounts an ephemeral filesystem would otherwise lose the keys on every restart.

Updates are manual. The project updates main roughly every two to four weeks, and if you self-host you will need to update the software manually to get those updates. The README repeats here that technical support for self-hosting is outside the scope of the support provided with each kit.

The Docker topology, and what each service is for

The docker-compose.yml file in the repository draws its own diagram of the service layout, and it is worth reading because the shape tells you what the application depends on.

At the bottom is the web service, which depends on db and redis. The database is Postgres 17 with a restart policy of always and a named volume for the data directory. The cache is valkey 9.0, with the image referenced as valkey/valkey:9.0 and the data on a volume mounted at /data, and the port exposed rather than published, which is the correct pattern for a service only the web container talks to.

The web container is built from docker_configs/api.Dockerfile and runs Passenger with a configurable pool size and max requests, and it mounts the source tree into the container so the code is live, along with a bundle cache volume. It also opens stdin and allocates a tty, which is what makes the container usable for the interactive work the development workflow expects.

Above the web service sits the mqtt service, built from docker_configs/rabbitmq.Dockerfile, and the diagram shows the three background workers hanging off it: log_digests, rabbit_jobs and delayed_job. The layout in the comment block also shows the frontend assets and the typescript compilation as separate boxes, which reflects that the frontend is built as its own step rather than inside the web image.

The use of valkey rather than Redis is a detail worth noticing. The architecture is otherwise conventional, and the fact that it is drawn in the file means the next person to change it sees the intent.

Contributing, translating and disclosing

The contributing section is written as a list of ways in, and it is unusually concrete about the size of the tasks.

You can browse the open issues and make thoughtful suggestions. You can check the developer documentation for writing add-ons and plugins. You can search the repository for TODOs, and the README notes that sometimes these are simple tasks suitable for new contributors. You can help translate the web app into your language, and it mentions there are FarmBot owners in over 90 countries who speak a wide range of primary languages.

Translation is a four step procedure with a helper script. Fork the repository, go to /public/app-resources/languages and run the command `bun _helper.js yy` where yy is your language code, for example ru for Russian. Then edit the translations in the file that was created, where the format is a phrase mapped to a translated phrase. Then commit, push and submit a pull request.

Security disclosure has its own channel, a separate disclosure address, with the note that the project takes security seriously and values the input of independent researchers. That is consistent with the self-hosting section, which lists independent security research and auditing as one of only two valid reasons to run your own server.

The frontend tooling in the package manifest shows what a contributor has to satisfy. There is a typecheck script and a separate dev-typecheck, an eslint run over the frontend and the language files, a sass-lint and stylelint pair, a translation check with jshint over the language JSON, and a Ruby check that runs rubocop and brakeman together. The Ruby side is linted with rubocop and scanned with brakeman in a single command, and the Brakeman run skips the docker_volumes directory, which is a sensible exclusion.

The test scripts are split by cost rather than by suite, with test-slow, test-timings and test-iso running separate shell scripts, and the default test being bun test.

Editorial conclusion

Adopt this repository if you are developing a FarmBot add-on, auditing FarmBot itself, or need the API on your own infrastructure, since the REST API and the realtime MQTT channel are the integration points an add-on actually talks to. Do not self-host it as a FarmBot owner, because the README is direct that a free hosted instance exists at my.farm.bot and that self-hosting will not give you a more stable experience and may cause data loss. Before you start, read the configuration section, because the server will not run until the environment variables are set, and plan for manual updates, since the main branch is updated every two to four weeks and nothing pulls those changes for you.

Frequently asked questions

Official sources

1. FarmBot/Farmbot-Web-App on GitHub
2. License: MIT
3. Project website
4. README
5. Releases