OpenConstructionERP: a self-hosted construction ERP built from replaceable modules

Eight company types and fifteen roles sit behind the estimating screen

OpenConstructionERP targets the estimating and cost control half of a construction company: bill of quantities, quantity take-off from drawings, scheduling, cost modelling and tender preparation. The README describes all of it as one self-hosted platform rather than a set of disconnected tools.

The headline sizing numbers should be read as product claims rather than measurements, because no independent figure supports them. The project description lists 120,000+ priced cost items, 44 languages, cost data for 40+ markets, 190+ modules and 293 guided cases. The most revealing of those is the guided case count, which describes a guided path through the product rather than a technical capability. Companies arriving from a spreadsheet and a PDF quantity survey are the intended audience. So are teams that already run a larger ERP and want estimating pulled out of it, which is where the self-hosted packaging earns its keep.

The module manifest is the architecture, and it is yours to break

The design is legible in the directory layout rather than in a hand-drawn diagram. The repository root separates backend/, frontend/, modules/, packs/, packages/, services/, tools/ and deploy/, with MODULES.md and a data/ directory of seed content at the top level.

The README frames the whole thing with a WordPress analogy: modules come from a marketplace, you can drop in your own, and you can replace theirs with custom-built ones. The module honeycomb diagram shades each cell by the category its own manifest declares and by how many other modules it is wired to, so dependencies are visible before anything is installed. That makes module selection a planning exercise with a dependency surface rather than a settings checkbox.

The cost of that freedom shows up later. A module you replace is a module you now have to maintain, and the wiring an upstream module expects may not survive a rewrite. That is a fair trade for firms with in-house development capacity and a poor one for a small estimator who simply wants a quantity survey out the door.

Three ways in: PyPI, the desktop app, and the make targets

The project offers three entry points, and the quickest to evaluate is the packaged Python distribution on PyPI:

pip install openconstructionerp

That installs the CLI and library surface named in the project description. For a look at the product without touching a server, the README points to downloadable desktop builds for Windows, macOS on Apple Silicon, and Linux in .deb and .AppImage form, under the tagline that no Python and no Docker are needed.

For development against the full stack, the Makefile documents a two-terminal flow that keeps the setup cross-platform:

make setup && make dev

The two targets that actually start the services are separate, and the Makefile help text tells you to run one in each terminal:

make dev-backend
make dev-frontend

The backend serves on port 8000 and the frontend dev server on port 5173, while the quick start target is documented as landing on http://localhost:8080. A separate Makefile target brings up PostgreSQL, Redis and MinIO only, and an infra-ai target adds Qdrant under the ai compose profile, so you can start without the vector store.

The cost catalog is the product, and its edges are undocumented

Every estimating workflow here bottoms out in a priced catalog. The project description puts the size at 120,000+ priced positions across 44 languages, with cost data for 40+ markets, and the README summary table counts 47 countries and 6 CAD formats.

Language coverage is the part that matters most to a multi-market quantity surveying firm, because catalog labels are what an estimator reads while pricing. Input breadth is wide: the topic list names CAD, BIM, IFC, GAEB and DIN 276, and the description frames it as PDF, CAD and BIM take-off with AI cost matching.

Two boundaries are worth stating plainly. The README does not say which model or provider performs the AI matching, nor whether matching runs against your own catalog or the shipped one, so treat it as a feature to trial on your own drawings rather than a stated accuracy. And the count of 6 CAD formats is given without a list, so confirm your drawing sources are covered before you commit a pilot to it.

Five services, one database called openestimate

The compose file is the honest dependency list. The database runs on a DuckDB-backed PostgreSQL image, and the schema it initialises is named openestimate:

  postgres:
    image: pgduckdb/pgduckdb:16-main
    environment:
      POSTGRES_USER: oe
      POSTGRES_PASSWORD: oe
      POSTGRES_DB: openestimate

Alongside it sit Redis 7 on Alpine, MinIO for object storage, and Qdrant for the vector side, plus a Celery worker built from the backend directory. The compose file states the worker's own contract in a comment: it reads job identifiers from Redis and dispatches them to the generic oe.dispatch_job task, which looks up the registered handler in app.core.job_runner. Background work is therefore routed through one dispatch point rather than a per-module queue.

