# Devopness: AI-driven DevOps for AWS, Azure, GCP, DigitalOcean and Hetzner

> Devopness is an open source platform and MCP server that provisions cloud infrastructure from scratch and deploys apps without SSH or the cloud console. This review covers what the repository actually ships, how to install the SDKs, and where the hosted control plane sets the boundary.

**devopness/devopness** — Devopness: AI DevOps on your cloud. Deploy apps, infra and CI/CD. Any cloud and any stack, one MCP. Deterministic API, opinionated and fully configurable. No cloud credentials in AI chats. Free plan.

- Repository: https://github.com/devopness/devopness
- Website: https://www.devopness.com
- Stars: 563 · Forks: 177
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/devopness-devopness

## The problem Devopness targets: provisioning and deploying without SSH

Most self-hosted deploy tools start from an assumption the README states plainly: tools such as Coolify and Dokploy take a server you already provisioned and reach it over SSH. Devopness starts one step earlier. It creates networks, subnets, static IPs and servers inside cloud accounts you control, configures Linux on them, and then deploys applications. The README frames the product as a replacement for a stack of tools that usually sit side by side: Terraform for infrastructure, Ansible for configuration, Jenkins or GitHub Actions for pipelines, and a PaaS such as Vercel or Heroku for the application layer.

The audience is named in the README: developers, team leads, founders and agencies shipping on cloud infrastructure they control. The practical pitch is that routine work (a deploy, a server resize, a migration between clouds) happens from a web app, a mobile client, the API, or natural language in an AI agent, with no SSH session and no cloud console. That matters most for small teams where the same people write the application and operate it, and where nobody wants to keep a browser tab open on the AWS console to check whether a deploy finished.

## How the MCP server and the API fit together

The mechanism the README describes is an MCP server at https://mcp.devopness.com/mcp/, plus a deterministic API behind it. An MCP-compatible client (Cursor, VS Code, Claude Code, Codex CLI, Gemini CLI, Windsurf, Zed, Warp, JetBrains AI and others are listed) connects to that endpoint, and the agent then issues operations such as provisioning servers, deploying apps or migrating between clouds. The README gives one example prompt: "Migrate my app from AWS to Hetzner."

The important design claim is about credentials. The README states that starting the MCP server prompts you to log in with your Devopness account, and that cloud credentials do not sit in the AI chat. That is the difference between handing an agent a cloud access key and handing it a session that the platform mediates. Devopness holds the cloud credential, the agent holds a scoped session, and the API executes the operation.

One MCP endpoint covers every supported cloud rather than a separate integration per provider or per stack. The trade-off is architectural: the intelligence that turns a request into infrastructure changes lives in the hosted service, not in this repository. What you can read here is the client surface (SDKs, UI, docs, examples), not the provisioning engine.

## Installing the Devopness SDKs and running a first API call

