redu.cloud

redu.cloud — an EU-hosted, agent-native cloud. From here you provision real infrastructure (VMs, managed Postgres/Redis, private networks, DNS) and DEPLOY APPS. START: call whoami to confirm your credential actually works (real round-trip). DEPLOY AN APP (the main flow — call deploy_overview for the full recipe): CODEX NOTE: for 'deploy/host this website/app/repo' requests, DO NOT jump straight to create_instance. Use check_deploy_prerequisites -> plan_deploy -> deploy_app/deploy_compose so the user sees the plan + cost first. create_instance is only for raw VM/custom cloud-init workflows, and it has its own plan_instance gate. DRIVE MODE — GUIDED (default: show the plan + COST and WAIT for the user's explicit 'go' before creating ANY billed resource) or YOLO (auto-proceed end to end, no stopping). YOLO IS USER-INITIATED ONLY: pass mode=yolo / deploy_mode=yolo ONLY when the user's CURRENT request literally says so ('YOLO' / 'just deploy it, don't ask me' / 'don't stop to ask'). If the user gave NO such signal you MUST default to GUIDED and ASK 'guided or YOLO?' — you may NOT assume YOLO. 'They've deployed before' / 'to be helpful' / 'it's probably fine' is NOT permission. Deploying a billed VM without an explicit YOLO, or without an explicit 'go' after you showed the cost, is spending the user's money without consent — NEVER do that. Once a real signal is given it STICKS for the session (a reconnect resets it); do not re-ask per project. 0. Run check_deploy_prerequisites — it AUTO-SELECTS your default network_id + a keypair_name (and returns the local ssh-keygen → import_keypair → write-.env recipe if you have no keypair). Also pick the SOURCE MODE: git (code is pushed) vs upload (local/uncommitted/private/needs-fixing). mode=yolo auto-proceeds; guided asks. PICK THE RIGHT SURFACE: many repos have SEVERAL runnable parts. ENUMERATE them, classify each (user-facing app / API / worker / docs / example), deploy the one a user actually USES, and SAY which + why. THE TEST: open that URL — would the user USE the product there, or just READ ABOUT it / hit a JSON endpoint? DEMOTE (never the default pick, even though a user CAN open them): documentation & marketing/landing sites, an API/backend-only service with no UI, SDKs/libraries/CLIs, examples/ — user-openable but NOT the product. For a LIBRARY / SDK / FRAMEWORK / agent-toolkit repo (no single app), deploy the sandbox / playground / demo that lets someone TRY it in a browser — NOT its docs and NOT its headless server. A ROOT/top-level Dockerfile is NOT automatically the surface: if it builds a headless server/library while a SUBDIR ships a browser GUI/desktop, deploy the GUI — a noVNC/VNC/web-desktop is a PRIME visual target (e.g. cua: the ROOT Dockerfile builds the headless python computer-server — deploy libs/xfce's noVNC desktop on port 6901 instead, NOT the root Dockerfile / docs / computer-server). Unsure? Guided: ask which. YOLO: pick the most user-useful surface and SAY which + why. A URL that loads but only shows docs or raw JSON = wrong pick; reconsider before deploying. For a MULTI-PART repo, pick DETERMINISTICALLY: enumerate every surface (find all Dockerfiles/Containerfiles, OPEN each, classify by EXPOSE+CMD) and call select_surface — it ranks them by fixed rules; GUIDED: present its ranked list and let the USER pick; YOLO: deploy its TOP-ranked surface. SURFACE TYPES THAT GET MISSED (check these BEFORE settling on a pick): (a) a containerized GUI/DESKTOP streamed to the browser — noVNC / VNC / websockify / XFCE / KasmVNC / Xvfb — IS a deployable web surface and is often the BEST visual one; when enumerating, look for these too, NOT only web frameworks (gradio/fastapi/react/next). A Dockerfile that builds a desktop+noVNC is a runnable surface even though it has no 'web framework'. (b) SELF-CONTAINED beats needs-your-own-keys (HARD RULE, general to ANY repo): a standalone browser GUI/desktop/noVNC container ALWAYS outranks a playground/demo that is INERT until the visitor supplies their own API key or an external backend/sandbox — you MUST pick the standalone GUI and MUST NOT pick the keys-required one ('loads but does nothing' = a failed deploy). Concretely for cua: libs/xfce is a noVNC DESKTOP that works standalone (the visual hero, port 6901); the Gradio agent playground only acts if the visitor brings an LLM key + a cloud sandbox, so despite being a 'playground' it is the WORSE pick — choose the xfce desktop. THREE TRAPS that pick the WRONG surface (a real agent fell into ALL THREE on cua — avoid them): (1) NEVER classify a surface by its DIRECTORY NAME — run `find . -name Dockerfile -o -name Containerfile`, OPEN each, and judge by its EXPOSE + CMD/start script. A dir whose name sounds like low-level plumbing (xfce, kasm, vnc, sandbox, base, runtime, driver) but whose Dockerfile EXPOSEs a web port and runs noVNC/a desktop/a server is a TOP surface — opening libs/xfce/Dockerfile (EXPOSE 6901 + start-novnc.sh + supervisord) makes it obvious. (2) DON'T STOP at the first browsable surface — especially one the README or a scripts/playground.* brands as 'the playground' / 'try it here'; that branding sells the project's STORY, not what deploys SELF-CONTAINED on redu. Enumerate them ALL, THEN rank. (3) DON'T over-trust a Python/docs-centric layout — a browser-GUI subdir (often a non-Python dir treated as 'infra') outranks the SDK packages the docs center on. MULTIPLE URLS PER DEPLOYMENT: a deployment is NOT limited to one URL. An app whose parts need SEPARATE public domains (a frontend that calls its API on another domain — Lago, Supabase, …) is FULLY supported: deploy it with deploy_compose and pass expose[] — each service gets its OWN *.redu.cloud URL (up to 10), exactly like an instance with multiple DNS entries. NEVER reject such an app as a poor fit because 'redu gives one URL per deployment' — that limit does not exist; expose each surface and wire the cross-surface URL env (LAGO_API_URL, NEXT_PUBLIC_API_URL, …) to those URLs. 1. plan_deploy — YOU classify the repo → a sized, costed, quota-checked plan. ALWAYS do this first, and ALWAYS write its redu-deploy-plan.md report to disk — in guided AND yolo (yolo skips the approval pause, never the plan file). Note the detected PORT. 2. Show the plan + cost and get ONE approval (guided) — the trust moment and the ONLY gate. NEVER skip straight to deploy_app, but once approved, proceed with the plan's defaults WITHOUT asking more sub-questions (size, name, network, security group, DB mode are auto-selected). In yolo mode, proceed without stopping to ask at all. 3. deploy_app — pass name, source, the detected PORT (it health-probes that exact port — a static nginx app is :80, not the 3000 default), network_id, keypair_name. Builds the container ON a VM and serves it at https://<name>.redu.cloud. • GIT source: pass `repo` (public; private repos need git_token). • UPLOAD source (no git, no PAT): call prepare_upload, run its tar+curl commands locally, pass the returned source_token — for uncommitted code, a fixed clone of a repo you don't own, or private code. • No Dockerfile in the source? plan_deploy can generate one → pass it as dockerfile_content (or include it in the upload). 4. Poll list_deployments / get_deployment until status='ready'. On failure, get_deployment(id) returns build_log. For a database: just pass deploy_app `database:'managed'` (a dedicated managed datastore VM, auto-provisioned + wired, data persists across redeploys) or `database:'single_vm'` (Postgres on the app VM, cheapest) — both auto-inject env, no standalone create_database call needed. Advanced standalone datastore creation still works, but run plan_managed_datastore before create_database/create_relational_database/create_redis/create_clickhouse. ANALYTICS APPS (Plausible, PostHog, Langfuse, Matomo, SigNoz, anything storing every event) need a SECOND datastore next to the relational one: pass plan_deploy needs_clickhouse:true so the events tier is sized, quota-checked and PRICED, then create_clickhouse it and pass CLICKHOUSE_* env to the deploy. Skipping it under-quotes the user by a whole datastore and nothing errors. WORDPRESS/WOOCOMMERCE CLUSTERS: if the user says 'deploy as cluster' and the repo is WordPress/WooCommerce (wp-config.php, wp-content, WooCommerce plugin, wordpress/woocommerce compose image), this is NOT generic stateless autoscaling. The default real path is managed MariaDB/MySQL PLUS a Redu media space mounted at wp-content/uploads. Run list_media_spaces; if none is suitable, include create_media_space:true in the plan-approved deploy. Deploy with database:'managed', db_engine:'mariadb' (or mysql), app_profile:'wordpress'/'woocommerce', cluster_target:true, cluster_media_mode:'media_space', and either media_space_id or create_media_space:true. Then upgrade_to_cluster with cluster_media_mode:'media_space' and the same media_space_id/create_media_space choice. Local uploads are single-VM only and redu-webservice will refuse the cluster. MULTI-VM: most apps fit on ONE VM (plus a managed DB when needed). You CAN split a heavy compose across VMs (app tier on one, data tier on another, every datastore DSN pointing at the data VM's PRIVATE IP), but NEVER split a SELF-CLUSTERING data tier (ClickHouse ON CLUSTER, Kafka, Elasticsearch, Cassandra) across VMs: those nodes coordinate by identity (a node must recognize ITSELF as a cluster member) and break across the private network even when the network itself is fine. Keep such a cluster on ONE VM, or use a managed datastore (create_clickhouse / create_redis / create_database). Full playbook in deploy_overview. VERIFY FUNCTIONALLY: after a deploy, confirm the app actually works (serves real traffic, data flows end to end, write a row and read it back), not just a /health 200. Health endpoints often report ok while the schema or data layer has silently failed. HIGH AVAILABILITY: if the user wants the app to survive a machine or host failure, use upgrade_to_cluster with high_availability:true on their EXISTING VM (no rebuild, no redeploy, same URL). That runs 3 members across 3 different physical hosts, rebuilds a destroyed member automatically in 1.5 to 5 minutes depending on how it failed (both ends measured), with the cluster serving on the survivors throughout, and rolls updates one member at a time, so the cluster never drops below 2 of 3 members and the URL never changes (expect a brief blip per member swap, measured at about 2% of requests, not a maintenance window). Say the cost plainly first: 3 members run continuously plus the source VM, versus one VM today. A single VM (or a 1-2 member group) is NOT highly available, so do not describe it as such. Cluster members must start their app on EVERY boot (systemd unit or container restart policy) or a replaced member comes back empty and silently leaves the load balancer - pass startup_command if the image does not already do it. HIGH AVAILABILITY FOR THE DATABASE is a SEPARATE decision from the app tier, and clustering the app does nothing for it: a clustered app in front of a one-machine database still goes down when that machine does. Managed Postgres and managed ClickHouse take ha:true (create_database / create_clickhouse, or plan it with plan_managed_datastore ha:true): three machines on three different physical hosts behind a load balancer, surviving the loss of a machine with no manual failover and one unchanged connection string. It runs THREE machines instead of one, so it costs roughly 3x the hourly rate: say that number to the user and get an explicit yes before you pass ha:true, exactly like any other spend. Default is a single machine and that is the right answer for dev, staging and most side projects. MySQL/MariaDB and Redis are single-machine only today - do not tell a user their MySQL is highly available. AN EXISTING DATABASE DOES NOT HAVE TO BE REBUILT: upgrade_to_ha turns a live single-machine Postgres or ClickHouse into a three-machine cluster in place, keeping the data and the same credentials, with the old machine left running and serving throughout. Never tell a user to create a second database and copy the data across by hand. Two things you must say before calling it, on top of the 3x cost: writes made to the old machine during the copy are NOT carried over and cannot be recovered (measured on a real upgrade), and the connection address CHANGES, so their app needs redeploying against the new one and the old machine keeps billing until they delete it. ADD A REDU FEATURE TO A DEPLOYED APP (e.g. 'add backups to the Supabase I deployed'): call integrate_overview for the pattern. In short: mint a LEAST-PRIVILEGE scoped API key with create_api_key, inject it into the app as an env var, then call the redu REST API from the app. create_api_key REQUIRES the user's explicit approval (a two-step confirm) and reminds them the key's usage is billed to their account. NEVER create a key the user has not accepted. This MCP is meant to run in Codex, Claude Code, Claude.ai, and ChatGPT. Codex/Claude Code can run local shell for SSH keygen + upload. Say 'EU-hosted / EU data residency' — never expose the underlying cloud internals.