Atlas CMMS: a self-hosted maintenance system for teams that already run Docker
#1 Self hosted CMMS web & mobile application that allows you to manage enterprise maintenance for free - Computerized Maintenance Management System
At a glance
- What is it?
- Atlas CMMS (Grashjs/cmms) is an AGPL-3.0 maintenance management application with a TypeScript frontend, a Spring Boot API and a Docker Compose deployment. It fits teams that want work orders and asset history on their own hardware, and it is a poor fit for anyone who cannot operate Postgres, MinIO and a reverse proxy.
- Who is it for?
- Adopt Atlas CMMS if you already run Docker Compose, can keep Postgres and MinIO backed up, and accept AGPL-3.0 terms for whatever you build around it. Do not adopt it if you need a vendor on the phone during an outage, or if your maintenance data must sit in a managed cloud you do not administer.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Atlas CMMS targets, and who ends up running it
Maintenance work tends to live in spreadsheets, chat threads and paper job cards until something breaks and nobody can say when the pump was last serviced. Atlas CMMS is the project's answer to that: a Computerized Maintenance Management System you host yourself, covering work orders, equipment records, inventory and service requests. The README describes it as "Jira for technicians", which is a fair summary of the shape. A work order has an assignee, a priority, logged time and a history, and the surrounding records (equipment, location, stock) are linked to it rather than kept in a separate file.
The README lists the intended industries: facilities and property management, manufacturing, healthcare, hospitality, public sector infrastructure, campuses, and utilities. Those share a property that matters for adoption. They have physical assets with service intervals, and they usually have an IT function or at least one person comfortable with containers. The project's own framing says it is aimed at "IT managers or developers looking to implement solutions", so the audience is not a maintenance planner with no technical support. If nobody on staff can read a docker-compose.yml or restore a database dump, the deployment becomes the weak point regardless of how good the work order screens are.
What the repository layout tells you about the architecture
The topics list names the stack directly: TypeScript, React and React Native with Expo on the client side, Java and Spring Boot on the server, Postgres and MinIO as the data services, all shipped through Docker. The repository is split into a frontend directory (the README references frontend/public/static/images/logo/logo.png) and an api directory (the feature list lives at api/Current features.pdf). That split matches the runtime: a web client, a mobile client built from the same React Native codebase, and a single backend that both talk to.
MinIO's presence is the detail worth pausing on. It means file attachments and images are not stored in Postgres but in an S3-compatible object store, which is why the environment table asks for MINIO_USER and MINIO_PWD alongside the database credentials. A backup plan that dumps Postgres only will leave you with work order records pointing at files that no longer exist. The nginx.conf file in the repository root is the other structural clue: the frontend is served through nginx rather than directly, so the compose file is expected to sit behind that proxy configuration, and PUBLIC_SERVER_URL exists to tell the application what address it is reachable on.
Getting it running with docker-compose and the required variables
The README's quick start is three files and one command. Download docker-compose.yml, nginx.conf and .env.example, rename the last one to .env, then run:
docker-compose up -d
The application is then reachable at http://localhost:3000. That is the whole documented happy path, and it is genuinely short.
The environment table is where the real setup work sits. Five variables are marked required: POSTGRES_USER, POSTGRES_PWD, MINIO_USER, MINIO_PWD and JWT_SECRET_KEY. The defaults shown in the table (rootUser, mypassword, minio, minio123, your_jwt_secret) are placeholders, and the README tells you to generate the JWT key with openssl rand -base64 32. Changing the Postgres and MinIO credentials after the first start is not a matter of editing .env, because the volumes will already have been initialised with the old values.
Everything else is optional and off by default. PUBLIC_SERVER_URL takes the form http://your.public.ip and defaults to http://localhost:3000, which is the value you must change before the instance is reachable from anywhere but the host itself. ENABLE_EMAIL_NOTIFICATIONS defaults to false, and INVITATION_VIA_EMAIL also defaults to false and, per the table, requires SMTP plus ENABLE_EMAIL_NOTIFICATIONS to be on before it does anything. MAIL_TYPE selects SMTP or SENDGRID, with smtp as the default, and SMTP_HOST is the first of the SMTP settings you fill in if you go that route. The README points at a demo at atlas-cmms.com if you want to see the interface before committing to a deployment.
Where the documented material runs out
The README is a landing page, not an operations manual. It covers first boot and stops there. There is no documented upgrade procedure: the releases page shows v1.6.0, v1.7.0 and v1.8.0 arriving roughly two months apart through 2026, but nothing in the supplied material describes how to move a running instance between them, whether database migrations run automatically on container start, or whether a rollback is possible. That is the single largest gap for anyone planning to run this in production, and it is a gap you would need to close by reading the compose file and the api directory yourself.
Backup and restore are similarly absent. Given the two data services, a defensible backup means a Postgres dump plus the MinIO bucket contents, and the README does not describe either. Reverse proxy and TLS configuration beyond the supplied nginx.conf is also undocumented, as is the Google Maps integration mentioned under locations, which presumably needs an API key that the environment table does not list. Treat the missing pieces as work you will do rather than work that has been done for you.
The licence decision, and what AGPL-3.0 means for integrators
Atlas CMMS is AGPL-3.0. For an internal deployment where employees use the system to maintain their own buildings or machines, the practical effect is close to that of any other open source licence: you can run it, modify it and keep your changes to yourself. The obligation that catches people is network use. If you modify the code and expose the modified version to users over a network, the AGPL's source-availability requirement is generally understood to apply to those users. That matters most for the two groups the README invites: developers building a product on top of Atlas CMMS, and service providers hosting it for clients. This is a description of the licence's usual interpretation, not legal advice, and if you are in either group you should have someone qualified read the actual terms before you ship.
The other licence-adjacent cost is maintenance. The project is active (last push 2026-09-10, releases through v1.8.0) and the README explicitly asks for contributors, which is a reasonable signal of intent but not a support contract. There is no documented commercial support tier in the supplied material. Your upgrade cost is therefore measured in the time it takes your team to read a release and test it against your data, and your risk is that a breaking change arrives with no migration notes. Pinning to a specific release tag rather than tracking main is the obvious mitigation, and it costs you the fixes in between.
When a managed CMMS is the better answer
The honest alternative is a hosted CMMS such as a commercial SaaS product, and the difference is not the feature checklist. It is who is on the hook when the database is corrupt at 2am. With Atlas CMMS that person is you: you own the Postgres instance, the MinIO bucket, the nginx configuration, the JWT secret rotation and the upgrade path. With a hosted product you trade monthly cost and data residency for someone else owning all of it. The README's own framing points at this: it is aimed at IT managers and developers, which is exactly the population for whom running the stack is cheaper than paying for it.
A second, less obvious alternative is doing nothing, and for a small site it is sometimes correct. If you have one building and a handful of assets, a shared calendar plus a spreadsheet of service dates may cover the need. Atlas CMMS earns its place when you have enough assets that the question "when was this last serviced and by whom" comes up often, when inventory levels need stock alerts, or when you want purchase orders and approvals inside the same system as the work that generated them. The README lists all three of those capabilities, and they are the features that make a spreadsheet stop working.
Who should adopt it, and what to check before you do
Adopt Atlas CMMS if you already operate Docker Compose workloads, you can back up both Postgres and MinIO, and the AGPL-3.0 terms are acceptable for how you plan to use it. The deployment path is short enough that a competent team can have a working instance the same day, and the feature set covers the core maintenance loop: work orders with priorities and time logging, equipment and downtime tracking, inventory with stock alerts, purchase orders, user roles, locations and service requests.
Do not adopt it if you need vendor support with an SLA, if your organisation cannot run its own database and object storage, or if you intend to modify the code and serve it to external users without understanding the AGPL's network clause. Do not adopt it on the strength of the README alone either, because the README does not tell you how to upgrade.
Before you commit, do four things. Read api/Current features.pdf and confirm the workflows match yours, since that file is the project's own definition of scope and the README only summarises it. Generate JWT_SECRET_KEY with openssl rand -base64 32 and set POSTGRES_PWD and MINIO_PWD to real values before the first start, not after. Set PUBLIC_SERVER_URL to your actual address rather than leaving the localhost default. And if you want email notifications, confirm SMTP_HOST and the rest of the SMTP settings work from inside the container network, because ENABLE_EMAIL_NOTIFICATIONS and INVITATION_VIA_EMAIL both default to false and the README states they require working mail configuration to do anything at all.
Editorial conclusion
Adopt Atlas CMMS if you already run Docker Compose, can keep Postgres and MinIO backed up, and accept AGPL-3.0 terms for whatever you build around it. Do not adopt it if you need a vendor on the phone during an outage, or if your maintenance data must sit in a managed cloud you do not administer. Verify first that the api/Current features.pdf list matches your workflows, that MAIL_TYPE and the SMTP settings work on your network if you enable notifications, and that you have generated JWT_SECRET_KEY with openssl rand -base64 32 rather than shipping the placeholder value.
Community notes