Does a small print farm need an ERP?

Probably not yet. A spreadsheet sitting next to a file library covers more of the business side than people expect, and it has the advantage of being obviously a spreadsheet. There is a real threshold where that stops working, and it is further out than the printer count usually quoted at you.

The answer is unsatisfying because the software category does exist and keeps getting recommended in farm threads, usually in the same breath as tools that solve a completely different problem. Separating the two halves is most of the decision.

Two different jobs that both look like “farm software”

One half is production: which file, which slice, which printer, did it finish, how much filament went into it. That is the library and fleet layer, and it is what PrintStash, OctoPrint, Mainsail, and Moonraker are about.

The other half is commercial: who ordered it, at what price, against which stock, invoiced when. That layer has its own vocabulary borrowed straight from manufacturing, and the words are not decoration. A bill of materials says a finished product consumes three printed parts, four M3 inserts, and a box. Material requirements planning takes your open orders, subtracts what is on the shelf, and tells you what to buy. A general ledger makes the whole thing reconcile at year end.

These halves touch at exactly two places: the cost of a job, and the material a job consumed. Everything else is genuinely separate, which is why one product rarely does both well.

FilaOps is the self-hosted version of the second half

FilaOps is an ERP written specifically for print shops, and it is the closest thing to a self-hosted answer here. It ships eight modules covering sales and customers, inventory across multiple locations, production orders with bills of materials and routings, purchasing, MRP, accounting with a chart of accounts and GL reporting, maintenance scheduling, and multi-user access, exposed over what the README counts as 432 REST endpoints. The stack is FastAPI on Python 3.11 with React 19 and PostgreSQL 16, deployed through Docker Compose. Version 4.1.0 landed on June 20, 2026 and added a production scheduler with a Gantt view and inventory reconciliation. Checked August 17, 2026.

Two things to know before you install it. The license is Business Source License 1.1, not an OSI open-source license, and it converts to Apache 2.0 on December 5, 2029. It is free for use that does not compete with the vendor, which covers running your own farm and does not cover reselling it as a service. And a paid PRO tier at $49 a month, $588 a year, or $2,500 perpetual carries the Bambu Lab printer integration, so the community edition is the business layer and largely not the machine layer.

That last point is the one people get wrong. FilaOps does not drive your printers. It plans and accounts for work that some other system sends to the machines.

Printago covers both halves, in the cloud

Printago is the product that does not respect the split, and the price of that is where your printers live. Shopify and Etsy orders come in as print jobs, its Gutenbed engine matches those jobs to printers with the right material loaded, slicing happens in the cloud through OrcaSlicer or Bambu Studio, and the fleet dashboard handles live status and remote control across Bambu, Prusa, Creality, Elegoo, and Klipper machines. Non-Bambu printers connect through a local bridge.

Pricing is per production slot rather than per printer: unlimited printers connect for free, and you pay for how many jobs can run at once, sold in blocks of 1, 10, 25, or 50. The free tier includes one slot and 5 GB of cloud storage. I did not get dollar figures out of the pricing page, so check it directly.

If your business is a storefront that ships printed products, this is the shortest path from order to plate, and I did not find a self-hosted equivalent of the Shopify and Etsy intake anywhere in this group. The cost is that your files, your slicing, and your printer control all live on somebody else’s servers, which is the tradeoff a lot of people self-host to avoid.

Three names that come up here and are not business systems

OctoFarm still comes up constantly in farm recommendations, and it has 357 stars to show for it, but the last release was v1.8.0-beta.11 on December 28, 2022 and the last commit to the repository landed on May 19, 2023. The repository is not archived and the README still carries a maintained badge, so the citation count keeps rolling forward on inertia. What it did was unify several OctoPrint instances behind one dashboard. It never had orders, quotes, or accounting, and starting a new farm on it in 2026 means adopting a stack that has not moved in three years. If you want the current version of that job, look at the printer controllers themselves.

3D Print Log is a cloud print journal: log a print with photos and notes, track filament and resin inventory, see success rates on a dashboard, and pull status automatically from OctoPrint or Klipper via Moonraker. It integrates with the usual slicers. What it gives you is history, which is a real input to quoting and not the same thing as a quote.

printpal.io shows up in cost discussions on the strength of its free calculator, which takes filament price and weight, print time, printer wattage, local electricity rate, optional depreciation over the printer’s useful hours, and a failure rate percentage. The formula is the right shape and matches what a real print cost has to account for. The rest of the site is AI model generation, not shop management, and a calculator forgets everything the moment you close the tab, so it prices a job without ever building the history that makes the next price better.

Where PrintStash stops

PrintStash is on the production side of that line and does not cross it. The database has no table for a customer, a sales order, a quote, an invoice, a purchase order, a vendor, or a ledger entry. Filament profiles are presets that carry cost data, not stock levels: nothing in PrintStash knows how many kilograms are on your shelf or reorders when they run out.

What it does own is the chain from file to outcome. A model holds its source mesh and its G-code revisions, one revision carries the recommended marker, and each print job records what it cost, with the cost frozen at completion so a later price change does not rewrite last quarter’s numbers. With Spoolman synced, the calculation uses the selected spool’s real price rather than a generic material preset. Measured filament use and duration come back from Moonraker only; the beta providers fall back to slicer estimates, and the compatibility matrix breaks that down per provider. Since v0.11.0 it queues G-code across the fleet with manual, default-printer, or least-busy routing, and v0.11.4 added sorting a filtered library by print cost.

So it can answer “what did this part cost to make” and cannot answer “what should I charge, to whom, against which stock”. The roadmap does not close that gap either; the next work is localization and provider reliability, not order management. The missing half is a boundary, and I would rather say that than imply it is queued up somewhere.

Running both without double counting

If you do end up with a business system and a library, the join is the print job, and the discipline is deciding which system owns each fact.

The library owns files, revisions, printer state, job outcomes, and measured consumption. The ERP owns customers, orders, prices, bills of materials, stock, and the ledger. Costs flow one way, from the job record into the order, and nothing useful travels back in the other direction.

Material is where this goes wrong. If PrintStash writes measured Moonraker consumption back to Spoolman, and Spoolman is your stock system, and the ERP also decrements the same spool from its own inventory module, one kilogram leaves the shelf twice on paper. PrintStash already guards the narrow version of this by not writing back when Moonraker manages the active spool itself, and since v0.11.3 write-back is off unless you turn it on. The wider version is your problem to design: pick one system of record for filament stock and let the others read it. Connecting Spoolman covers the mechanics on the PrintStash side.

The case for the spreadsheet

For a farm running a handful of repeat products through five machines, an ERP is a second system to install, back up, upgrade, and keep accurate, and inaccurate inventory data is worse than no inventory data because you will act on it. The day-to-day farm workflow works fine with a library, a spool tracker, and a sheet.

The point where that stops holding is not a printer count. It is when the number of open orders exceeds what you can hold in your head, when you buy filament against forecast demand rather than because a shelf looks empty, or when someone who is not you has to answer a customer’s question about an order. Those are the conditions the second half of this software was built for, and until you hit one of them, most of an ERP sits unused while still needing to be correct.

Questions that come up

Is there a self-hosted ERP built for print farms?

FilaOps is the main one, covering sales, inventory, production orders with bills of materials, purchasing, MRP, and accounting, deployed with Docker Compose against PostgreSQL. Read the license before committing: it is Business Source License 1.1, not a standard open-source license, free for use that does not compete with the vendor, and it converts to Apache 2.0 in December 2029. It also does not control printers, so it sits behind whatever already talks to your machines. General-purpose open-source ERPs like ERPNext or Odoo can be configured for a print shop, but you will be modeling filament, plates, and print time yourself.

Can PrintStash generate a quote for a customer?

No. It can tell you the cost of a print, which is the filament and the recorded or estimated time priced against your material profile or a synced Spoolman spool, and it stores that per job so you can look at what a part has actually cost across runs. A quote needs a customer, a margin, labor, packaging, shipping, and a document you can send, and none of those exist in PrintStash. Use the cost history as the input to whatever produces the quote, whether that is a spreadsheet or an ERP.

Would an ERP replace my file library?

Not on its own. FilaOps tracks a part as an inventory item with a cost and a bill of materials, which is a different thing from tracking which of six G-code slices printed cleanly on the 0.6 mm nozzle. Printago does cover both, including cloud slicing and file storage, at the price of running your production files and printer control through a hosted service. If you self-host, expect to run the two layers side by side rather than collapsing them.

Should I still be looking at OctoFarm?

I would not start there. Its last release was a beta in December 2022 and the code has not been touched since May 2023, so anything you build on it is unmaintained from day one, and it was a multi-instance OctoPrint dashboard, never a business system. Its visibility reflects how many older farm guides recommended it, not current activity. Klipper with Mainsail or Fluidd, or OctoPrint on its own, covers the machine side today.

How do the two systems actually connect?

Through the print job, usually by API rather than any built-in integration, because none of these products ship a connector for the others. A workable shape is that the ERP creates a production order, an operator or a script pulls the right revision out of the library and sends it, and the finished job’s cost and material use get posted back against the order. PrintStash exposes this over its REST API, where an API key is a login credential rather than a bearer token, so a script logs in first and uses the returned JWT. That glue is yours to write and maintain, which is a real cost to weigh against the spreadsheet.

Sources

• FilaOps and its project site for the module list, endpoint count, stack, license terms and conversion date, and PRO pricing. Release v4.1.0 dated June 20, 2026 in the repository’s release feed.
• Printago and its pricing page for order integrations, the Gutenbed routing engine, cloud slicing, supported printer brands, and the production-slot model.
• OctoFarm release feed and repository metadata for the December 28, 2022 release and the May 19, 2023 final commit.
• 3D Print Log and the printpal.io cost calculator for their respective feature sets.
• PrintStash cost, spool, queue, and history behavior from the shipped v0.11.4 release notes, and the absent tables from the schema in the repository.

Every external tool above was checked on August 17, 2026, and this group moves quickly enough that prices and feature lists are worth reconfirming before you commit to one.

For the production side on its own, a self-hosted stack for a small farm covers the software that runs the machines, and how PrintStash compares to the alternatives separates libraries from monitors and farm platforms. If what you actually need is the step before all of it, setting up customer job submission covers building an intake channel without an ERP behind it.