DEV Community

Xin Jiang
Xin Jiang

Posted on

Building self-hosted, single-tenant Rails apps for small manufacturers

Small manufacturers and project shops tend to run on the same stack: a shared drive, a dozen spreadsheets, and one person who remembers which file is the real one. When that person goes on holiday, the stack stops working.

I've been building two small open-source Rails apps for exactly that situation, and I want to write down the design decisions behind them, because they go against how most SaaS in this space is built.

1. Single-tenant on purpose

MuseFlow is a self-hosted PLM: CAD drawing revisions, products and nested parts, process documents, and BOM releases, all behind one approval workflow.

It is deliberately single-tenant. One deployment holds one company's data. There is no tenant_id on every table, no row-level isolation layer to get wrong, and no shared database with a competitor's drawings in it.

For a manufacturer, the drawings are the company. Asking them to trust a multi-tenant cloud with their released revisions is a harder sell than giving them a repo and saying: run it on a box in your office.

The trade-off is that every customer runs their own instance. For a product that's MIT-licensed and meant to be forked, that's fine.

2. "Released" should mean a specific revision

The most common failure I've seen on shop floors is not missing data. It's ambiguous data. Someone asks for "the released drawing" and gets whatever is in the shared folder today.

In MuseFlow, a released drawing or BOM is a specific revision with an approval record behind it: who signed off, on which revision, and when. Engineering changes are approved rather than silently overwritten, so the workflow itself becomes the audit trail.

The model is four business lines (product, part, process document, BOM), and parts can nest as components or sub-assemblies under a product or another part. That's the structure engineers already think in, so the schema doesn't try to be clever.

3. Seed data that is a real workflow

Both apps ship seed data that's an actual working sample, not empty tables:

bundle install
bin/rails db:setup
bin/rails server
Enter fullscreen mode Exit fullscreen mode

MuseFlow's seed loads a product, its parts, process documents, and a BOM, so you can walk a release end to end before reading a single model file. Stack: Ruby 4.0.1, Rails 7.1, PostgreSQL, Redis.

Repo: https://github.com/Qumge/museflow-plm

4. The same idea for project operations

Aprove AI applies the same thinking to project operations: projects and approvals, orders, deliveries, payments, invoices, partners, contracts, expenses, files, and reports in one workspace instead of six spreadsheets and three exports.

  • Rails 8.1 + PostgreSQL, MIT licensed
  • English and Chinese interface out of the box
  • bin/rails db:prepare && bin/rails db:seed creates a demo company. Log in as demo_admin and click through a real order → delivery → invoice chain.

The point of linking orders through to invoices in one chain is simple: a delivered job shouldn't live in a different spreadsheet from the money it earned.

Repo: https://github.com/Qumge/aprove-ai

Why open source and self-hosted?

Because these businesses already customise everything. Their approval chains, field names, and labels are specific to how they work. With a SaaS product they'd file a feature request. With a Rails app they own, they (or a local contractor) change the code.

If you run operations for a small manufacturer or project company, or you're a Rails dev who does contract work for one, I'd love feedback on either repo. Issues and PRs are welcome.

More of what we build is at qumge.com/en/products.

Top comments (0)