OpenOps: a no-code FinOps workflow engine you host yourself
The batteries-included, No-Code FinOps automation platform, with the AI you trust.
At a glance
- What is it?
- OpenOps bundles a workflow editor, an Excel-like table store and a dashboard layer so FinOps teams can turn cost findings into executed actions. The self-hosted docker-compose install is the interesting part, and it is also where the operational questions start.
- Who is it for?
- Adopt OpenOps if you already have cost findings coming out of AWS, Azure or GCP tooling and the missing piece is the execution and approval layer, and if you are willing to run the docker-compose stack yourself. Do not adopt it as a cost visibility tool: it consolidates and acts on opportunities rather than generating the underlying billing analysis.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- 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 gap OpenOps is aimed at: findings that never become changes
The README frames the problem in one sentence about practitioners who have visibility tools that surface cost-saving opportunities but lack implementation capabilities. That is a specific complaint, not a general one. A rightsizing recommendation sitting in a vendor dashboard is worth nothing until someone opens a ticket, gets an approval, and runs the change. OpenOps positions itself as the layer that consolidates opportunities from native and third-party FinOps tools, suggests practical actions, and lets you customise the pre-built ones or author new ones. The intended audience follows from that: FinOps practitioners, plus the engineers, DevOps and finance people who have to sign off on the change. The no-code editor is what makes the first group able to build the workflow without filing an engineering ticket of their own.
Workflow engine, table store and dashboard shipped as one stack
Three components appear in the material. The workflow editor is where you build from scratch or customise a pre-built workflow. OpenOps Tables is described as the project's own Excel-like database, and OpenOps Analytics is its own visualisation system. Both are bundled rather than expected as external dependencies, which is the architectural decision that matters most here. A workflow that detects idle RDS instances, writes an opportunity row into a table, waits for a human decision, and then acts, needs somewhere to persist that state and something to show it. Shipping the store and the view inside the same product removes the integration work, at the cost of adopting a second database and a second reporting surface alongside whatever you already run. The README also lists human-in-the-loop controls across multiple channels for critical approval workflows, which is the mechanism that keeps a de-provisioning step from firing unattended.
What the repository does and does not tell you about internals
TypeScript is the primary language, and the topics list names an MCP server and MCP tools alongside the workflow engine. That tells you the integration surface is being built for agent-style tool calling as well as for the editor, but the README does not document the MCP endpoints, the tool schema, or how an external agent authenticates to them. The repository layout is not included in the supplied material either, so the split between the editor, the tables service and the analytics service cannot be confirmed from what is here. Treat the MCP angle as a signal of direction rather than a documented interface you can plan against today.
Installing the self-hosted stack
The README states OpenOps is available two ways: a managed cloud service with no infrastructure requirements, automatic updates and support SLAs, and a free docker-compose-based installation that can run locally or in the cloud. The quick start guide lives at the documentation portal under getting-started/quick-start-guide, and that page is where the actual compose file, environment variables and service definitions are described. The README itself does not print the compose command or list the configuration keys, so anyone evaluating the self-hosted path should read the quick start guide before assuming a single up command covers the whole stack. What the README does confirm is the shape of the deployment: a compose-based install, self-hosted, free of charge, with the update process left to you rather than handled automatically as it is on the managed service.
The self-hosted trade: you own the upgrade path
The release history shows a steady cadence: 0.6.23 in March 2026, 0.6.24 in April, 0.6.25 in May, with the last push to the default branch in September 2026. That is roughly monthly minor releases, and it means a self-hosted deployment accumulates upgrade work at that rate. The managed option explicitly includes automatic updates and maintenance, which is the clearest statement in the material that self-hosting shifts that burden onto your team. There is no documented long-term support branch, no stated compatibility policy between releases, and no migration guidance in the README. If you run the compose install, pin a version and read the release notes before moving, because nothing in the supplied material promises that a workflow built against 0.6.23 survives an upgrade untouched. The same silence applies to the bundled tables database: it is part of the stack, so its data is part of your backup and restore problem.
Where OpenOps is the wrong tool
OpenOps does not produce the underlying cost analysis. It consolidates opportunities from native and third-party FinOps visibility tools, which means you still need one of those tools feeding it. If your problem is that nobody knows where the spend is going, OpenOps does not answer that question on its own. It is also a poor fit if you cannot tolerate an approval step in the loop. The human-in-the-loop controls are presented as a feature, and for de-provisioning production databases they clearly are, but a team that wants unattended remediation of low-risk resources will find the approval machinery in the way. Finally, the no-code editor is a real constraint as well as an accessibility win: the README says you can drop into code when needed, but it does not describe the extension model, the supported languages, or how custom code is packaged and deployed. Confirm that before choosing OpenOps for a workflow whose logic does not fit the pre-built blocks.
How it differs from a general-purpose automation platform
The obvious comparison is a general workflow tool such as n8n or a cloud-native orchestrator, and the difference is not the editor. It is what ships in the box. A general automation platform gives you connectors and a canvas and leaves the FinOps domain to you: the opportunity schema, the approval table, the de-provisioning guardrails, the reports. OpenOps arrives with pre-built FinOps workflows covering cost optimisation, tagging, budgeting, allocation and reporting, plus the table store that holds opportunity state and the analytics layer that renders it. The trade is the usual one. You get domain defaults you can customise, and you inherit a product whose abstractions you did not choose. If your FinOps process is unusual, the pre-built workflows are a starting point rather than a fit, and you are back to building. If it is standard, you skip months of connector and schema work.
Licence, maintenance and what to check first
The README states OpenOps is licensed under the Apache License 2.0 and carries the matching badge. The repository metadata supplied here reports the licence as NOASSERTION, which means GitHub could not map the repository's licence file to a known identifier. Those two facts disagree, and the resolution is to read the LICENSE file in the repository root rather than the badge. Apache 2.0 permits commercial self-hosted use and modification and includes a patent grant, but it also means the project carries no warranty, so support for the free install comes from the Slack community and the documentation portal rather than an SLA. That is the same split the README draws between the managed service and the compose install. If you need someone contractually on the hook for an upgrade that breaks a de-provisioning workflow, the managed tier is the version of OpenOps that comes with that, and the self-hosted path is not.
Editorial conclusion
Adopt OpenOps if you already have cost findings coming out of AWS, Azure or GCP tooling and the missing piece is the execution and approval layer, and if you are willing to run the docker-compose stack yourself. Do not adopt it as a cost visibility tool: it consolidates and acts on opportunities rather than generating the underlying billing analysis. Before committing, check the repository LICENSE file against the Apache 2.0 badge in the README, since the GitHub metadata reports the licence as NOASSERTION, and confirm the release cadence fits your patching window.
Community notes