Devopness: what the open repository actually ships, and what stays closed

The problem it targets: provisioning in your cloud, not on a rented box

Most self-hosted deploy tools start from an assumption the README states outright: that you already provisioned a server and can reach it over SSH. Devopness takes the opposite starting point. It provisions networks, subnets, static IPs and servers inside cloud accounts you control, on AWS, Azure, GCP, DigitalOcean and Hetzner, then configures Linux and deploys the application on top. The claimed audience is developers, team leads, founders and agencies shipping on infrastructure they own rather than on a platform that owns it for them. The distinction matters at the boundary of responsibility. With a platform-as-a-service, the provider holds the account and you hold a dashboard login. Here the servers live in your cloud billing relationship, and Devopness is the layer that creates and configures them. The README positions this against a stack of separate tools: Terraform plus Ansible plus Jenkins plus a PaaS plus stack-specific server panels. Whether one tool should absorb all five is a judgement call, and the repository alone does not settle it.

What is inside the repository, and what is not

This is the part worth reading before anything else. The repository table lists four paths: docs, packages/sdks/javascript for the @devopness/sdk-js package, packages/sdks/python for the devopness package, packages/ui/react for the @devopness/ui-react design system, and examples/applications with sample integrations for Rails, Express, Laravel and others. The control plane that provisions cloud resources is not among them. The repository is Apache-2.0, the default branch is main, and the most recent published releases are @devopness/ui-react versions from September 2026, which tells you the release cadence visible here is dominated by the UI package rather than the platform. If you arrived expecting to self-host the whole product, the repository layout says otherwise. What you can read, audit and reuse is the client surface and the documentation. What you cannot inspect from here is the engine that talks to AWS, Azure, GCP, DigitalOcean and Hetzner on your behalf. That asymmetry should shape how much weight you put on the open source label when evaluating the product.

How the MCP server connects an agent to your infrastructure

The mechanism is a remote MCP endpoint at https://mcp.devopness.com/mcp/. The README gives one-click install links for Cursor and VS Code that write that URL into the client configuration, and states that starting the MCP server prompts you to log in with your Devopness account. So the data flow runs from your AI client, over MCP, to a hosted Devopness service, which then acts on your cloud accounts. The README's framing is that this is one MCP server rather than a separate integration per cloud or stack, and it gives a single example prompt: migrate my app from AWS to Hetzner. The security claim attached to this design is that no cloud credentials go into AI chats. That is a plausible consequence of the architecture, since the agent authenticates to Devopness and Devopness holds the cloud relationship, but the README does not spell out the token model, scopes or session lifetime. The README also lists MCP-compatible clients including Cursor, VS Code, Claude Code, Codex CLI, Gemini CLI, Windsurf, Zed, Warp and JetBrains AI, with step-by-step guides pointed to in the MCP docs rather than reproduced in the repository.

Getting from an account to a first deploy

The Quick start is three steps and is deliberately thin. First, create an account at app.devopness.com, which the README says is free and requires no credit card. Second, follow the Getting Started documentation, which walks the hierarchy organization, then project, then environment, then first deploy. Third, optionally connect MCP through the one-click links or the MCP docs. There is no install command in the README, no CLI invocation, and no configuration file to copy. That is consistent with a hosted product: the entry point is a signup, not a package install. The SDKs exist for programmatic access if you want it. The npm package is @devopness/sdk-js and the PyPI package is devopness, both listed in the repository table, and both are the kind of thing you would install if you were scripting against the API rather than clicking through the web app. What the README does not provide is a worked example of authenticating an SDK client, so plan on reading the docs directory for that.

The self-hosting question the repository does not answer

This is the limitation to weigh hardest. The README states that Devopness provisions infrastructure from scratch and replaces a list of tools, and the topics include self-hosting. But the repository contents are SDKs, a design system, docs and examples. Nothing in the supplied material describes a self-hosted deployment path for the platform itself: no Docker Compose file, no Helm chart, no server binary, no installation guide. The practical reading is that self-hosting, as the term appears here, means bringing your own cloud servers for Devopness to manage, not running Devopness on your own hardware. Those are different things and the README does not separate them clearly. If your constraint is data residency, an air-gapped network, or a policy that forbids a third party holding API credentials to your cloud accounts, the repository as described does not give you a route around that. You would be evaluating a hosted service, and the Apache-2.0 licence on the client packages does not change where the provisioning logic runs.

How it differs from Coolify and Dokploy

The README names these two directly and the contrast is specific rather than marketing. Coolify and Dokploy, as described here, assume you already provisioned a server and can connect over SSH. They are deploy targets: you bring the machine, they run the pipeline and the runtime on it. Devopness starts one layer earlier, creating the network, subnet, static IP and server in your cloud account before anything is deployed. That is the real difference in approach, and it decides which tool fits. If you already have servers and want a control panel for them, the SSH-based model is simpler and keeps everything on hardware you can touch. If the tedious part for you is the provisioning step itself, the cloud console work and the Linux configuration that follows it, then a tool that begins at the cloud API is addressing your actual bottleneck. The README also lists the panels Devopness intends to replace by stack, including cPanel, Laravel Forge, Plesk and RunCloud for PHP, Cloud 66, Hatchbox and Kamal for Ruby, and FastAPI Cloud for Python, which is a broad claim across very different runtimes.

Licence, maintenance and upgrade cost

The repository is Apache-2.0, which permits commercial use, modification and redistribution of the code that is actually present, subject to the licence terms. That covers the SDKs, the React design system, the docs and the examples. It does not grant you the hosted service, and nothing in the supplied material describes a support contract, an SLA, or what happens to your infrastructure if you stop paying. On maintenance, the visible release cadence in the supplied data is the @devopness/ui-react package, with three versions published across two days in September 2026. That is a UI component library moving quickly. It tells you nothing about how often the provisioning engine changes, because that code is not here. If you depend on @devopness/sdk-js or the Python devopness package, the upgrade cost is the usual one for a generated API client: version bumps when endpoints change, and a changelog you should read before pinning. I cannot tell you from this material how the SDK versions track the API, and that is worth confirming in the docs before you build on either package.

Editorial conclusion

Devopness fits teams that want cloud infrastructure provisioned in accounts they already own, driven from a web app or an AI agent, without building the Terraform and Ansible layer themselves. It does not fit anyone who needs to run the whole platform on their own hardware, because the repository holds SDKs, a React design system, docs and examples rather than the provisioning engine. Before committing, read the docs directory for the permission model and the API reference, and confirm what the free plan includes, since the README states only that a free plan exists.

Official sources

1. devopness/devopness on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases