farmOS

Self-hosted farm management, honestly reviewed. Built on Drupal and backed by USDA and Cornell — but is it for you?

TL;DR

• What it is: Open-source (GPL-2.0) web-based application for farm management, planning, and record keeping — built on top of Drupal and designed as a standard platform for agricultural data [README].
• Who it’s for: Independent farms, agricultural researchers, and land conservation organizations that need structured, interoperable farm records — not a general-purpose farm app for casual use [README][4].
• Cost: Free to self-host under GPL-2.0. Managed hosting available via Farmier (pricing not publicly listed) [README].
• Key strength: Serious institutional backing (USDA, Cornell, Vermont Agency of Agriculture, multiple land conservation nonprofits), a well-specified data model designed for interoperability, and a modular Drupal architecture that can be extended without forking [README][4].
• Key weakness: 1,244 GitHub stars is a niche signal. Built on Drupal (PHP stack, 2000s-era architecture). The UX reflects its origins. Third-party user reviews are scarce — this is not a tool with a Reddit fanbase [README].

---

What is farmOS

farmOS is a web application for recording what happens on a farm: land use, inputs, harvests, observations, equipment, and livestock. The GitHub repository’s description is deliberately plain: “A web-based farm record keeping application.” [README] That’s the right framing. This is not an AI-powered smart farming platform or a dashboard full of predictive analytics. It is structured digital record keeping, replacing spreadsheets and paper logs.

What makes it architecturally interesting is the platform it runs on. farmOS is built as a Drupal distribution — meaning the entire server is a configured Drupal CMS under the hood [website]. Drupal gives it modularity (you install additional capabilities as Drupal modules), a battle-tested permission system, a JSON:API-based REST interface, and a security track record. It also gives it Drupal’s age and complexity as baggage.

The project is maintained by a community of volunteers led by Michael Stenta, who has been the primary maintainer for over a decade [README]. Unlike many open-source projects where “community” means two people, farmOS has serious institutional patrons: Cornell University, the USDA Natural Resources Conservation Service, the Vermont Agency of Agriculture, the US Forest Service International Programs, and a dozen agricultural research organizations [README]. That list is not decoration. It means the project is used in actual USDA-affiliated research contexts, not just by one farmer in Vermont who put it on a Raspberry Pi.

The project uses OpenCollective for funding and GitHub for code. As of this review, it has 1,244 GitHub stars. For context, Nextcloud has 28,000+. That star count tells you something important: farmOS is a specialist tool with a genuine user base in a narrow domain, not a breakout consumer product.

---

Why people choose it

The reasons farmOS gets deployed over alternatives tend to fall into three categories.

Institutional requirements and data interoperability. The farmOS Data Model — the underlying schema that defines what a “log,” “asset,” “location,” and “quantity” mean — is intentionally designed to be a standard that different systems can speak [4]. An alternative implementation project (Runrig farmOS) describes the goal clearly: the farmOS Data Model exists so that data can move between farm management systems without losing meaning [4]. If you’re a researcher needing records that conform to an agricultural data standard, or a land trust managing dozens of farms that need to aggregate data, this matters. It’s why USDA-affiliated organizations fund and use it [README].

GPL-2.0 self-hosting without vendor dependency. Farm records contain sensitive operational data — yields, input costs, field histories. Depending on a cloud provider to store this indefinitely is a real risk for farmers who’ve seen ag-tech companies acquired, pivoted, or shut down. farmOS running on your own server means your records exist on your hardware under your control, under a license that guarantees the code remains open [README].

Community module ecosystem built on Drupal. Because farmOS inherits the Drupal module system, capabilities like offline mobile logging, sensor data ingestion, livestock tracking, and equipment management can be installed without touching core code [website][4]. The farmOS GitHub organization hosts multiple satellite repositories for these integrations. Researchers at organizations like Rothamsted Research and Point Blue Conservation Science have contributed integrations for their specific monitoring needs [README].

---

Features

Based on the README, website documentation, and the Runrig architecture overview [4]:

Core record keeping:

• Logs: activities, observations, inputs, harvests, seedings, transplantings, soil amendments — each type captures structured data, not free text
• Assets: land, plantings, animals, equipment, materials, structures — tracked as entities with their own histories
• Areas/locations: geographic areas managed with farm-specific geometry (field boundaries, bed maps)
• Quantities: structured numeric data attached to logs (weight, volume, length, count)

Planning and scheduling:

• Plan-type logs (pending vs. completed) allow forward scheduling
• Multi-season record history attached to specific fields and assets

