OpenBerth

AI-assistant native self-hosted deployment platform

73 followers

AI-assistant native self-hosted deployment platform

73 followers

OpenBerth is a self-hosted deployment platform that AI assistants can use natively. Tell Claude, your agent, or any AI tools you use on your phone or desktop to deploy an app, it does. Store and use secrets securely, AI references them by name without seeing values. Works from CLI, AI chat, or a single file drop. Your server, your rules. Connect any AI tools to MCP server and start building.

Free

Launch tags:Open Source•Developer Tools•Artificial Intelligence

Launch Team

ClarifyThe autonomous CRM that helps you sell more

Promoted

Maker

📌

I deployed an app from my phone last week, not by SSHing anywhere, but by telling Claude "build me a feedback form and deploy it with my database credentials." 30 seconds later I had a live HTTPS URL. That moment made me realize this thing is ready to share. **The backstory:** I got tired of paying platform taxes on side projects and internal tools. Vercel and Railway are great but I have servers sitting there. I just wanted: code in → URL out. No YAML, no Docker Compose, no 47-step CI pipeline, and even my non-technical friend be able to quickly use it instead of sharing localhost:3000 ;) So I built OpenBerth. One binary on any Linux server. That's the whole setup. **What surprised me** was how much better it got once I connected it to AI. Claude (on my phone, desktop, or Cursor) can: → Write code and deploy it in the same conversation → Look up my encrypted secrets by description ("Stripe key", "production database") and use them without ever seeing the values → Push live updates with hot reload — no rebuild wait → Pull logs and debug issues right in the chat I basically have a DevOps engineer in my pocket now. **It's not AI-only though.** `berth deploy` from your terminal works exactly how you'd expect. Drop a React component, a Python app, a Go service, even a Jupyter notebook — auto-detected, sandboxed, HTTPS, done. Every deployment shows up in a **built-in app gallery** — a dashboard of everything you and your team/friends/family have deployed, all in one place. Click through to any app, check its status, or share it. It's like your own private app store. Each app also gets **persistent storage** out of the box — a built-in key-value data API that survives redeploys. Your app can store and retrieve data without setting up a separate database. Great for prototypes, internal tools, or anything that needs to remember state. Fully open source, self-hosted, no usage limits, no surprise bills. **One more thing** that I think matters: OpenBerth doesn't lock you into any specific AI tool. Today I use Claude and Cursor. Tomorrow a better model comes out? Just point it at my server. My infrastructure, my secrets, my deployments — they all stay. The AI is interchangeable, the platform is yours. I think this is where things are heading. AI coding tools will keep getting better and cheaper. The last thing you want is your production apps trapped inside a platform that picked one model for you. Own your deployment layer, swap the brains whenever you want. I've been using this daily for months and I'm genuinely curious — if you had an AI that could deploy to YOUR server, what's the first thing you'd build?

Report

5mo ago

The secrets-by-name-without-seeing-values architecture is the most interesting part here. How does that work exactly when Claude is orchestrating a deployment — does the MCP server do a local substitution at runtime, or are the values never in the process environment that the LLM context can reach? The threat model matters a lot depending on the answer.

Report

5mo ago

Maker

@sounak_bhattacharya Secrets are stored encrypted at rest on the server. When Claude (or any AI client) calls berth_secret_list/get, the MCP response only includes names (for referring) and descriptions (for knowing the purpose so LLM can understand when to pick that up), values never enter the LLM context.

At deployment time, the server decrypts and injects secrets as environment variables into the container (Isolated using gVisor so no access outside the running instance). This happens entirely server-side; the MCP protocol never transmits secret values.

So the boundary is: the AI agent knows which secrets exist and can reference them by name in deployment configs (or being asked by the user to use what, for instance, use my stored stripe key when integrating with Stripe), but the actual values only live on the server and inside the running container and outsiders are allowed to refer to secrets not having knowledge on the value.

Report

5mo ago

How does this compares to tools kike dokku?

Report

5mo ago

Maker

@nayan_surya98 Great question! Your AI tools can be deployed directly via MCP, no CLI or git push required. OpenBerth also provides a development sandbox with hot reloading, allowing you to iterate on live code before promoting it to production.

While other platforms excel in their own areas, they weren’t specifically designed for AI-assisted workflows. OpenBerth, on the other hand, is built with this focus in mind.

Additionally, OpenBerth includes built-in secret management, enabling your AI tools to securely reference and use secrets within a project, without exposing API keys.

You can explore a full comparison in the documentation: https://openberth.io/docs/compare

Report

5mo ago

Reviews