The repository is an npm workspace whose workspaces are packages/sdks/* and packages/ui/*, with packageManager set to npm@11.17.0. The two published SDKs are @devopness/sdk-js on npm and devopness on PyPI. Installing the JavaScript SDK is a single npm command.

```bash
npm install @devopness/sdk-js
```

The Python equivalent uses pip, and the PyPI distribution name is devopness.

```bash
pip install devopness
```

Getting a usable credential is a hosted step, not a repository step. The README's quick start says to create an account at app.devopness.com (free, no credit card required) and then follow the Getting Started docs through the sequence organization, project, environment, first deploy. The SDK documentation in the docs directory is where the authentication call and the exact method names would be confirmed; the README itself does not show a code sample for either SDK, so treat the package names above as the verified part and the call signatures as something to read in /docs before you write integration code.

For the MCP path, the README offers one-click install badges for Cursor and VS Code. The configuration those badges encode is an HTTP MCP server named devopness pointing at https://mcp.devopness.com/mcp/.

```json
{
  "mcpServers": {
    "devopness": {
      "type": "http",
      "url": "https://mcp.devopness.com/mcp/"
    }
  }
}
```

After the client connects, the README says you are prompted to log in with your Devopness account. If the login prompt appears, the transport is working; if it does not, the endpoint or the client's MCP support is the first thing to check.

## Where Devopness is the wrong tool

The clearest limitation is the split between this repository and the product. The README describes open source packages and documentation: the JavaScript and Python SDKs, the @devopness/ui-react design system, product docs, and sample applications under examples/applications (Rails, Express, Laravel and more are named). The provisioning and deployment engine is reached through app.devopness.com and mcp.devopness.com. Nothing in the README documents running the control plane yourself, and the README does not document rollback, so anyone whose compliance rules require the orchestrator to run inside their own network should treat this as a hosted service with open source clients, not as a self-hosted platform.

A second limitation is scope. Devopness is opinionated about the path from cloud account to running app. Teams with an established Terraform module library, a GitOps controller, or a platform engineering group that has standardized on Kubernetes manifests are not the target; replacing that machinery with a different abstraction costs more than it saves. The README also lists a large set of tools it replaces, and a replacement claim is not the same as feature parity. If you depend on a specific Jenkins plugin or a Terraform provider that has no equivalent here, that gap is yours to verify before migrating.

The third is release cadence versus product cadence. The recent releases in this repository are all @devopness/ui-react versions (2.205.0, 2.206.0 and 2.206.1, all dated 2026-09-09). A busy design-system release stream tells you the UI packages move; it tells you nothing about how often the hosted platform changes. The last push to the repository was on 2026-09-10, and the repository is not archived.

## Devopness compared with Coolify, Dokploy and Kamal

The README positions Devopness against two groups. The first is self-hosted deploy tools such as Coolify and Dokploy, which it says assume you already provisioned a server and can connect over SSH. The second is stack-specific panels: cPanel, Laravel Forge and Envoyer, Plesk, RunCloud and ServerPanel.app for PHP; FastAPI Cloud and similar for Python; Cloud 66, Hatchbox and Kamal for Ruby, with the README noting Kamal is popular in Rails but works for any stack.

The difference in approach is where the tool starts. Kamal, Coolify and Dokploy begin with a machine that exists and a deploy that ships a container to it; you own provisioning and you own the SSH path. Devopness begins at the cloud API, creates the network and the server, configures Linux, and then deploys. That ordering is why the README can claim no SSH and no cloud console for routine work, and it is also why the platform needs your cloud credentials rather than just a hostname and a key.

Against Terraform plus Ansible, the difference is abstraction level rather than capability. Those tools give you a declarative language and a state file you control; Devopness gives you an opinionated sequence (organization, project, environment, deploy) and an API. If your infrastructure is already expressed as code that auditors read, the second model is a step backwards in transparency even when it is faster to operate.

## Licence, contribution flow and the cost of staying current

The repository is licensed under Apache License 2.0, with a NOTICE file at the top level and a LICENSE file alongside it. For the published packages (@devopness/sdk-js, devopness on PyPI, @devopness/ui-react) that permissive licence is the relevant one when you embed them in your own product. It does not extend to the hosted service, and the README does not describe a self-hosted distribution of the platform, so the licence question and the service question are separate. This is a description of what the repository states, not legal advice; if you plan to redistribute a modified SDK, read LICENSE and NOTICE yourself.

Upgrade cost on the client side is low and visible. Versioned npm and PyPI packages, changesets configuration in the repository root (@changesets/cli and @changesets/changelog-github), and a format:changelogs script that runs vp fmt over packages/*/*/CHANGELOG.md mean release notes are generated rather than hand-written. The ui-react packages published three versions on 2026-09-09 alone (2.205.0, 2.206.0, 2.206.1), which is a signal about how the design system is versioned: pin it if you consume it.

Contributions go through CONTRIBUTING.md, with AGENTS.md called out for people using AI tools and a Code of Conduct. The repository root also carries CLAUDE.md, which suggests AI-assisted contribution is an expected workflow here rather than an afterthought.

## Conclusion

Adopt Devopness if you want cloud provisioning, Linux configuration and deploys driven from one control plane, with an MCP server so an AI agent can act on your behalf without holding cloud credentials. Do not adopt it if you need a fully self-hosted control plane today: this repository publishes SDKs, a React design system, docs and examples, while the provisioning engine runs as a hosted service. Verify first that the SDKs cover the operations you need, that the Apache-2.0 licence on the published packages matches how you intend to redistribute them, and that the MCP login flow satisfies your security review before pointing an agent at production.

## FAQ

### Do I need to install anything to use the Devopness MCP server?

No local install is required for the MCP path. The README provides one-click install badges for Cursor and VS Code that configure an HTTP MCP server named devopness at https://mcp.devopness.com/mcp/, and starting it prompts you to log in with your Devopness account.

### Which clouds and stacks does Devopness support?

The README lists AWS, Azure, GCP, DigitalOcean and Hetzner for provisioning cloud infrastructure in accounts you control, and describes one platform for all stacks rather than a separate panel per stack. Sample applications under examples/applications include Rails, Express and Laravel.

### Is Devopness free to start?

The README states that creating an account at app.devopness.com is free and requires no credit card, and the project description mentions a free plan. The repository does not document pricing tiers beyond that.

### Can I self-host the Devopness platform?

The README does not document a self-hosted control plane. This repository publishes the JavaScript and Python SDKs, the @devopness/ui-react design system, product docs and examples, while provisioning and deploys run through the hosted service at app.devopness.com and mcp.devopness.com.

### Which SDK packages does the Devopness repository publish?

The README lists @devopness/sdk-js on npm and devopness on PyPI, both under packages/sdks, plus @devopness/ui-react under packages/ui/react. The root package.json declares packages/sdks/* and packages/ui/* as npm workspaces.

## Sources

- [devopness/devopness on GitHub](https://github.com/devopness/devopness)
- [License: Apache-2.0](https://github.com/devopness/devopness/blob/main/LICENSE)
- [Project website](https://www.devopness.com)
- [README](https://github.com/devopness/devopness/blob/main/README.md)
- [Releases](https://github.com/devopness/devopness/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/devopness-devopness