run.zero

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.

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.

Takes no parameters.

Get one app: slug, status, publish mode, services (URL, replicas, health, env var NAMES), addons, domains. Secret values are never returned.

Create a new app. Optionally links to a Git repository — if no repo is given, you can attach one later.

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.

Takes no parameters.

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.

List the services (runtime processes) of an app with their build source, port, replicas and status.

Get the runtime log output of one service (stdout/stderr of its running containers), last N lines.

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.

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.

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.

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.

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.

Preview what a deploy would change without making any changes. Use this before runzero_deploy to verify the diff.

Add a new service to an app. Clones the repo, builds with buildpacks, and deploys. The web process must listen on $PORT.

Permanently delete one service of an app: its running containers, its public URL and its configuration. Irreversible; to only stop it, scale it to 0 with 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.

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.

List the secret keys for an app (values are never returned). Includes both app-wide and per-service secrets.

Delete a single secret from an app or a service. Affected services are redeployed automatically.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Get the full log stream for a specific build (all kpack steps concatenated). Use runzero_list_builds first to find the build id.

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.

List all files in the app's Git repository (platform-managed repos only). Optionally filter by path prefix.

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.

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.

List the end-users of an app's login realm (requires the app's keycloak addon). Returns id, username, email and enabled state.

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.

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.

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).

Enable or disable (block) an end-user in the app's login realm. A disabled user cannot log in but is not deleted.

List external login providers (Google, GitHub, …) configured on the app's login realm. Secrets are never returned.

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.

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).

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.

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.

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.

Takes no parameters.

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.