cloud.redu/mcp

Lists available instance sizes.

Lists available OS images.

Lists your compute instances.

Lists your SSH keypairs. If empty, call import_keypair first before creating instances.

Lists Redu media spaces: private NFS media VMs backed by persistent volumes. For WordPress/WooCommerce clusters, reuse one on the app's private network for wp-content/uploads, or pass create_media_space:true to deploy_app/deploy_compose/upgrade_to_cluster so Redu creates one.

Lists your private networks.

Lists your managed Qdrant vector databases (create_qdrant, or started for a deploy). Once a row's status is 'ready' it carries private_ip (REST port 6333, gRPC 6334); the API key is never listed.

Lists your managed Redis instances. Once a row's status is 'ready' it carries the private-network connection details (private_ip, port 6379) - connect from another instance on the same private network with redis-cli -h <private_ip> -p 6379 -a <password>.

Lists available regions.

Lists your managed MySQL/MariaDB databases (the relational-database resource). Each row carries its engine ('mysql'|'mariadb'); once status is 'ready' it has the private-network connection details (private_ip, port 3306, db_name, db_user).

Lists your runs, newest first: id, name, status (running, ending, ended, end_failed) and how many resources each still holds.

Lists your security groups.

Lists your instance snapshots.

Lists your block storage volumes.

Turns YOUR repo classification (you scan the repo and pass what you found) into a complete, approvable deploy plan WITHOUT creating anything. ⚡ REDU NEEDS THREE FILES IF THEY EXIST - redu.md, the compose file, the Dockerfile - and there are two ways to give them. ⭐ BEST, for an upload-mode deploy: run prepare_upload FIRST and pass its `source_token`; redu reads all three straight out of the upload you already made, the upload stays deployable, and you emit nothing. Pasting the same files costs you 20-29 KB of output for bytes the server already has. Otherwise (git mode) paste `redu_md` (cat redu.md), `compose_yaml`, `dockerfile`. Either way you do NOT read or interpret them; redu parses them SERVER-SIDE and returns (a) a short digest, (b) `pin_dname` so a redeploy keeps the SAME public URL, and (c) `preflight` - preemptive fixes for known failure patterns found in YOUR repo, each learned from a real failed build. Giving redu these files is the single highest-value thing you can do for a first deploy. picks the VM + managed-Postgres sizes, prices them at the real pricing_rules rates, and checks they FIT your quota - so a plan that can't provision is caught HERE, before any spend. You pass what you detected in the repo (runtime, port, needs_postgres/redis/clickhouse/vector_db); it returns resources + £/hr + £/mo + a feasibility verdict + a checkpoint summary to confirm with the user. Defaults: app VM m1.medium, managed Postgres m1.small, managed ClickHouse m1.medium; pass single_vm to collapse the app + Postgres onto one VM. SET needs_clickhouse:true FOR ANY ANALYTICS-SHAPED APP (Plausible, PostHog, Langfuse, Matomo, SigNoz, or anything with a clickhouse image / CLICKHOUSE_* env / a ClickHouse client dep): those products keep config in Postgres and EVERY EVENT in ClickHouse, so the events tier is a second VM with a second line on the bill: measured 2026-08-07, omitting it quoted GBP 53.29/mo for a GBP 65.99/mo deployment. It is sized, quota-checked and priced here; u…

Aggregates images/flavors/keypairs/networks/security groups into human-friendly choices. Does not create anything. Happy path: import_keypair → plan_instance → create_instance → get_ssh_command. Call this second (after import_keypair, if you have no keypairs).

Plans a direct managed datastore create without provisioning anything. Use this before create_database, create_relational_database, create_redis, create_clickhouse or create_qdrant (engine 'qdrant', the vector database). For app deployments you need none of these: datastores are managed by default, so the ones you report in send_signals are started and wired for you. Pass ha:true to plan a highly available datastore (postgres or clickhouse): three machines instead of one, surviving the loss of a machine without manual failover, at roughly 3x the hourly rate. The returned plan carries the machine count so you can show the user the cost before anything is created.

Changes the data INSIDE a managed Postgres database, as the console does: rows, tables and columns, a SQL write, a CSV import, saved queries, the editing lock. Each write is sent once. Deleting, dropping, renaming, a SQL write and unlocking need confirm: true, set only after the user said yes. Call postgres_data_read action help first for the arguments.