Architecture and extensibility:

• JSON:API-based REST API for integration with external systems [4]
• Drupal module system for adding capabilities
• Docker deployment (official Docker image available, tracked on Docker Hub) [README]
• Role-based access control inherited from Drupal
• Mobile logging via companion apps (documented separately from the main repo)

Data model:

• farmOS Data Model v2 — a formalized schema that Runrig describes as designed to support distributed architectures, P2P and federated data exchange between farm management systems [4]
• Asset-centric design: an asset (a field, an animal, a piece of equipment) is the anchor, and logs are events that reference assets

What it does not have out of the box:

• Native financial accounting (this is not QuickBooks for farms — despite the “finance” category tag in the metadata, farmOS does not do bookkeeping)
• IoT sensor dashboards without additional modules
• AI or ML features
• Multi-tenant SaaS mode (it’s designed for single-farm instances, though Farmier provides managed hosting)

---

Pricing: SaaS vs self-hosted math

farmOS self-hosted (GPL-2.0):

• Software license: $0
• A VPS with 2GB+ RAM to run Drupal: $5–15/month on Hetzner, Contabo, or DigitalOcean
• Your time to configure Drupal, set up Docker, and maintain updates

Farmier managed hosting: The README points to Farmier (https://farmier.com) as the official managed hosting option, described as offering “affordable options for individual farms and organizations” [README]. Farmier’s specific pricing is not available in the data provided for this review — you’d need to contact them directly for current plans.

Commercial agricultural software for comparison: The commercial farm management market (Granular, AgriWebb, Trimble Ag) typically runs $500–$2,000+ per year for full-featured plans, often priced per acre or per user. These tools offer polished mobile apps, agronomist support, and integrations with precision agriculture hardware that farmOS does not match. The trade-off is complete vendor dependency and data that lives on someone else’s cloud.

For a small independent farm willing to do the setup work, self-hosted farmOS on a $6 VPS is a compelling alternative to paying $500+/year for a SaaS that may discontinue your plan. For a commercial operation needing field-level yield mapping and equipment telematics, farmOS is not the right tool regardless of price.

---

Deployment reality check

farmOS provides a Docker image (tracked on Docker Hub [README]) and official installation documentation at farmOS.org. The underlying stack is PHP/Drupal, which means the deployment is more involved than a single-binary Go app or a simple Node.js container. Drupal has its own configuration management, database migration layer, and update procedures.

What you need:

• A Linux server (VPS or on-premise) with at least 2GB RAM
• Docker and Docker Compose, or a LAMP stack (Linux, Apache/Nginx, MySQL, PHP)
• A domain and HTTPS termination (Caddy or nginx with Let’s Encrypt)
• MySQL or PostgreSQL as the database backend
• Comfort with Drupal’s admin interface — configuration is done through Drupal’s UI, not YAML files

What can get complicated:

• Drupal updates require running database updates through the Drupal web UI or Drush CLI — it’s not a simple docker pull and restart cycle
• Module compatibility: adding community Drupal modules for farmOS-specific features requires matching Drupal version compatibility
• The mobile companion apps (for offline field logging) are separate installations that point back to your farmOS server — they’re not bundled
• There is no “one-click install” in the Coolify/Caprover sense — you’re setting up a Drupal site, not a standalone app

For a technically confident user comfortable with PHP hosting, the setup is manageable. For a non-technical farmer, Farmier’s managed hosting is the practical path.

---

Pros and cons

Pros

• GPL-2.0 licensed. Your farm records don’t leave your infrastructure. The code is open and forkable [README].
• Serious institutional backing. USDA, Cornell, the Vermont Agency of Agriculture, and 15+ agricultural research institutions fund and use this project. That’s meaningful validation for longevity [README].
• Formalized data model. The farmOS Data Model is explicitly designed for interoperability — it’s meant to be a shared standard, not a proprietary schema [4]. If you need to exchange data with research partners or aggregate data across farms, this matters.
• Modular via Drupal. The module system allows capabilities to be added without touching core code. A decade of community modules for livestock tracking, sensor ingestion, and research logging already exists [website].
• Active development. Regular commits and a maintained Docker image suggest this is not abandonware [README].
• JSON:API REST interface. External systems can read and write farm data through a documented API [4].

Cons

• Low GitHub star count (1,244). Compared to mainstream self-hosted tools, this is a small community. Fewer stars means fewer forum posts, fewer tutorials, and less unofficial support [README].
• Drupal complexity. Running Drupal in 2026 is a specific technical commitment. Updates, module management, and the admin interface are not beginner-friendly. Most self-hosters aren’t familiar with Drupal’s architectural concepts.
• No mobile-native experience. The core application is a web app. Companion apps for offline field logging exist but are separate deployments, not bundled [website].
• Farmier pricing opacity. The only managed hosting option doesn’t list prices publicly. You’re negotiating with one vendor, which undermines some of the “escape vendor dependency” appeal.
• Not a financial tool. Despite appearing in a “finance” category in some listings, farmOS does not do bookkeeping, invoicing, or payroll. If you need farm financial management alongside record keeping, you need a separate tool.
• Limited third-party reviews. The third-party articles provided for this review did not include farmOS-specific user experiences. Community discussion appears primarily in farmOS.discourse.group and Matrix, not the mainstream tech review sites — which makes independent validation difficult.

---

Who should use this / who shouldn’t

Use farmOS if:

• You’re an independent farm, land trust, or agricultural research organization that needs structured, self-hosted farm records
• Your work involves data that needs to conform to agricultural standards and be shareable with research partners [4]
• You or someone on your team is comfortable setting up and maintaining Drupal on a Linux server
• You want your farm data on infrastructure you control, not a SaaS that can raise prices or get acquired
• You’re receiving funding from government or nonprofit agricultural programs that may require documented record keeping

Skip it (use Farmier’s managed version) if:

• You need farmOS’s capabilities but don’t want to manage a Drupal server
• You’re a farmer, not a systems administrator

Skip it entirely if:

• You want a modern mobile-first farm app with slick UX — look at commercial options like AgriWebb or Granular
• You need farm financial accounting — farmOS won’t replace your accounting software
• You’re a non-technical founder who stumbled here looking for a general-purpose farm management SaaS — the setup overhead is real
• Your farm operation is small enough that a spreadsheet covers your record-keeping needs

---

Alternatives worth considering

• Farmier — the official managed hosting for farmOS. Same software, no server management. Pricing by inquiry [README].
• AgriWebb — commercial, mobile-first livestock management platform. Polished UX, enterprise pricing, no self-hosting option.
• Granular (Corteva) — enterprise ag management, field-level record keeping and agronomy. Built for large commercial operations.
• OpenFarm — community-contributed growing guides rather than record keeping; a different category entirely.
• Runrig farmOS — an experimental alternative implementation of the farmOS data model in Rust, designed for distributed/P2P architectures [4]. Not production-ready, but represents where farmOS’s data model may evolve.
• AtoB / Farm-specific ERP tools — if financial tracking is your primary need, a purpose-built ag-finance tool is more appropriate than farmOS.

The realistic comparison is farmOS self-hosted vs. Farmier-managed farmOS vs. a commercial SaaS. If you’re committed to the farmOS data model and self-hosting, there’s no direct competitor with the same institutional credibility and interoperability focus.

---

Bottom line

farmOS is a real tool solving a real problem for a specific audience — and that audience is not “non-technical founders escaping SaaS.” It’s farms, researchers, and land conservation organizations that need structured agricultural records with serious institutional backing and data portability. The GPL-2.0 license, the USDA and Cornell sponsorships, and the explicitly designed-for-interoperability data model are its strongest cards. The Drupal tech stack, the 1,244 GitHub stars, and the absence of a slick modern UX are the honest caveats. If you’re a farmer who wants to stop losing records in spreadsheets and you have someone technical to help with setup, farmOS on a $10 VPS is a credible choice. If you’re a research organization needing standardized agricultural data that can be shared with USDA partners, farmOS may be the only open-source option designed for that use case. If you want a farm management dashboard that looks like a modern SaaS app, this is not that.

---

Sources

1. farmOS GitHub Repository and README — “farmOS: A web-based farm record keeping application” — https://github.com/farmos/farmos (1,244 stars, GPL-2.0, maintained by Michael Stenta and community)
2. farmOS Official Website — farmOS.org — https://farmos.org/ (hosting guide, installation guide, community forum, newsletter)
3. Farmier — Official managed hosting for farmOS — https://farmier.com (referenced in farmOS README as the official paid hosting option)
4. Jamie Gaehring, Runrig/Codeberg — “Runrig farmOS: An alternative implementation of farmOS built for distributed computing scenarios” — https://codeberg.org/runrig/runrig-farmos (concept paper describing the farmOS Data Model, Standard farmOS architecture, JSON:API interface, and distributed computing design goals)