Craftplan: a self-hosted ERP for small-batch makers, built on Elixir and Ash

The gap Craftplan fills: made-to-order production, not generic ERP

Generic ERP suites assume you buy raw materials in bulk, hold finished goods in a warehouse, and sell from stock. A small bakery, a soap maker or a hot sauce producer does the reverse: orders arrive first, then batches get planned, then materials get consumed. Craftplan's README describes workflows built around that sequence, with production batching, order item allocation to batches, and automatic material consumption listed as production features. The audience is explicit in the repository description: artisanal D2C micro-businesses. That is a small segment, and the feature list reflects it. There is no general ledger, no payroll, no multi-currency treasury. What exists instead is BOM versioning with cost rollups, lot traceability on raw materials, and allergen and nutritional fact tracking. Those three are the differentiators. A food producer who has to regenerate a nutrition label after swapping a supplier's cocoa butter has a real problem that a generic invoicing tool will not solve. Craftplan's README claims first-class support for exactly that case.

Inside the Elixir stack: Ash resources, LiveView screens, PostgreSQL underneath

The tech stack line names Elixir, Ash Framework, Phoenix LiveView, PostgreSQL and Tailwind CSS. That combination explains several product decisions visible in the README. Ash gives you declarative resources with policy-based authorization, which is why the access control section can claim policies on all resources with only two roles, admin and staff. Phoenix LiveView means the interface is server-rendered and stateful over a websocket, so the Cmd+K command palette and the schedule views do not need a separate JavaScript API layer. PostgreSQL carries the relational load: versioned BOMs, lot records, stock movements, and the cost snapshots taken per production batch. MinIO appears in the deployment command, which tells you attachments such as product photos and possibly generated documents are stored as objects rather than as database blobs. The README does not describe the schema, so the exact table layout behind BOM versioning is not something I can confirm. What can be confirmed is the behaviour: editing a BOM creates a new version, older versions become read-only, and cost rollups propagate through nested BOMs automatically. Whether rollups recompute retroactively for historical batches is not stated, and that is a question worth answering before you rely on cost snapshots for pricing.

Deployment: three curl commands and a compose file

The README gives a self-hosting path that avoids cloning the repository. You download two files, copy the environment template, and start the stack:

curl -O https://raw.githubusercontent.com/puemos/craftplan/main/docker-compose.yml curl -O https://raw.githubusercontent.com/puemos/craftplan/main/.env.example cp .env.example .env docker compose up -d

According to the README, that command starts Craftplan, PostgreSQL and MinIO, with migrations running automatically. The .env.example file is where the required secrets go; the README does not enumerate them, so treat that file as the authoritative list rather than any summary. The self-hosting guide linked from the README covers single-container mode, Railway deployment and reverse proxy setup, which suggests the default compose topology is not the only supported one. For contributors there is a second path using mise: mise install, mise run services:up to start PostgreSQL, MinIO and Mailpit, mise run setup, then mise run dev for localhost:4000. Mailpit in the development services list is a sensible choice, since it means you can exercise transactional email without touching a real provider. The CI entry points are mise run test, mise run format, mise run format:check and mise run ci, with format covering Styler, Spark, Tailwind and HEEx.

Where Craftplan stops: accounting depth, scale and the AGPL boundary

The README lists invoicing but not accounts receivable ageing, tax filing, bank reconciliation or a chart of accounts. If your accountant needs a trial balance exported from the same system that plans your batches, Craftplan is the wrong tool. The same applies to scale: nothing in the material describes multi-warehouse inventory, barcode-driven picking, or carrier integrations for shipping labels. A maker shipping thirty orders a week by hand will be fine. A maker shipping three hundred will be doing a lot of clicking. There is also a documentation gap worth naming. The README advertises demand forecasting and reorder planning, but gives no description of the forecasting method, the lookback window, or how seasonality is handled. That is a feature you should evaluate against your own sales history rather than accept on the strength of a bullet point. The AGPL-3.0 licence is the other boundary. If you modify Craftplan and let users interact with it over a network, the licence's network clause generally requires you to offer those users the corresponding source. Running it unmodified for your own business is a different situation from forking it into a hosted service. I am not a lawyer and this is not legal advice; read the LICENSE file and the AGPL text before building a commercial offering on top of the code.

