Open Vercel's dashboard. Open Heroku's. Open any hosting platform you use. You will find the same things: a list of apps, deployment logs, environment variables, domains, and a settings page. Maybe a CLI. Maybe a decent API.
None of them have an AI assistant that understands your infrastructure.
sh0 does. And it is not a chatbot pasted on top -- it is a first-class feature with its own billing, its own tool execution engine, its own safety model, and its own protocol server. We built the entire stack in 48 hours, across 14 engineering sessions, and it is the second icon in the navigation bar.
Here is why, and how.
The Problem No One Is Solving
Hosting platforms give you powerful tools and then leave you alone with them. When your deployment fails at 2 AM, you:
1. Open the dashboard 2. Navigate to the app 3. Check the deployment logs 4. Read the build output 5. Maybe check the container logs 6. Maybe check resource usage 7. Formulate a theory 8. Try a fix 9. Wait for the rebuild 10. Repeat
Every step requires you to know where to look, what to look for, and how to interpret what you see. This is fine for experienced DevOps engineers. It is terrible for the solo founder deploying their first Node.js app, or the agency managing 40 client sites, or the startup that cannot afford an ops team.
What if step 1 was: "Hey sh0, my app is down -- what happened?"
And step 2 was: sh0 reading the logs, checking resource usage, identifying the error, and either fixing it or telling you exactly what to do?
That is what we built.
What We Actually Built
Layer 1: The AI Chat
The dashboard has a full-featured AI assistant, accessible from the second position in the navigation sidebar. It supports three Claude models (Haiku for speed, Sonnet for balance, Opus for complex problems), streams responses in real time, and persists conversation history.
But a chat interface is just a text box. The real value is what happens behind it.
Layer 2: Tool Calling -- The AI That Can Act
When you ask "What's wrong with my app?", the assistant does not guess. It calls tools:
list_apps-- reads your app inventory with status, stack, and replicasget_app_details-- pulls full configuration, domains, and environmentget_deployment_logs-- fetches recent deployments and build outputget_server_status-- checks CPU, memory, disk, Docker status, and uptimelist_databases-- inventories database instanceslist_backups-- checks backup schedules and recent backup status
These are not hypothetical. Each tool maps to a real sh0 API endpoint. When the AI calls get_deployment_logs, it receives the actual build output from your last deployment. When it calls get_server_status, it reads real CPU and memory metrics from your server.
The AI can also act:
restart_app-- restart a containerdeploy_app-- trigger a new deploymentscale_app-- adjust replica counttrigger_backup-- run a backup nowtrigger_cron_job-- execute a scheduled job
And it can generate files:
generate_config_file-- produce ash0.yaml,docker-compose.yml, orDockerfilebased on your conversation
After every response, it suggests follow-up actions as clickable chips, so you never have to think about what to ask next.
Layer 3: The MCP Server -- For AI Clients Beyond the Dashboard
The dashboard chat is one interface. But what if you want to manage your sh0 server from Claude Desktop? From Cursor? From any MCP-compatible AI client?
sh0-core includes a full MCP (Model Context Protocol) server, implementing the Streamable HTTP transport per the 2025-03-26 specification. It exposes 20 tools -- 12 read-only, 7 write operations, and 1 confirmation meta-tool -- all auto-generated from the same OpenAPI spec that powers the REST API.
This means:
- Open Claude Desktop, point it at
https://your-server.com/api/v1/mcp - Claude discovers all available tools automatically
- You can manage your infrastructure from any MCP client, not just the sh0 dashboard
No other hosting platform has this. Not Vercel. Not Railway. Not Render. Not Fly.io. Nobody.
Layer 4: The Safety Model -- Because AI + Production = Danger
Giving an AI the ability to restart apps and delete databases is powerful. It is also terrifying. Our safety model has three layers:
Scoped API Keys. Every MCP connection authenticates with a key that carries a scope: read, standard, or admin. Read keys can only call read tools. Standard keys can read and write. Admin keys can do everything -- but destructive operations require an additional step.
Risk Classification. Every tool is classified as read, write, or destructive. The risk level is enforced at execution time. A standard-scope key calling delete_app gets a 403 immediately, before any code runs.
Confirmation Tokens. Destructive operations (delete app, delete database) never execute directly. Instead, they return a confirmation token -- a single-use, user-bound, 5-minute-TTL token that the client must explicitly submit via confirm_action. This prevents an AI from accidentally cascading destructive operations. Even with an admin key, you cannot delete anything without a deliberate confirmation step.
Every write operation is audit-logged with an mcp:* action prefix, so you can trace exactly what the AI did and when.
The Architecture: Dual Execution
The most interesting architectural decision is the dual execution model:
Path A: Client-side execution (Dashboard). When you use the chat in the dashboard, tool calls are executed in your browser. The AI gateway defines the tools, Claude decides which to call, but the actual API requests go from your browser to your sh0 server. The gateway never sees your server data -- it only sees the tool names and results that get sent back to Claude.
Path B: Server-side execution (MCP). When you use Claude Desktop or another MCP client, tool calls execute on your sh0 server directly. Claude connects to the MCP endpoint, discovers tools, and calls them server-side. No browser involved.
Path C: Hybrid (Gateway MCP Connector). When the AI gateway detects that your sh0 instance has MCP enabled, it uses Anthropic's MCP Connector to let Claude call your server's tools directly -- but still handles gateway-only tools (like suggest_actions and generate_config_file) locally. If MCP fails (network issue, instance down), it falls back to the dashboard path transparently.
This architecture means the AI features work in three contexts: 1. In the dashboard (browser) 2. In any MCP client (Claude Desktop, Cursor, etc.) 3. Via the API (programmatic access)
All three use the same tools, the same safety model, and the same audit logging.
The Billing Model: Prepaid Wallet
AI features cost money to run. We chose a prepaid wallet model:
- Buy credit packs ($5, $20, $50, $100) with volume bonuses
- 20% margin over Anthropic's list prices
- Three models with different price points (Haiku: fast and cheap, Sonnet: balanced, Opus: powerful)
- Token-level accounting -- you see exactly what each conversation costs
- Business plan users can bring their own Anthropic or OpenRouter key (BYOK), encrypted at rest with AES-256-GCM
The wallet balance is visible in the top header on every page, with a direct link to buy more credits. We want AI usage to feel natural, not rationed.
Why Now, Why Us
Three reasons we could build this and the established platforms have not:
1. Architecture advantage. sh0 is a single Rust binary with an embedded Svelte dashboard. Adding an MCP server is adding a route handler to an Axum application -- not coordinating across 15 microservices, 3 teams, and a 6-month roadmap. We went from "let's add AI" to "20 tools in production" in 48 hours.
2. We eat our own cooking. sh0 is deployed on sh0. When we add AI features, we immediately use them to manage our own infrastructure. The tool definitions are not hypothetical -- they map to real operations we perform daily. "Restart the app" is not a demo feature. It is how we recover from a failed deployment.
3. AI is not an add-on for us. It is a differentiator. The established platforms are optimizing for enterprise sales, Kubernetes compatibility, and edge computing. We are optimizing for the solo founder, the small team, the African startup that cannot afford a DevOps hire. For these users, an AI that can diagnose and fix deployment issues is not a nice-to-have -- it is the difference between shipping and giving up.
What This Means for Users
If you deploy on sh0, you get:
- Natural language infrastructure management. Ask questions, get answers with real data.
- Proactive diagnostics. The AI reads your logs, not just your description of the problem.
- Safe automation. Restart apps, trigger backups, scale services -- with confirmation gates on anything destructive.
- Multi-client access. Use the dashboard, Claude Desktop, Cursor, or any MCP client.
- Transparent pricing. See your costs per conversation, per model, per token.
And because the AI features are second in the navigation -- not buried in a settings page or hidden behind a feature flag -- they are part of the daily workflow, not an afterthought.
The 48-Hour Timeline
For those who care about the engineering:
| Session | What was built |
|---|---|
| 1 | AI gateway backend: chat endpoint, API keys, wallet, usage tracking |
| 2 | Dashboard chat UI: streaming, conversation history, model selector |
| 3 | Tool calling: 9 tools, agentic loop, processing steps UI |
| 4-5 | MCP Phase 1: 12 read-only tools, Streamable HTTP, 2 audit rounds |
| 6 | MCP Phase 2: OpenAPI-driven tool generation, LazyLock caching |
| 7-8 | MCP Phase 3: write tools, scoped keys, confirmation tokens, 2 audit rounds |
| 9 | MCP Phase 4: gateway MCP Connector, dual execution, fallback |
| 10-14 | Audits: 6 rounds total, 7 issues found and fixed, 0 regressions |
14 sessions. ~50 new files. ~10,000 lines of code. 20 MCP tools. 488+ tests passing. Production-ready.
What's Coming Next
What we shipped in 48 hours is the foundation. The next sessions will push the AI assistant far beyond what any hosting platform -- or even most standalone AI products -- can do. Here is the roadmap:
File Generation
The AI will generate real files, not just text. Ask it to create a docker-compose.yml, a Nginx config, an SSL certificate request, a migration script -- and it will produce a downloadable file with live preview, syntax highlighting, and an inline editor. We are porting a proven file generation engine that supports XLSX, PDF, PPTX, DOCX, HTML, and Markdown, all generated server-side from structured LLM output.
The file canvas will let you edit generated files in a split-panel view: chat on the left, rich editor on the right. Edit a generated Dockerfile, save it, and deploy it -- without leaving the conversation.
Web Search and URL Browsing
The assistant will be able to search the internet and read URLs. When you ask "How do I configure Redis for my Next.js app?", it will search for the latest documentation, read the relevant pages, and give you an answer grounded in real, current sources -- with citations.
This turns the sh0 assistant from a knowledge-limited chatbot into a research-capable agent that can pull in any information it needs to help you.
Code Execution Sandbox
A sandboxed bash environment where the AI can run commands in isolation. Need to test a build script? Debug a dependency issue? Validate a configuration? The AI will execute commands in a Docker-based sandbox, show you stdout/stderr, and iterate on the solution.
This is not hypothetical. We have a working implementation from another ZeroSuite product (Deblo Pro) that runs 30-second-capped commands with full output capture. Porting it to sh0's Rust backend means each execution runs in an isolated container via the Docker API -- the same API sh0 already uses for deployments.
RAG Pipeline -- Your Docs, Your Context
Users will be able to upload documentation, configuration files, runbooks, and architecture diagrams. The AI will index them using semantic chunking, BGE-M3 embeddings, and pgvector -- then retrieve relevant context when answering questions.
Ask "What's our deployment process?" and the AI will pull from your uploaded runbook. Ask "Why did we choose Postgres over MySQL?" and it will find the architecture decision record you uploaded last month. Your infrastructure knowledge, always available, always searchable.
Background Generation
Long-running AI tasks (complex file generation, multi-tool research, large document analysis) will run as background jobs. If your browser disconnects, the job keeps running. When you come back, the results are waiting. This uses a queue-bridged architecture with tokio tasks and mpsc channels -- production-grade async that never loses work.
Specialist Agents
Instead of one generic assistant, you will be able to switch between specialist personas: a DevOps expert, a security auditor, a database administrator, a Dockerfile specialist, a CI/CD consultant. Each agent has a tailored system prompt that focuses its knowledge and behavior on its domain.
Need a security review? Switch to the security auditor agent. Need help optimizing your PostgreSQL queries? Switch to the database agent. Each agent knows what it knows and stays in its lane.
Email and Notification Tools
The AI will be able to send emails and notifications on your behalf: deployment reports, incident summaries, status updates. It will draft the email in an interactive card, let you edit it, and send it when you approve. Rate-limited, audit-logged, and always under your control.
Interactive Diagnostics
Quizzes and assessments that help you understand your infrastructure. The AI will test your knowledge of your own setup: "Do you know what port your app is running on? What happens if your database runs out of disk? When was your last backup?" Not for gatekeeping -- for education. A hosting platform that makes you better at operations.
The Vision: AI-Native Infrastructure
These features are not random additions. They form a coherent vision: an AI-native hosting platform.
Every feature follows the same pattern: the AI reads your infrastructure state, reasons about it, acts on it (with safety gates), and communicates the results. The tools are the same whether you use the dashboard chat, Claude Desktop, or the API. The safety model is the same. The billing is the same.
When all of these ship, sh0 will not just be a hosting platform with AI bolted on. It will be an AI platform that happens to host your apps. The hosting is the substrate. The intelligence is the product.
No other platform is building this. Not because they cannot -- but because they are optimizing for enterprise procurement cycles, not for the solo founder who needs an ops team at 2 AM.
We are building that ops team.
The Line in the Sand
Every hosting platform will eventually add AI features. They will announce it at a conference, ship a beta 6 months later, and GA it a year after that.
We shipped the foundation in 48 hours. The features listed above will ship in the next 2-3 weeks. By the time the established platforms hold their keynotes, sh0 will have a 6-month head start and a feature set they will spend a year catching up to.
The AI assistant is not a checkbox on a feature matrix. It is the answer to a question every solo developer has asked at 2 AM: "Why is my app down, and how do I fix it?"
sh0 answers that question. Nobody else does. Yet.
---
This post documents the AI feature set built for sh0.dev between March 23-25, 2026, across 14 engineering sessions, with a roadmap for the next phase. All code is in production in the zerosuite-inc/sh0-core and zerosuite-inc/sh0-website repositories.