cloud.redu/mcp

Read-only. Fetches EVERY resource on your redu.cloud account (VMs, volumes, private networks, managed databases: Postgres/MySQL/MariaDB/ClickHouse/Redis/Qdrant, load balancers, and DNS access points) and renders ONE Mermaid diagram of the whole account, grouped into per-private-network subgraphs with repetition collapsed into count nodes (e.g. "App VM x12"). Returns report_markdown to save as redu_architecture_diagram.md at the repo root, PLUS a redu_md_section that enriches the repo's redu.md with the current account topology, so the NEXT deploy is account-aware: it integrates with services that already exist and picks models/versions/sizes that fit the stack (better decisions, not just avoiding duplicate networks/databases). Nothing is created or changed.

Attaches an EXISTING block volume to a running instance as an extra disk. This is how you finish a RESTORE after a VM is gone: restore_backup (volumeName) rebuilds the data into a new volume, then attach_volume puts that volume on a replacement instance - then SSH in (get_ssh_command) and mount it (`lsblk` to find it, usually /dev/vdb, then `mount /dev/vdb /mnt/...`). The volume must be 'available' (not already in-use - detach_volume it first) and in the same project. Attaching does NOT mount or boot from it: the instance keeps booting from its own root disk, the volume shows up as an extra block device. Poll list_volumes until status is 'in-use'.

The deploy ENTRY GATE - run this first when a user wants to deploy. Verifies the account is ready and AUTO-SELECTS the network_id + keypair_name to pass to deploy_app (so you never hunt for them): (1) account reachable + quota, (2) a private network (picks your default - every account has one), (3) an SSH keypair (if you have none, returns ssh_key_recipe: the exact local ssh-keygen → import_keypair → write SSH_KEY_LOCATION-to-.env steps - run them, in yolo mode without asking). Returns { ready, network_id, keypair_name, missing, ssh_key_recipe }.

Mints a NEW least-privilege redu API key for a deployed app or automation to use (e.g. to add a backup feature). GUARDRAIL: the first call does NOT create anything. It returns a confirmation the user must approve, because a key is a long-lived credential that acts on the account and ANY usage of it is BILLED to the account owner. Show the user the name, the exact scopes, and the billing notice, get their explicit approval, then call again with confirm:true. This is required even in yolo/auto mode. The secret is returned ONCE.