Reads the data INSIDE a managed Postgres database, as the console's data view does: tables, rows (sorted, found), a table's info, one cell, a related row, one read-only SQL query, CSV export, saved queries. Changes nothing. Action help lists every action's arguments and the rules, for this tool and postgres_data_change.

Returns the LOCAL shell commands to package your working directory and upload it for an upload-mode deploy (no git, no PAT). Run them in the user's terminal, capture `source_token` from the upload's JSON response, then call deploy_app with that source_token (omit repo). The upload authenticates AUTOMATICALLY with a short-lived ticket minted from your MCP credential - NO API key needed in the command and nothing secret is printed (it falls back to needing $REDU_API_KEY only if minting is unavailable). Excludes node_modules/.git/.venv/build output and .env by default; honors .gitignore when is_git_repo=true.

Publish the included website's working HTTP application at its generated HTTPS hostname or one exact custom hostname the owner has verified with verify_domain. Point the custom hostname at the generated free-<operation ID without hyphens>.redu.cloud name using CNAME (or the same public edge address for an apex). Only one hostname is served: a custom hostname replaces the generated hostname, not an additional alias. Omit domain to keep the current hostname; pass null to restore the generated one. Verify application readiness and authentication first. All public website HTTP/HTTPS response bodies share 5 GB per UTC month, including multiple routes. Incoming uploads, VM downloads, SSH and private SQL are excluded. No direct public IP is assigned. Database publication and WebSocket upgrades are unavailable. Give the returned URL only after the action completes.

Publish a user-requested HTTP application from either pilot, including the smaller pilot on its own, at a generated public HTTPS URL. First install and start the application, enable its production authentication and verify its local HTTP port. This publishes the app only; it does not assign a public VM IP or expose database/SSH ports. Responses consume the existing shared 5 GB outgoing account budget. No paid VM is created. Inspect get_private_vps_action until complete and give the returned URL to the user together with their separately obtained SSH command. If installation fails, preserve the VM and give SSH access; do not claim a working URL. Reuse request_key after a timeout. One fixed application port per pilot lifetime; deleting the pilot removes its route.

Removes a custom domain from this account: a verified domain is no longer verified for it (using it again needs a new TXT check), and a pending claim is cancelled. The first call releases nothing: it shows the domain for the user to approve; call again with confirm:true only after their yes. The second call reports the platform's answer: released, or refused. A refusal because public names still use the domain (DOMAIN_IN_USE) lists those names, each with its id: remove each with delete_dns_entry (it asks for the user's yes first), then call this again. Releasing a domain deletes no deployment, instance or cluster.

Restores a backup into an existing volume (volumeId), an instance's volume (instanceId), or a new one (volumeName). Poll list_volumes for the restored volume. DISASTER RECOVERY (the original VM is gone, so its volume died with it): restore with volumeName to rebuild the data as a NEW volume. To bring the MACHINE back, pass that volume as create_instance's boot_volume_id - it boots from the restored disk, so the VM returns with its filesystem intact and nothing to mount. Use attach_volume instead only when you want the data as an EXTRA disk on an existing machine (then get_ssh_command -> lsblk -> mount). A restored volume is inert until it is booted from or attached.

OPTIONAL preflight: returns a podman-compose.yml + .env so the user can run the app (and a throwaway local Postgres) on THEIR machine before deploying to redu - to see it run / sanity-check the container. Requires local podman/podman-compose. It's a suggestion, not a gate - skip it and go straight to deploy_app any time. Honest caveat: the local Postgres is NOT the managed Postgres, so a green local run does not prove the prod DB wiring.

For a repo with SEVERAL runnable parts, call this BEFORE plan_deploy. You enumerate the candidate surfaces (find every Dockerfile/Containerfile, OPEN each, classify by its EXPOSE + CMD - never by directory name) and pass them in; redu RANKS them with fixed rules (a standalone browser desktop/noVNC > a self-contained web app > a keys-required playground > an API > a headless worker > docs/examples). GUIDED: returns the ranked list to present to the user, who picks. YOLO: auto-selects the TOP-ranked surface. Then run plan_deploy on the chosen surface's path + http_port. (A single-surface repo doesn't need this.)

