mcpbeat Sign in

run.zero MCP Server

answering

run.zero is answering right now. Last checked 8 min ago. It exposes 50 tools. Last commit 4 Nov 2026.

Deploy apps, APIs and Postgres from your AI agent. EU PaaS hosted in Germany, OAuth sign-in.

Uptime history 71 hours of history
71 hours agonow
100.0%
Uptime 24h
91 of 91 checks
50
Tools
read from the server
130 ms
Response time
average over 24h
0
Stars
last commit 4 Nov 2026

What changed 2

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 5 November 2026. No other catalogue keeps this.

6 Nov a tool changed the parameters it asks for runzero_create_user
5 Nov a tool description was rewritten runzero_deploy

Nothing serious here today

Today is the operative word: we check run.zero every 15 minutes and re-read its code on every release. Watch it and you find out the day that stops being true.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 8 min ago.

run in your terminal
claude mcp add mcp --transport http https://api.run-zero.de/mcp
Settings → Connectors → Add custom connector, then paste this address
https://api.run-zero.de/mcp
~/.codex/config.toml
[mcp_servers.mcp]
url = "https://api.run-zero.de/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "mcp": {
      "url": "https://api.run-zero.de/mcp"
    }
  }
}
.vscode/mcp.json
{
  "servers": {
    "mcp": {
      "type": "http",
      "url": "https://api.run-zero.de/mcp"
    }
  }
}

Available tools 50

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

