I was thinking and exploring areas where developer tooling in OpenMRS could be improved and wanted to get some thoughts and insights from the community.
In many systems, a CLI is used to simplify tasks like setup, environment management, and maintenance. I was wondering if something similar has been considered in OpenMRS for developer/admin workflows – for example:
Initial setup and local development
Module management (install/enable/disable)
Running maintenance or scheduled tasks (e.g., archiving voided data)
Database utilities (backup, migrations, etc.)
I know that OpenMRS is primarily UI-driven for end users, so this would mainly target developers and administrators rather than clinicians.
I’m curious and open to know:
Has there been any previous discussion or attempt around a CLI for OpenMRS?
Is there any ongoing work or existing tools in this space?
Do you think such a tool would be useful, or are there other priorities that make it less relevant right now?
Would love to hear your thoughts and any pointers to past discussions or efforts.
There isn’t a unified CLI for OpenMRS today, but the Maven-based OpenMRS SDK already covers parts of this, like setting up and running local instances. However, areas like module management, maintenance tasks, and database utilities are still mostly handled via the UI or manual processes.
A CLI could be valuable, especially for improving developer productivity and enabling automation. It might make sense to build on top of existing tools (like the SDK) and start with a small proof-of-concept, perhaps focusing on module management or common maintenance tasks.
It would be great to hear if there have been past efforts or interest from others in this area.
Some kind of administrative interface is potentially something usable, especially if it facilitates managing OMRS via IaC. I would completely de-scope module management from this. We already have tooling to build distributions and we’re trying to slowly kill off the live module deploy / re-deploy parts.
A nice place to start might be with a simple utility that is able to (correctly) backup and restore an OpenMRS installation. This involves a lot more than just the database (there’s also stuff in the Application Directory).
Initial setup and deployment is something of a pain-point, but the reality is that I’ve never seen two implementations that deploy OpenMRS the same way (bare metal Tomcat / external database server, bare metal everything on one server, fully Dockerized, partially Dockerized, K8S, pre-install scripts—especially pre-loading databases, custom application initialization via modules, etc.). It’s something of a wild-west, which is one of the reasons some of this tooling is lacking.
OpenMRS’s priorities are whatever the community decides, and that basically means, if you build it, it can exist.
I think what this could use is a stronger, more opinionated vision for what the kind of tool your envisioning is. Is this, e.g., something like kcadmin, Keycloak’s “do anything” tool? Is this a tool to get new developers up and running with a working environment faster (so maybe something built on the SDK and the openmrs Node CLI?) Is this a tool for implementations, so maybe focused on building OpenMRS distributions via the SDK and deploying those, running back-ups and maybe various monitoring checks?
Thank you for the detailed insights @ibacher – this really helps clarify the direction to some extent.
The point about de-scoping module management makes sense and I was not aware off and now I will take a note for it, especially given the shift away from live module deployment. The backup and restore idea is particularly interesting and where I am mostly leaning, and I can see how that’s a more concrete and valuable problem that can be solved, especially considering the complexity around the application directory and different deployment setups.
I also understand your point about needing a clearer vision. Based on your suggestions, I’m starting to think more along the lines of a developer/admin-focused utility – possibly something around which I am thinking about that builds on the SDK and focuses on operational tasks like backup/restore and maintenance, rather than a broad “do everything” CLI which can be gradually done and implemented after the initial work for a CLI around operational tasks for OpenMRS is done and responses from the admins and community developers is received and can be then widely scoped the CLI for OpenMRS accordingly in that fields where it will needed and useful.
I am trying to explore and implement this direction further which I told above and tried to refine the idea into something more concrete. Is that so the insights which you asked for and can be it be useful and handy to do so @ibacher?
@binayak in addition to all the above, were you thinking along the lines of a CLI for LLMs to call instead of MCP servers, given that models are increasingly calling CLI tools instead of MCP servers?
That’s a new interesting perspective – I hadn’t initially considered the CLI from an LLM/tooling integration angle.
My current focus is more on building a reliable developer/admin-facing CLI for operational tasks like backup/restore and maintenance which I said above. What you mentioned adds a new dimension, and I think this could be an important direction for future extensibility.
I am primarily more familiar with Java and its ecosystem, and have been working with it along with related frameworks, which is also what attracted me towards OpenMRS as the tech stack aligns closely with my current strengths.
I do have a decent understanding of LLM-related concepts and have explored working with them, but I am not yet very experienced in solving real-world problems involving LLM integrations, especially something like integrating a CLI with LLM-driven workflows.
I think it would make sense to first focus on defining a clear and reliable set of core operations (like backup/restore), and then potentially explore how such a CLI could also act as a stable interface for higher-level automation or AI-driven workflows.
So for now, I think to focus on building a solid CLI foundation while keeping the design flexible for future extensions. As it keeps going through community feedback and real-world usage, I expect to gain more experience and then explore this direction further.
Thanks again for bringing this up – it’s definitely something I’ll keep in mind going forward!