Changes the PUBLIC HOSTNAME a cluster serves on, so the user can put THEIR OWN production domain (shop.acme.com, app.theircompany.com) in front of it instead of the auto-generated redu.cloud URL. That is what this tool is for: a real product on a real brand. The cluster itself is untouched - same members, same load balancer, same data - only the name in front of it changes. Pass stack_name + stack_id from list_clusters. TWO RULES, and getting either wrong wastes a call: (1) A CUSTOM DOMAIN MUST BE VERIFIED FIRST. Call get_domain_verification for the TXT record, have the user add it at their DNS provider, then call verify_domain until it reports verified (list_domains shows what is already verified). Binding an unverified domain is refused, on purpose: without proof of ownership anyone could bind, and obtain a certificate for, a hostname that is not theirs. Also make sure the domain's own DNS actually points at this cluster, or it will verify and still not serve. (2) A redu.cloud NAME CANNOT BE FREELY CHOSEN. The redu.cloud base domain is shared by every customer, so names under it always keep a short-id suffix - the real form is `<label>-<8chars>.redu.cloud`. Ask for a bare `myapp.redu.cloud` and you will NOT get it: the server normalises it and binds something else. If the first caller could pick any name under the shared domain, the good ones would all be gone. SO: the response carries `access_point`, the hostname the server ACTUALLY bound, which may differ from what you asked for. Report that value to the user and use it everywhere afterwards - never repeat your requested label back as if it were the URL. Finally, changing the hostname changes the URL: anything wired to the old one (OAuth callbacks, cookie domains, webhooks, an app told its own address) breaks until it is updated, so say so before you call this.

Turns nightly AUTOMATED (scheduled) backups ON or OFF for a MANAGED data service - the toggle that create_backup (a one-off volume snapshot) is NOT. Once enabled, redu's nightly job backs the service up on its own and prunes to the retention window; see them with list_backups and recover with the service's restore. Works for managed Postgres/MySQL/MariaDB/Redis/Qdrant/ClickHouse and can be flipped ANY time after provisioning, not only at create. Requires a card (automated backups are a paid feature; no-card trials cannot enable them). Pass the service type + its numeric id, enabled, and optional retention (days).

Updates a running autoscaling cluster to a new app version IN PLACE, with NO URL change: snapshots the 'hero' VM (the source/master VM you SSH into and change - it is also the always-on baseline member that serves traffic), then redu rolling-updates the autoscaled extra members to that snapshot ONE AT A TIME and refreshes the image the group boots future members from - the SAME load balancer and SAME *.redu.cloud URL are kept, and the service stays up during the roll. This is the ONLY way to update a cluster: you do NOT edit live members (they are disposable clones); you change the hero VM (SSH into it, deploy the new version), then update_cluster snapshots it and spreads it to the fleet (the hero already runs your change; this propagates it to the autoscaled members). It is low-disruption, not zero-downtime: measured, a rolling update failed about 2% of requests, in one short burst at each member swap, and never dropped below a majority of members. Never promise the user zero downtime. That holds ONLY if the app starts on every boot - a member whose app is launched by a first-boot-only script returns empty after replacement, never rejoins the pool, and the roll silently drains the cluster. The snapshot upload can take several minutes on a large disk; poll list_clusters until the stack status is UPDATE_COMPLETE.