runzero
runzero_activate_version
Put an earlier version back online — this CHANGES what visitors see. Only do this when the user explicitly asks to go back; never on your own initiative after a failed build (fix the code instead). While an older version is active, new builds are built but NOT published, until you call this again with image "latest". If the service has a database, the container goes back but the data does not — say so and pass acknowledge_data only after the user confirms.
runzero_add_service
Add a new service to an app. Clones the repo, builds with buildpacks, and deploys. The web process must listen on $PORT.
runzero_adopt_template
Create a NEW app as a full copy of a template from runzero_list_templates: app + repo + running instance, owned by the caller. Use this INSTEAD of runzero_create_app when a template matches the request, then adapt the copy (texts, colors, images — placeholder assets keep their paths and get overwritten). The copy provisions asynchronously; follow with runzero_wait_for_build as usual.
runzero_backup_volume
Start a backup of the persistent volume now, on top of the automatic daily one. The service keeps running. It runs in the background; runzero_volume_status lists it once it is finished.
runzero_create_app
Create a new app. Optionally links to a Git repository — if no repo is given, you can attach one later.
runzero_create_identity_provider
Add an external login provider (Google, GitHub, Microsoft, generic OIDC/SAML) to the app's login realm, so end-users can sign in with it. You need an OAuth client id/secret from the provider first. IMPORTANT: the response contains a redirect URI that the user must register in the provider's OAuth app — surface it to them. For generic 'oidc' also pass authorization_url and token_url.
runzero_create_user
Create an end-user in the app's login realm. Returns the generated password ONCE if none is given — relay it to the user, it cannot be retrieved later.
runzero_db_query
Run one SQL statement against an app's PostgreSQL addon (owner/admin only). Read-only by default: the statement runs in a READ ONLY transaction that is rolled back. With allow_write=true it CAN WRITE: INSERT/UPDATE/DELETE and DDL (DROP, ALTER, TRUNCATE) are committed immediately and cannot be undone. Before setting allow_write, show the user the exact SQL and get their explicit confirmation. Results are capped at 1000 rows; statements time out after 15s.
runzero_delete_app
Permanently delete an app with all its services, addons (including database data), secrets and domains. Irreversible: only on an explicit request, and name the app back to the user before calling.
runzero_delete_secret
Delete a single secret from an app or a service. Affected services are redeployed automatically.
runzero_delete_service
Permanently delete one service of an app: its running containers, its public URL and its configuration. Irreversible, and it also deletes the persistent volume of the service with all its backups; to only stop it, scale it to 0 with runzero_scale_service.
runzero_delete_user
Permanently delete an end-user (account, sessions, login data) from the app's login realm. Irreversible; to only block the login use runzero_set_user_enabled.
runzero_deploy
Deploy an app. Fetches the repo and checks for run-zero.yaml (or the older itdone.yaml). If found, syncs all services + addons + domains from config. If not, deploys the repo as a single service. Services missing from the config are scaled to 0; with prune=true they are DELETED. Run runzero_deploy_preview first to see the diff. Read `warnings` in the result: it reports data that will not survive a restart (a known image without room for its automatic volume, SQLite in the code without `volumes:`) and gives the exact fix. Apply it before you call the app done.
runzero_deploy_preview
Preview what a deploy would change without making any changes. Use this before runzero_deploy to verify the diff.
runzero_describe_addon
Show exactly which environment variables an addon injects into an attached service, straight from the platform (the source of truth — use this instead of guessing env var names). Call it BEFORE writing code that reads addon credentials.
runzero_generate_image
Generate an image with AI (FLUX) and commit it into the app's repo. Costs credits. Use for hero images, backgrounds, illustrations. The file is committed at the given path (e.g. assets/hero.jpg), replacing a file already there, and a rebuild is triggered; reference it in the code afterwards. The prompt is sent to Black Forest Labs (EU endpoint).
runzero_get_app
Get one app: slug, status, publish mode, services (URL, replicas, health, env var NAMES), addons, domains. Secret values are never returned.
runzero_get_build_logs
Get the full log stream for a specific build (all kpack steps concatenated). Use runzero_list_builds first to find the build id.
runzero_get_help
Look up structured guidance on platform concepts and conventions. Topics: workflow, files, addons, procfile, domains. Call this whenever you need to understand addons, the Procfile/PORT convention, or the typical workflow for a new app. Returns markdown.
runzero_get_legal_profile
Get the user's saved legal profile (their Impressum details: name/company, address, contact, and for a company the representative, register and VAT id). Read this BEFORE asking the user for Impressum data, so you reuse what they already gave and only ask for what is missing. Returns the profile (or null) and imprintReady = whether it has the §5 DDG minimum.
runzero_get_logs
Get the runtime log output of one service (stdout/stderr of its running containers), last N lines.
runzero_get_metrics
CPU and memory usage of a service over a time window (default last hour). Returns per-pod current/min/max/avg — CPU in millicores, memory in MiB — not raw time series, to stay compact.
runzero_list_apps
List the apps the authenticated user has access to (own + collaborated), newest first — one compact row each (name, slug, url, kind, status, flags). Details of one app: runzero_get_app.
runzero_list_builds
List recent build records for an app. Returns kpack Build status (success/failed/running) per service. To WAIT for a build to finish, use runzero_wait_for_build instead of calling this in a loop.
runzero_list_files
List all files in the app's Git repository (platform-managed repos only). Optionally filter by path prefix.
runzero_list_identity_providers
List external login providers (Google, GitHub, …) configured on the app's login realm. Secrets are never returned.
runzero_list_releases
What the user has PUBLISHED, newest first, with the sentence they described each change with, and which one visitors see right now. This is the list to use when someone says "wie letzte Woche" or "vor der Umgestaltung" — not runzero_list_versions, which lists every build including the platform's own bookkeeping commits and is unreadable for a person. Also reports whether something is built and waiting.
runzero_list_secrets
List the secret keys for an app (values are never returned). Includes both app-wide and per-service secrets.
runzero_list_services
List the services (runtime processes) of an app with their build source, port, replicas and status.
runzero_list_templates
List the curated template library: finished, deployed page designs (landing pages, shops, portfolios …) that can be adopted as the starting point of a NEW app instead of building from scratch. Each entry has a live URL and a screenshot URL plus kind/industries/tags for matching. Adopting a matching template is far cheaper and better-looking than writing a page from zero — check here FIRST on any first build.
runzero_list_users
List the end-users of an app's login realm (requires the app's keycloak addon). Returns id, username, email and enabled state.
runzero_list_versions
Earlier versions of a service that can be put back online, newest first. Each entry has an `image` (pass it to runzero_activate_version or runzero_preview_version), when it was built, and `summary` — the commit message, i.e. what changed. `active: true` marks what is online now. Use this when the user refers to an earlier state ("wie gestern", "vor der Umgestaltung"). Omit `service` when the app has only one.
runzero_preview_version
Show an earlier version under a SECOND address without touching the live site — use this whenever the user wants to look before deciding. Returns a url; the pod needs a few seconds, so a first request may fail — retry once. Pass `stop: true` (without `image`) to tear the preview down again; it costs nothing once stopped.
runzero_publish
Put the waiting changes on the real site — this is what VISITORS see, so only ever on an explicit request ("mach das live", "veröffentliche das"), never on your own initiative after finishing a change. Write `description` in the user's own words and in their language ("Tag der offenen Tür angekündigt"), because that sentence is what they will read next month when they want to go back. Only for apps that publish on request; an app that publishes automatically has nothing to publish.
runzero_push_files
Push changes into the app's Git repository as ONE atomic commit (create, patch, and delete in a single push). CHANGING an existing file? Use `edits` — an exact-snippet replacement, like your editor's edit tool. Use `files` only to create a NEW file or to genuinely rewrite one end to end: it resends the whole document, so a twelve-line change costs you the entire file. Both may appear in the same push (different paths). If the app has no repository yet, a platform-managed repo is created automatically on the first push. Text files only (UTF-8) — for binary assets (icons, images, fonts) NEVER attempt to inline the bytes; models cannot generate valid binary data. Instead use runzero_upload_assets (the user uploads via the dashboard) or set sourceUrl on a file entry (the server downloads it from the web). IMPORTANT: after the FIRST push on a fresh app, run runzero_deploy once — it creates the service(s) from the repo (single service from the root, or several from a run-zero.yaml). Later pushes rebuild existing services automatically. See runzero_get_help topic 'files' for the full flow, code layout rules and the run-zero.yaml format. Only works with platform-managed repositories, not external repos. `deletions` and `files` overwrite or remove files in the repo; earlier content stays in the Git history.
runzero_read_file
Read a file from the app's Git repository (platform-managed repos only), UTF-8. Returns at most 250 lines per call (a note at the end says how to continue) — read the part you need with startLine/endLine instead of the whole file; every returned line is paid for on every later step.
runzero_rebuild_service
Rebuild a service from the latest commit of its repo branch; on success the new version rolls out to the live URL. Use after an external repo changed; pushes via runzero_push_files rebuild on their own.
runzero_reset_user_password
Replace an end-user's password in the app's login realm; the old one stops working at once. Returns the new password ONCE (generated if none given).
runzero_restore_release
Put an earlier published state back on the real site. Use the id from runzero_list_releases. This CHANGES what visitors see. It does not touch the code: anything changed since is still there and still waiting, so this undoes what is published, not the work. If the user wants an announcement removed rather than the whole site rolled back, edit the page instead — going back also removes every other change made since.
runzero_restore_volume
Replace the data on the persistent volume with a backup. The service stops, the current data is backed up first, the backup is unpacked, and the service starts again. Takes minutes; follow it with runzero_volume_status (`restore.phase` ends at `done`, with `error` if it failed and the data stayed unchanged).
runzero_scale_service
Set the replica count of a service (0-10). Scaling to 0 takes the service offline (its URL stops answering) without deleting it; scale up again to bring it back. A service with a persistent volume runs 0 or 1 replicas and keeps its data at 0.
runzero_screenshot
SEE the deployed page with your own eyes: renders the live URL in a real browser and returns fresh screenshots as images — desktop (1280×800) and/or mobile (390×844). Use it after runzero_wait_for_build to review the visual result like a designer would (spacing, contrast, overlaps, broken mobile layout) and fix what you SEE, not what you assume. Never cached; but the rollout of a fresh build lands ~30-90s after build success, so a screenshot taken too early shows the previous version — if it looks unchanged, wait briefly and call again.
runzero_set_legal_profile
Save or update the user's legal profile so it is reused across their apps and the legal pages can be regenerated. Send only what the user actually provided; omitted fields are cleared. NEVER invent legal data.
runzero_set_publish_mode
Switch between publishing every change immediately (auto) and collecting changes on a preview until the user releases them (manual). Explain the consequence before switching to manual: from then on nothing reaches their visitors until they say so, which is the point but also a way to wonder for days why a change never appeared. Switching back to auto publishes whatever was waiting, immediately.
runzero_set_secrets
Set one or more environment variables for an app or a specific service. Existing keys are overwritten; other keys are preserved. Affected services are redeployed automatically.
runzero_set_user_enabled
Enable or disable (block) an end-user in the app's login realm. A disabled user cannot log in but is not deleted.
runzero_upload_assets
Get the dashboard upload link for an app so the USER can upload binary assets (icons, images, fonts) via drag & drop — real bytes, nothing travels through the model. Give the returned URL to the user, wait until they confirm the upload, then call runzero_list_files with path 'assets/' and reference the files in the code.
runzero_volume_status
Show the persistent volume of a service: mount path, size, last backup, the backups that can be restored, and the state of a running or last restore. Volumes are declared under `volumes:` in run-zero.yaml (runzero_get_help topic files).
runzero_wait_for_build
Wait server-side until the newest build of an app is finished AND the new version is serving traffic — use this INSTEAD of polling runzero_list_builds, sleeping, or re-checking the site in a loop. Blocks up to 45 seconds per call and returns {status: "success" | "failed" | "running", phase, rollout, builds}. "running" with phase "building" or "rolling-out" means: call it again. A rollout follows every successful build by 30-90 s, and until it lands the live URL, curl and screenshots still show the OLD version — do not push a fix for what you see in that window. "success" with phase "live" means every pod serves the new build; phase "done" means built but not live for a reason named in `hint` (the app publishes on request, an older version is pinned, not deployed yet). On "failed", read runzero_get_build_logs with the failed build id.
runzero_work_url
The URL where this app's UNPUBLISHED changes can be looked at, and a link that opens it (the plain hostname refuses without one). Call this after EVERY change to an app that publishes on request, and give the user the link with a plain sentence: their change is on the preview, their real site is untouched, and it goes live when they say so. Without that sentence they look at their own website, see nothing, and conclude the change was lost.