The environment file names the matching variables, and it is worth reading them before your first run:

DATABASE_URL=postgresql+asyncpg://oe:oe@localhost:5432/openestimate
REDIS_URL=redis://localhost:6379/0
S3_BUCKET=openestimate

Note that Redis is described as optional, falling back to in-memory when it is absent, which is convenient for a trial and unsuitable for a server with more than one worker process.

AGPL-3.0 reaches further than a permissive licence would

OpenConstructionERP is licensed under AGPL-3.0, and the practical consequence for a construction firm is that offering the software to users over a network brings the corresponding source obligation with it. For an internal estimation team that never exposes the platform outside the company, the licence is largely a non-event. For a consultancy that hosts the platform for clients, or a vendor who plans to resell it as part of a service, the copyleft terms are the first thing to read and settle.

The repository follows the customary formalities of a project that expects scrutiny: LICENSE, NOTICE, COPYRIGHT, AUTHORS.md, SECURITY.md, CONTRIBUTING.md and CODE_OF_CONDUCT.md are all present at the root, and a .gitleaks.toml and a .pre-commit-config.yaml sit alongside them. The README also carries a CodeQL workflow badge and a Sigstore signed releases badge, which means release artifacts are signed and can be verified before you install one.

Licence and signing together answer two different questions. The signature tells you the binary came from the project. The licence tells you what you may do with it once it is running. Neither substitutes for the other.

Compared with a single suite, the module marketplace is the real trade

The usual alternative to a project like this is a single licensed suite that bundles estimating with finance, procurement and reporting, sold per seat on a hosted platform. The difference in approach is not the feature list, it is the boundary of the unit of work. A suite asks you to migrate your whole workflow into one vendor's model and accept its release cadence. A module marketplace lets you keep the estimating, scheduling and tendering parts and skip everything else, and it lets you replace exactly one module when it stops fitting.

That flexibility only pays if you can absorb the consequence. Module manifests declare categories and wiring, so a custom replacement has to satisfy the same contract as the original. A team without someone who can read backend/ and MODULES.md will find the marketplace a liability rather than an asset.

The other alternative worth naming is the single-purpose estimating tool, often a desktop application with no server component. OpenConstructionERP is the heavier choice by design: five services, an environment file, a worker process, and a database named openestimate. In exchange you get a multi-user environment with a priced catalog and take-off in the same place.

The documentation stops where the deployment gets interesting

Several operational details are explicit in the environment file, and they are the ones you will trip over. The shipped defaults are the credentials oe and oe for the database and minioadmin for object storage. TRUSTED_PROXIES defaults to loopback and private ranges only, so a reverse proxy on another host will be ignored until you widen it. ALLOWED_ORIGINS points at http://localhost:5173, the development frontend, so a real deployment needs it changed. A development-only flag exposes the plaintext magic link token and PIN from the field request, and the file states it is ignored when APP_ENV=production.

Two more constraints are documented plainly. The 3D globe draws raster tiles only and shows shaded relief by default, because no free public raster street service permits application use, so a real map needs your own tile server with its XYZ template and the credit its licence requires. And the AI profile is opt-in: Qdrant is started under a compose profile rather than by default.

The gap is what is not written. The README does not document a rollback procedure, nor an upgrade path for the compose stack, and release numbering moves fast across v18.6.3, v18.6.4 and v18.7.0 within a few days. Plan your own upgrade rehearsal against a copied database, because the project does not describe one for you.

Editorial conclusion

OpenConstructionERP fits estimating teams that want to replace spreadsheet and PDF take-off with a self-hosted module they can extend, and it does not fit firms that need accounting or payroll in the same install, because the described scope stops at BOQ, take-off, scheduling, cost modelling and tendering. Before adopting it, check three things against your own drawings and prices: which of the 6 CAD formats you actually need, how AI cost matching behaves on your own catalog, and whether the default credentials and proxy settings in .env.example have been replaced. Settle the AGPL-3.0 obligations and the module wiring before the first pilot project.

Frequently asked questions

Official sources

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