How it compares with Odoo and with spreadsheet-plus-shopify setups

The obvious comparison is Odoo Community, which covers manufacturing, inventory, purchasing, CRM and full accounting under LGPL. Odoo's manufacturing module is far broader: work centres, routings, MRP runs, quality checks. Craftplan's approach is narrower and, in one respect, more opinionated. BOM versioning is a first-class concept in Craftplan, with older versions locked read-only, whereas Odoo's default bill of materials model does not version the same way without add-ons. If your recipes change often and you need to know which version produced which batch, Craftplan's model maps more directly onto that need. The trade is depth everywhere else. Odoo will do your payroll and your tax returns; Craftplan will not. The other realistic alternative is a spreadsheet for costing plus a hosted storefront for orders, which is what many micro-businesses actually run today. That combination is cheaper and requires no server, but it breaks on lot traceability. Once a customer reports a problem with a jar, tracing it back to a supplier lot across a spreadsheet and an order export is manual archaeology. Craftplan's stock movements and lot creation on receiving exist precisely to avoid that. Whether the avoided cost justifies running PostgreSQL and MinIO is a judgement about your recall risk, not about feature counts.

Upgrade and maintenance cost

Craftplan is versioned and moving. The release list shows v0.7.0 on 2026-09-05, following v0.6.4 and v0.6.3 on consecutive days in early September. That cadence tells you two things. First, the project is active. Second, you are on a pre-1.0 codebase, where minor version bumps can carry schema changes. The compose file runs migrations automatically on startup, which is convenient for a first install and riskier for an upgrade: a failed migration against production data is not something the README describes a rollback path for. The practical implication is that you should take a PostgreSQL dump before pulling a new image, and pin the image tag rather than tracking latest. The mise-based contributor workflow gives you mise run test and mise run ci to check a release locally before promoting it, which is a reasonable staging approach for a small team. On the licence side, AGPL-3.0 means no per-seat cost and no vendor to pay, but it also means no vendor to call. Support routes listed in the README are the issue tracker and the documentation site. Budget for that: someone on your side needs to be comfortable reading Elixir and Ash when a migration goes sideways, or you need to be prepared to restore a dump.

Who this is for, and what to check before you commit

The fit is a food or craft producer with a handful of staff, a recipe or formula that changes, ingredients that need lot traceability, and a preference for owning the data. The email configuration supports SMTP, SendGrid, Mailgun, Postmark, Brevo and Amazon SES with API keys encrypted at rest, and the API exposes JSON:API and GraphQL endpoints with encrypted API key authentication, so integrations with a storefront or a label printer are possible without forking. The iCal feed, generated and revoked from Settings, covers order deliveries and batch schedules, which is a small feature that removes a recurring manual step. Before you migrate real data, run the CSV import for products, materials and customers against a copy of your actual catalog and check that nested BOM cost rollups match your supplier pricing. Then place one test order, allocate it to a batch, complete the batch, and confirm the cost snapshot and the stock movements land where you expect. If those two checks pass, the rest of the workflow is documented well enough to follow. If the rollup numbers disagree with your own costing sheet, you have found the boundary of the tool before it cost you a pricing decision.

Editorial conclusion

Adopt Craftplan if you run a small food, beverage or craft operation where recipe versions, lot traceability and allergen data matter more than general ledger depth, and where you are willing to run PostgreSQL and object storage yourself. Skip it if you need multi-entity accounting, payroll, warehouse-scale WMS features or a hosted SLA, because the repository shows none of those. Before committing, verify three things on your own copy of the compose file: that the .env.example secrets cover your SMTP provider, that the iCal feed URL works against your reverse proxy, and that a test BOM version rolls up nested costs the way your supplier pricing actually behaves.

Official sources

1. License: AGPL-3.0
2. Project website
3. puemos/craftplan on GitHub
4. README
5. Releases