Endpoints

URLTransportStateLatencyChecked
https://api.run-zero.de/mcp streamable-http answering 109 ms 8 min ago

Alternatives to run.zero

same job, measured the same way
Resilis
by resilis

Deploy local apps, add managed Postgres, and inspect logs from your AI coding agent.

answering
Light Cloud
by light-cloud

Deploy and run web apps, APIs and databases on Light Cloud from your AI agent.

259 installs/wk local only
Ownkube
by ownkube

Deploy and run apps, workers, jobs, Postgres, and Valkey on Ownkube from your coding agent.

answering
kad.dev
by kad

Deploy and run web apps from your agent: live URL, Postgres, S3 storage, a version per commit.

answering
ohmyho.st
by amerged-org

Operate ohmyho.st hosting from your coding agent: deploy GitHub apps, Postgres, mail, domains.

2 191 installs/wk local only
Sota
by sota

EU-native PaaS for AI agents — deploy web apps with one sentence, managed Postgres, GDPR by default.

92 installs/wk 14 tools answering
Ployz
by ployz

Deploy apps, databases and previews to your own servers. Run Ployz Cloud from your agent.

answering
Zektor
by m-akcan

Managed Postgres and Valkey hosted in Germany. Agents can create a trial database with no signup.

67 installs/wk local only

run.zero — questions

Answers built from our own checks of this server.

What can run.zero do?
It exposes 50 tools, read directly from the server on our last check. Among them: runzero_activate_version, runzero_add_service, runzero_adopt_template, runzero_backup_volume, runzero_create_app, runzero_create_identity_provider and 44 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is run.zero working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 91 of 91 checks got a reply (100.0%), average response time 130 ms. The bar chart above shows every period we have measured.
How do I connect run.zero?
Copy the ready config from this page. We generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each in the form that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does run.zero need an API key?
No. run.zero completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 50 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is run.zero?
It answers our handshake in 130 ms on average, which is faster than 89% of all working MCP servers we measure. That puts it in the quick quarter of the ecosystem. The comparison comes from our own checks across the whole registry, every 15 minutes.
Is run.zero open source?
We cannot say either way: 0 stars on GitHub, but we could not determine the licence, and without one the code is not open source by default.