THE WAY TO MAKE AN EXISTING APP HIGHLY AVAILABLE. If the user asks for high availability, redundancy, no single point of failure, surviving a host or VM failure, or 'stay up if a machine dies', this is the tool: point it at their running VM and pass high_availability:true. It needs no rebuild and no redeploy, and the URL does not change. Turns a single running instance into a horizontally-autoscaling cluster: snapshots the instance and puts your SOURCE VM behind a load balancer as its ALWAYS-ON BASELINE MEMBER, then an autoscaling group adds EXTRA members (booted from that snapshot) on CPU load and scales them back down to zero. FLAVOR - LEAD WITH A MEMORY-OPTIMIZED SMALL-DISK FLAVOR (m1.mem16/m1.mem32) for the cluster, and ideally have the SOURCE VM on one too: clustering snapshots the source VM's FULL disk, so DISK size (not RAM) drives how long the cluster takes to build and to add each member under load - a 40 GB mem flavor is several times faster to snapshot and scale than a 160 GB standard flavor (m1.xlarge) and costs less for the same RAM. If the source VM is on a big-disk flavor, RECOMMEND migrating the app onto a mem-flavor VM first (a root disk cannot be shrunk in place), even though it is extra work - it pays off on every scale-out, and a clustered app is stateless anyway (state in the managed DB) so the lean disk fits. Expect a DRASTICALLY better clustering experience on a mem flavor: far faster cluster-create, snapshots, and every scale-out. The user can override with any flavor. At rest ONLY your source VM serves - there is NO idle extra VM to pay for (the source VM is the cluster's minimum, so the floor is 0 extra members). Use it to LOAD-SCALE a stateless app tier while managed services hold state: it becomes highly-available UNDER LOAD (multiple members behind the LB), but at rest a SINGLE source VM serves - and that source VM is a plain VM, not an autoscaled member, so it is NOT auto-replaced if it fails while idle (only the autoscaled extra membe…

Turns an EXISTING, running single-machine managed Postgres or ClickHouse into a THREE-machine highly available cluster, in place, keeping the data and the same username, password and database name. Use this when the user has a live database and wants it to survive a machine or host failure: they do NOT have to create a new one and migrate by hand. How it works: a full backup is taken first (a safety copy while the upgrade runs, deleted when it ends: the old machine is never touched and stays the restore point), the cluster is built alongside, the data is copied in and verified by counting both sides, and only then does the database's address move to the load balancer. The original machine is left running and untouched throughout, so a failure changes nothing and the user is never without a database. SAY THREE THINGS TO THE USER AND GET A YES BEFORE CALLING: (1) COST, it becomes three machines behind a load balancer instead of one, so roughly 3x the hourly rate, and the old single machine keeps billing for 3 days, until it is removed automatically; (2) WRITE LOSS, anything written to the old machine during the copy is not carried over (see acknowledge_write_loss); (3) THEY MUST REPOINT THE APP afterwards, the connection address changes and nothing redeploys their app for them. Takes about 20 minutes and returns immediately; poll list_databases / list_clickhouse_databases until the address changes. Requires a payment method: high availability is not available on the no-card trial. ⛔ CLICKHOUSE ONLY, a FOURTH thing to say: after the upgrade every table has to use a REPLICATED engine. The existing tables are converted for them as part of the copy, but any NEW `CREATE TABLE ... ENGINE = MergeTree` is refused from then on (ClickHouse error 56) and has to be written `ENGINE = ReplicatedMergeTree`. It is refused rather than accepted because a plain MergeTree on three machines replicates its schema and not its rows, which would leave two of the three answering with an empty…

Asks redu to re-probe a deployment's public URL and update its status from what it actually observes. USE THIS AFTER YOU HAVE FIXED A FAILED DEPLOY - a deployment that ended 'error' or 'build_failed' but is now serving becomes 'ready' again, and you do NOT need to redeploy it to get a green status. Redeploying working infrastructure to clear a red flag wastes the user's money and throws away the fix. You cannot set the status yourself: this tool triggers a check, and the probe decides. Readiness means the URL answers with a non-5xx (401/403/404 count - they prove the app is answering), the same rule the deploy's own health gate uses. A deployment with no public URL (a headless worker) cannot be verified this way; use get_containers for its container state instead.

Checks the DNS TXT ownership record of a custom domain and, when it matches, marks the domain verified for this account. Call get_domain_verification first for the record, have the user add it at their DNS provider, then call this until it reports verified (a new record can take minutes, sometimes hours, to show). A verified domain can be bound: dname on deploy_app/deploy_compose, dns_entries on create_instance, or set_cluster_domain. A pending claim's TXT value can change (values are specific to each account), so add exactly the value get_domain_verification returns now, never one saved earlier or seen on another account; if verify_domain keeps failing, call get_domain_verification again and update the record when the value differs.

⭐ CALL THIS INSTEAD OF POLLING. Waits up to 50 seconds per call (an MCP client cuts a call at about 60 s) for the deployment to reach a TERMINAL state (ready, build_failed, error or vm_missing) and returns, in ONE response, everything you would otherwise fetch afterwards: the HTTP status of the PUBLIC url (not the VM's private interface, which can answer 401 while the public path still 502s), the container table with health and restarts, the host's memory/disk/load, and the .env KEY NAMES. Do NOT loop on get_deployment: that is 8-9 round trips per deploy that learn nothing, and then three more asking for what this already returned. ⚠️ A TIMEOUT IS NOT A FAILURE: if it returns timed_out:true the build is simply still running, so call it again (a typical deploy takes 2 to 5 calls). Only status decides success. On build_failed or error, call get_deployment(id) for the full build_log, which is the diagnosis.

Verifies your redu.cloud credential with a REAL server round-trip and returns your identity + live quota. A green result means the key actually works - not merely that one is configured. Use this first if anything is 401ing.