Creates a backup, by volumeId or by instanceId (the instance's volume is resolved for you). The backup is held independently of the instance, so it survives the VM. Poll list_backups until the new backup is available.

Provisions a managed ClickHouse database (OLAP / columnar analytics engine, Apache-2.0) on a dedicated VM on your private network - its OWN resource, NOT a relational database. Requires a recent plan_managed_datastore. Use it for analytics / observability workloads that need a column store (PostHog, Langfuse, event analytics, time-series). It is PRIVATE - reachable only from another instance on the same private network, via the DB's internal/private IP on the ClickHouse HTTP port 8123 (CLICKHOUSE_HOST/PORT/USER/PASSWORD/DB env, http://host:8123). Get the ids from plan_managed_datastore/list_flavors (use m1.small+ - ClickHouse needs >=2GB RAM), list_private_networks, list_keypairs. Provisioning takes ~5 min; poll list_clickhouse_databases until status='ready'. HIGH AVAILABILITY: pass ha:true to get THREE machines on three different physical hosts behind a load balancer instead of one: all three take reads and writes, so losing a machine costs no failover and no write pause, and the replacement refills itself from the survivors before it serves again. It costs about 3x the hourly rate (three machines instead of one) and provisions more slowly. Default is a single machine; show the user the price difference and get an explicit yes before turning HA on.

Provisions a managed PostgreSQL database on a dedicated VM on your private network. Requires a recent plan_managed_datastore. For app deployments, prefer deploy_app database:'managed' so plan_deploy includes and wires the DB automatically. It is PRIVATE - reachable only from another instance on the same private network, via the DB's internal/private IP (not a public address). Get the ids from plan_managed_datastore/list_flavors/list_private_networks/list_keypairs. Provisioning takes ~5 min; poll list_databases until status='ready', then the connection details (private_ip, port 5432, db_name, db_user) are populated. HIGH AVAILABILITY: pass ha:true to get THREE machines on three different physical hosts behind a load balancer with automatic failover instead of one machine: the database survives losing a machine, and nobody has to fail it over by hand. It costs about 3x the hourly rate (three machines instead of one), it provisions more slowly, and one connection string still serves the whole thing. Default is a single machine; show the user the price difference and get an explicit yes before turning HA on.

Create the included private PostgreSQL VM, with PostgreSQL installed automatically. Its fixed size is 1 CPU, 1 GiB RAM and 2 GiB total disk including Ubuntu. Create the included website VM first: all database access, including administration, goes through that website. No direct public SQL, SSH or HTTPS endpoint is provided for this database. No paid or pilot fallback. Create application tables in database redu as role redu, never as postgres. For local administration use sudo -u postgres psql -X -v ON_ERROR_STOP=1 -d redu and SET ROLE redu before application DDL or imports. This preserves console read/edit access and its default reader grants. A separate website runtime role may remain read-only. The default pg_hba.conf permits remote login only as redu from the website private address. For a separate runtime role, also add an exact host rule for database redu, that role and the website private IPv4 /32 with scram-sha-256 before the reject rules; validate pg_hba_file_rules and reload PostgreSQL. Keep all other sources rejected; never use trust or a public CIDR. Read the website address from the guest configuration rather than guessing it. SQL grants alone do not permit a new network login. Test the application connection from the website using its actual runtime role, without printing credentials, before publishing. If a shell command returns a nonzero exit code or the app returns HTTP 503, inspect its saved output and sanitized application error; do not repeat the installation blindly. Verify the table through postgres_data_read using the data-view ID returned by get_free_resources; discovery alone does not prove row access. Do not grant superuser or bypass row security to fix a permission error.

Create the included Ubuntu website VM. Its fixed size is 1 CPU, 2 GiB RAM and 10 GiB total disk. No hosting credit is consumed. It is separate from the pilot. If capacity is full, keep the queued operation and original request key; do not create a paid replacement. Wait for an active slot in get_free_resources before commands or SSH. Build apps on this VM with exec_free_resource, then publish_free_website. No paid fallback.

Creates a raw compute instance for custom OS/cloud-init workflows. For app/source deployments, prefer check_deploy_prerequisites -> plan_deploy -> deploy_app/deploy_compose; do not use create_instance as a shortcut around the deployment plan. Requires a recent plan_instance. For reduOS, set cloud_init_template='reduos' and flavor m1.xlarge (16GB). SSH keypair must exist. For a public web app on a raw VM, pass dns_entries (gives a .redu.cloud URL through redu's automatic public proxy). The origin app should listen on dns_entries[].port; do not install nginx on the VM unless the app itself needs it, because redu.cloud already creates the public Nginx proxy host.

Creates a private Redu media space: a small NFS VM backed by a persistent volume, intended for WordPress/WooCommerce wp-content/uploads in autoscaling clusters. Prefer letting deploy_app/deploy_compose create this by passing create_media_space:true after plan_deploy approval; use this tool when manually preparing or reusing shared uploads storage.

Creates an isolated private network in your account and returns its id, name and address range. It has its own router with an internet connection and no route to your other private networks, so a job's machines on it are kept apart from the rest of your account. Pass the id as network_id to create_instance or to the managed database tools. It is billed hourly while it exists and counts toward your account's network limit. Remove it with delete_private_network when the job is done.

Approved pilot accounts only. Create one website VM (1 CPU, 2 GiB RAM, 10 GiB total disk) or one database VM (1 CPU, 1 GiB RAM, 2 GiB total disk). Both start with plain Ubuntu. Maximum one of each, including pending and stopped VMs. The pair shares a 5 GB outgoing Internet budget; incoming and private traffic do not count. Pilot VMs and their specified boot disks have no charge. Existing paid resources keep normal billing. Reuse request_key when retrying this exact request. Creation does not install an application or publish a website. Either size can be used alone. For a smaller-only request, create kind database without a website VM. If the user wants SSH, obtain access with get_private_vps_ssh once active and include its returned command at the end, even if a later application install fails. Never delete or replace a failed tutorial VM unless requested.

Provisions a managed Qdrant vector database on a dedicated VM. Requires a recent plan_managed_datastore (engine 'qdrant'). Reachable from your private network at <private_ip>:6333 (REST) and :6334 (gRPC), and at a public https URL; every request must carry the api-key header (always required). Backups: set_managed_backups with service 'qdrant'. FOR AN APP YOU DEPLOY YOU DO NOT NEED THIS: report vector_engines:['qdrant'] in send_signals and the deploy starts and wires a managed Qdrant itself (a compose stack's own qdrant service is replaced by it). Provisioning takes a few minutes; poll list_qdrant until status='ready'.

Provisions a managed Redis instance on a dedicated VM on your private network. Requires a recent plan_managed_datastore. It is PRIVATE - reachable only from another instance on the same private network, via its internal/private IP on port 6379 (not a public address). AUTH (requirepass) is always enabled. Get the ids from plan_managed_datastore/list_flavors, list_private_networks (or check_deploy_prerequisites), list_keypairs - use the SAME network_id as the app that will connect. Provisioning takes ~5 min; poll list_redis until status='ready', then the connection details (private_ip, port 6379) are populated. Wire an app with REDIS_URL=redis://:<password>@<private_ip>:6379 (pass it via deploy_app env).

Provisions a managed MySQL (or MariaDB) database on a dedicated VM on your private network - the relational-database resource (use this instead of create_database when the app needs MySQL/MariaDB, e.g. WordPress, NextCloud, Matomo, many PHP/LAMP apps). Requires a recent plan_managed_datastore. For app deployments, prefer deploy_app database:'managed' with db_engine mysql/mariadb so plan_deploy includes and wires the DB automatically. It is PRIVATE - reachable only from another instance on the same private network, via the DB's internal/private IP (port 3306), not a public address. Get the ids from plan_managed_datastore/list_flavors/list_private_networks/list_keypairs. Provisioning takes ~5 min; poll list_relational_databases until status='ready', then the connection details (private_ip, port 3306, db_name, db_user) are populated. MySQL is created with mysql_native_password auth so older clients/apps connect cleanly. (ClickHouse is a separate resource - use create_clickhouse / list_clickhouse_databases.)

Starts a run: a record in your account that groups everything one job creates. Pass its id as run_id to create_private_network, create_instance and create_volume; each resource joins the run. When the job is done, end_run deletes everything in the run and checks each one gone. A run itself costs nothing; its resources are billed as usual.

Creates a snapshot of a running instance.

Creates a block storage volume.

Deletes one of the account's API keys, by id or by name. Anything that uses the key stops working at once, so the first call deletes nothing: it shows the key (name, scopes, last used) for the user to approve; call again with confirm:true only after their yes. Use it to clean up a key you created for a task that is finished.

Deletes a backup by ID.

Deletes a managed ClickHouse database and its underlying VM. Pass the numeric id from list_clickhouse_databases. This cannot be undone.

Deletes an autoscaling cluster - tears down the WHOLE cluster: every autoscaled EXTRA member VM, the load balancer, the pool, the cluster security group, and the cluster's *.redu.cloud proxy host. Your SOURCE (hero) VM is NOT part of the stack and is NOT deleted - it was the always-on baseline member but it is your own VM; delete_instance it separately if you no longer need it. Pass stack_name + stack_id from list_clusters. Deleting extra members individually does NOT work (the autoscaling group re-creates them under load) - this deletes the group itself. The managed database / external store the cluster used is NOT touched (data safety); delete_database it separately when you are done with the data. Cannot be undone.

Deletes a managed Postgres database and its underlying VM. Pass the numeric database id from list_databases. This cannot be undone.

Deletes a deployment and its underlying app VM, with the data kept on that machine (its named volumes): the only way kept data is deleted, so ask the user first. Pass the numeric id from list_deployments. IMPORTANT: its managed datastores are NOT deleted (data safety): its database, Redis and Qdrant keep running and billing, and this tool returns each id so you can delete_database / delete_relational_database / delete_redis / delete_qdrant them when you're done with the data. Cannot be undone.

Removes one public name (a DNS entry), by its id from list_dns_entries or by the name itself. The name stops serving at once, and anything reached through it (a site, an API, an OAuth callback) stops working with it. When the name belongs to one of your instances or deployments, that instance's own list of its names is updated too, the way the console's DNS view does it; the instance, its app and its data are untouched. The first call removes nothing: it shows the entry for the user to approve; call again with confirm:true only after their yes. Use it to clear the names a release_domain refusal (DOMAIN_IN_USE) lists. redu's own platform names cannot be removed.

Permanently delete one included free VM and its boot disk after explicit user authorization. Use its occupied operation ID from get_free_resources. Deleting the website interrupts access to the private database. The slot is released only after verified deletion. Monthly website usage is retained; no paid or pilot VM is affected.

Permanently deletes an instance. This cannot be undone.

Removes an SSH keypair from your account by name.

Permanently deletes a private network you added with create_private_network, which stops its billing. It is refused for your default network and for any network a machine is still attached to: delete those machines, or the resources running on them, first. Get the id from list_private_networks.

Permanently delete one of your pilot VMs and its boot disk, including all stored data. Requires explicit user authorization. Use the occupied operation id from get_private_vps_pilot, not a paid VM id. After deletion is verified its one-per-account slot becomes available for a new create_private_vps request. Keeps account approval, the other pilot, private networking and the existing outgoing allowance. Does not reset the monthly budget.

Deletes a managed Qdrant and its underlying VM, with every collection in it. Pass the numeric id from list_qdrant. This cannot be undone.

Deletes a managed Redis instance and its underlying VM. Pass the numeric id from list_redis. This cannot be undone.

Deletes a managed MySQL/MariaDB database and its underlying VM. Pass the numeric id from list_relational_databases. This cannot be undone.