cloud.redu/mcp

Est-ce que cloud.redu/mcp est sûr ?

Au dernier audit MCP Hub, le serveur MCP « cloud.redu/mcp » est classé « Non encore testé ». Référencé dans l'annuaire. Seul le pentest comportemental fait foi, et il n'a pas encore été exécuté sur ce serveur. Le verdict est réévalué en continu ; consultez la fiche pour l'état à jour.

Méthode : MCP Hub analyse la description de chaque outil (couche 1) et, pour le verdict fort, exécute le serveur dans une micro-VM isolée avec leurres et réseau bloqué (couche 2). On publie des noms et des compteurs, jamais le contenu brut renvoyé par un outil.

Les 88 outils

• architecture_diagram≈ 473 tokens

  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.

  Paramètres, retour & exemple (3)

  Paramètres

  • include_managed · boolean · optionnel
    Include managed databases (Postgres/MySQL/MariaDB/ClickHouse/Redis/Qdrant) in the map (default true).
  • include_volumes · boolean · optionnel
    Include block volumes in the map (default true).
  • include_load_balancers · boolean · optionnel
    Include load balancers in the map (default true).

  Exemple d'appel

  {"name": "architecture_diagram", "arguments": {"include_managed": true, "include_volumes": true, "include_load_balancers": true}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "counts": "texte", "resources": "texte", "redu_md_section": "texte", "report_filename": "texte", "report_markdown": "texte", "redu_md_filename": "texte"}}

• attach_volume≈ 518 tokens

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

  Paramètres, retour & exemple (2)

  Paramètres

  • volume_id · string · requis
    Volume to attach/detach - from list_volumes (id). For a recovery, this is the volume restore_backup created (restore_backup with volumeName makes a NEW volume from a backup).
  • instance_id · string · requis
    Instance to attach it to / detach it from - from list_instances (id).

  Exemple d'appel

  {"name": "attach_volume", "arguments": {"volume_id": "texte", "instance_id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• check_agent_prerequisites≈ 212 tokens

  Checks if your account has everything needed to run autonomous coding agents. Returns a checklist: API key validity, private network, SSH keypair, and billing. Safe to call anytime - read-only. Call this first before create_controller.

  Paramètres, retour & exemple (1)

  Paramètres

  • github_pat · string · optionnel
    GitHub Personal Access Token to validate (repo + workflow scopes required)

  Exemple d'appel

  {"name": "check_agent_prerequisites", "arguments": {"github_pat": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"all_ok": true, "checks": "texte"}}

• check_deploy_prerequisites≈ 470 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • mode · string · optionnel · guided | yolo
    OMIT by default: the session deploys end to end with no questions (yolo: the default network, a keypair created if missing). Pass 'guided' ONLY when the user explicitly said they want to approve or to be specific about something; it is STICKY for the session once set, so omit it on later re-checks. Defaults to the session's sticky mode, or the no-questions default if never set.

  Exemple d'appel

  {"name": "check_deploy_prerequisites", "arguments": {"mode": "guided"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "quota": "texte", "ready": true, "missing": [], "account_ok": true, "network_id": "texte", "keypair_name": "texte", "platform_facts": [], "ssh_key_recipe": []}}

• create_api_key≈ 568 tokens

  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.

  Paramètres, retour & exemple (4)

  Paramètres

  • name · string · requis
    A recognizable name for the key, e.g. 'supabase-backups'.
  • scopes · array · requis
    LEAST-PRIVILEGE scopes the key may use, e.g. ['instance:read','backup:read','backup:create','backup:restore']. Grant only what the feature needs. Discover the catalog via GET /v1/capabilities (grammar '<resource>:<action>'). billing/subscription/payment/admin are human-only and cannot be granted.
  • confirm · boolean · optionnel
    Set true ONLY after the user has explicitly approved (see the confirmation the first call returns). Leave unset to get the approval prompt first. Do NOT set it yourself.
  • expires_in_days · integer · optionnel
    Optional: auto-expire the key after N days.

  Exemple d'appel

  {"name": "create_api_key", "arguments": {"name": "texte", "scopes": []}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"key": "texte", "mode": "texte", "name": "texte", "next": "texte", "error": true, "scopes": "texte", "warning": "texte", "expires_at": "texte", "validation": "texte", "billing_notice": "texte", "needs_confirmation": true}}

• create_backup≈ 422 tokens

  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.

  Paramètres, retour & exemple (3)

  Paramètres

  • volumeId · string · optionnel
    ID of the volume to back up (see list_volumes). Provide this OR instanceId.
  • backupName · string · requis
    A name for the backup.
  • instanceId · string · optionnel
    ID of the instance to back up - its bootable (else first) attached volume is resolved automatically, so no volume:list scope is needed. Provide this OR volumeId.

  Exemple d'appel

  {"name": "create_backup", "arguments": {"backupName": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• create_clickhouse≈ 1587 tokens

  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.

  Paramètres, retour & exemple (11)

  Paramètres

  • ha · boolean · optionnel
    High availability. FALSE (the default) = ONE machine: right for dev, staging and most side projects, but if that machine dies the database is down until it is rebuilt. TRUE = THREE machines on three different physical hosts behind a load balancer, so losing a machine does not lose the database and nobody has to fail it over by hand. COST, say this to the user BEFORE you pass true: three machines instead of one at the size you picked, so roughly 3x the hourly rate of the same non-HA ClickHouse (plus a load balancer). Get an explicit yes on that number: a user who discovers HA from their bill was not asked. ClickHouse gets the easy version of this: all three machines accept reads AND writes, so there is no promotion step and no write pause. A machine dying is dropped from the load balancer, the other two carry on, and its replacement refills itself from them and is only allowed back once it has actually caught up. Queries that were running on the machine that died fail once and need a retry; new queries never see it. ⛔ ONE CONSTRAINT YOU MUST TELL THE USER BEFORE THEY CHOOSE THIS: on three machines every table has to use a REPLICATED engine. `ENGINE = MergeTree` is refused outright (ClickHouse error 56, UNKNOWN_STORAGE) - write `ENGINE = ReplicatedMergeTree` instead, with no arguments. 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 the user's queries with an empty table and no error. So anything that ships plain-MergeTree migrations - Plausible, PostHog and Langfuse all do - cannot run on the three-machine version without changing its migrations, and should use the single machine. HA takes longer to provision than a single machine, because the machines are built one at a time on purpose so they land on different hosts. HA is not a backup: it replicates your mistakes too, so keep backups on either setting.
  • name · string · requis
    Name for the managed ClickHouse database (lowercase letters, numbers, hyphens).
  • db_name · string · optionnel
    The database to create (default 'analytics').
  • db_user · string · optionnel
    The database user (default 'appuser').
  • flavor_id · string · requis
    Instance size for the ClickHouse VM - from list_flavors. ClickHouse is RAM-hungry; pick m1.small (2GB) or larger.
  • superuser · boolean · optionnel
    Grant the db user global rights (CURRENT GRANTS(ALL ON *.*)) on top of its own database - safe here, it is a dedicated single-tenant VM. SET IT for any app whose own MIGRATIONS create ClickHouse objects outside their database, above all USER-DEFINED FUNCTIONS. Measured 2026-08-08: a stock Plausible deploy crash-loops forever on `Code: 497 ... necessary to have the grant CREATE FUNCTION ON *.*` while it creates its 12 acquisition_channel functions, and no amount of retrying fixes it - the database has to be created with this flag. PostHog and other analytics apps that ship SQL UDFs are the same shape. Without it the app deploys, the container restarts, and the only symptom is a migration stack trace.
  • network_id · string · requis
    Private network id - from list_private_networks. The DB is reachable only from this network.
  • db_password · string · optionnel
    Password for the db user (letters/numbers/_/- only). Auto-generated and returned once if omitted.
  • keypair_name · string · requis
    SSH keypair name - from list_keypairs.
  • idempotency_key · string · optionnel
  • security_group_names · array · optionnel

  Exemple d'appel

  {"name": "create_clickhouse", "arguments": {"name": "texte", "flavor_id": "texte", "network_id": "texte", "keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• create_controller≈ 411 tokens

  Creates a self-configuring controller VM on redu.cloud. Auto-discovers your network, Ubuntu image, and flavor. Generates and uploads an SSH keypair if you don't have one. The VM bootstraps itself - no SSH or VPN needed. After ~7 minutes, authorize the fleet (run the authorize.sh one-liner it returns) then call trigger_agent_batch.

  Paramètres, retour & exemple (3)

  Paramètres

  • repo · string · requis
    GitHub repo to run agents on, e.g. 'owner/repo'
  • github_pat · string · requis
    GitHub Personal Access Token (repo + workflow scopes)
  • worker_count · integer · optionnel
    Number of worker VMs to provision (default 3)

  Exemple d'appel

  {"name": "create_controller", "arguments": {"repo": "texte", "github_pat": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"dns": "texte", "mode": "texte", "next": [], "status": "texte", "ssh_user": "texte", "log_token": "texte", "instance_id": "texte", "ssh_key_name": "texte", "trigger_token": "texte", "controller_host": "texte", "ssh_private_key": "texte", "authorize_command": "texte"}}

• create_database≈ 1423 tokens

  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.

  Paramètres, retour & exemple (13)

  Paramètres

  • ha · boolean · optionnel
    High availability. FALSE (the default) = ONE machine: right for dev, staging and most side projects, but if that machine dies the database is down until it is rebuilt. TRUE = THREE machines on three different physical hosts behind a load balancer, so losing a machine does not lose the database and nobody has to fail it over by hand. COST, say this to the user BEFORE you pass true: three machines instead of one at the size you picked, so roughly 3x the hourly rate of the same non-HA Postgres (plus a load balancer). Get an explicit yes on that number: a user who discovers HA from their bill was not asked. What it does and does NOT do for Postgres, state this honestly: only one of the three machines takes writes, so losing either of the other two changes nothing at all, and reads keep working through any single loss. Losing the WRITE machine pauses writes for roughly 30 seconds while one of the others is promoted, and transactions that were open at that moment fail and have to be retried by the app. That is true of every Postgres HA setup, hosted or not, so never promise zero downtime. Say 'no lost writes, one pause of about half a minute'. HA takes longer to provision than a single machine, because the machines are built one at a time on purpose so they land on different hosts. HA is not a backup: it replicates your mistakes too, so keep backups on either setting.
  • name · string · requis
    Name for the managed database (lowercase letters, numbers, hyphens).
  • db_name · string · optionnel
    The database to create (default 'app').
  • db_user · string · optionnel
    The database user (default 'appuser').
  • version · string · optionnel · 16 | 15 | 14
    Postgres major version (default 16).
  • flavor_id · string · requis
    Instance size for the DB VM - from list_flavors.
  • superuser · boolean · optionnel
    Grant the db user SUPERUSER - safe here (a dedicated single-tenant DB VM). Use when the app's own migrations must CREATE EXTENSION or alter roles.
  • extensions · array · optionnel
    Postgres extensions to pre-install at provision time (allowlisted): 'pgvector'/'vector' (embeddings), 'postgis' (geo), 'pgaudit', 'pg_trgm', 'pgcrypto', 'hstore', 'uuid-ossp', 'citext', 'ltree', 'pg_stat_statements', 'btree_gin', 'btree_gist'. Saves SSHing in to run CREATE EXTENSION; needed by apps like langfuse/lantern (pgvector).
  • network_id · string · requis
    Private network id - from list_private_networks. The DB is reachable only from this network.
  • db_password · string · optionnel
    Password for the db user. Auto-generated and returned once if omitted.
  • keypair_name · string · requis
    SSH keypair name - from list_keypairs (for operating the DB VM).
  • idempotency_key · string · optionnel
  • security_group_names · array · optionnel

  Exemple d'appel

  {"name": "create_database", "arguments": {"name": "texte", "flavor_id": "texte", "network_id": "texte", "keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• create_instance≈ 909 tokens

  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.

  Paramètres, retour & exemple (15)

  Paramètres

  • name · string · requis
  • port · integer · optionnel
  • dname · string · optionnel
  • volume · object · optionnel
  • image_id · string · requis
  • flavor_id · string · requis
  • imageName · string · optionnel
  • user_data · string · optionnel
  • network_id · string · requis
  • dns_entries · array · optionnel
    Public DNS/proxy entries to create automatically. Use [{ dname:'', port:8080 }] to generate a redu.cloud URL pointing at an origin process on port 8080.
  • keypair_name · string · requis
  • boot_volume_id · string · optionnel
    DISASTER RECOVERY: boot this new VM from an EXISTING volume (one restore_backup just created) instead of a fresh image, so the machine comes back with the restored filesystem AS its root disk. The volume must be 'available' (detached) and bootable. image_id is ignored when this is set. Without it, a restored disk can only be attached as a SECOND device and the VM still boots off a blank root disk.
  • idempotency_key · string · optionnel
  • cloud_init_template · string · optionnel · reduos
  • security_group_names · array · optionnel

  Exemple d'appel

  {"name": "create_instance", "arguments": {"name": "texte", "image_id": "texte", "flavor_id": "texte", "network_id": "texte", "keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• create_media_space≈ 631 tokens

  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.

  Paramètres, retour & exemple (8)

  Paramètres

  • name · string · requis
    Name for the media space, e.g. myshop-media.
  • size_gb · integer · optionnel
    Persistent media volume size in GB.
  • flavor_id · string · optionnel
    Small VM flavor id for the NFS media server. m1.small is enough for most WordPress uploads.
  • mount_path · string · optionnel
    Host mount path that app VMs will use before binding into /var/www/html/wp-content/uploads.
  • network_id · string · optionnel
    Private network id. Use the same network as the WordPress app and managed DB.
  • keypair_name · string · requis
    Existing SSH keypair name.
  • idempotency_key · string · optionnel
  • security_group_names · array · optionnel
    Security groups for the media VM. Redu opens NFS 2049 from private networks only.

  Exemple d'appel

  {"name": "create_media_space", "arguments": {"name": "texte", "keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• create_qdrant≈ 696 tokens

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

  Paramètres, retour & exemple (7)

  Paramètres

  • name · string · requis
    Name for the managed Qdrant (lowercase letters, numbers, hyphens).
  • api_key · string · optionnel
    The API key every request must send (the api-key header). Auto-generated and returned once if omitted. A managed Qdrant always requires one.
  • flavor_id · string · requis
    Instance size, from plan_managed_datastore/list_flavors. m1.small (2GB) holds most collections; vectors live in RAM, so size up for millions of large vectors.
  • network_id · string · requis
    Private network id, from list_private_networks (or check_deploy_prerequisites). Use the SAME network as the app that will connect.
  • keypair_name · string · requis
    SSH keypair name, from list_keypairs (for operating the Qdrant VM).
  • idempotency_key · string · optionnel
  • security_group_names · array · optionnel

  Exemple d'appel

  {"name": "create_qdrant", "arguments": {"name": "texte", "flavor_id": "texte", "network_id": "texte", "keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• create_redis≈ 725 tokens

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

  Paramètres, retour & exemple (8)

  Paramètres

  • name · string · requis
    Name for the managed Redis instance (lowercase letters, numbers, hyphens).
  • version · string · optionnel · 7 | 6
    Redis major version (default '7').
  • password · string · optionnel
    Redis AUTH password (requirepass). Auto-generated and returned once if omitted.
  • flavor_id · string · requis
    Instance size for the Redis VM - from list_flavors. m1.small (2GB) is plenty for most caches/queues.
  • network_id · string · requis
    Private network id - from list_private_networks (or check_deploy_prerequisites). Redis is reachable only from this network; use the SAME network as the app that will connect.
  • keypair_name · string · requis
    SSH keypair name - from list_keypairs (for operating the Redis VM).
  • idempotency_key · string · optionnel
  • security_group_names · array · optionnel

  Exemple d'appel

  {"name": "create_redis", "arguments": {"name": "texte", "flavor_id": "texte", "network_id": "texte", "keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• create_relational_database≈ 938 tokens

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

  Paramètres, retour & exemple (11)

  Paramètres

  • name · string · requis
    Name for the managed database (lowercase letters, numbers, hyphens).
  • engine · string · optionnel · mysql | mariadb
    Database engine: 'mysql' (default) or 'mariadb'. Both speak the MySQL protocol (mysql:// URL). Pick the one your app/stack uses. (For analytics/column-store needs use create_clickhouse instead - ClickHouse is not a relational DB.)
  • db_name · string · optionnel
    The database to create (default 'app').
  • db_user · string · optionnel
    The database user (default 'appuser').
  • version · string · optionnel
    Engine version (e.g. mysql '8.0', mariadb '11.4'). Defaults to the engine's current major if omitted.
  • flavor_id · string · requis
    Instance size for the DB VM - from list_flavors.
  • network_id · string · requis
    Private network id - from list_private_networks. The DB is reachable only from this network.
  • db_password · string · optionnel
    Password for the db user (letters/numbers/_/- only). Auto-generated and returned once if omitted.
  • keypair_name · string · requis
    SSH keypair name - from list_keypairs (for operating the DB VM).
  • idempotency_key · string · optionnel
  • security_group_names · array · optionnel

  Exemple d'appel

  {"name": "create_relational_database", "arguments": {"name": "texte", "flavor_id": "texte", "network_id": "texte", "keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• create_snapshot≈ 293 tokens

  Creates a snapshot of a running instance.

  Paramètres, retour & exemple (2)

  Paramètres

  • instanceId · string · requis
  • snapshotName · string · requis

  Exemple d'appel

  {"name": "create_snapshot", "arguments": {"instanceId": "texte", "snapshotName": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• create_volume≈ 289 tokens

  Creates a block storage volume.

  Paramètres, retour & exemple (2)

  Paramètres

  • name · string · requis
  • size · integer · requis

  Exemple d'appel

  {"name": "create_volume", "arguments": {"name": "texte", "size": 1}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• delete_api_key≈ 376 tokens

  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.

  Paramètres, retour & exemple (3)

  Paramètres

  • id · ? · optionnel
    The key's id, from list_api_keys.
  • name · string · optionnel
    Or the key's name, when exactly one key has it.
  • confirm · boolean · optionnel
    Set true ONLY after the user has explicitly approved deleting this key (see the confirmation the first call returns). Do NOT set it yourself.

  Exemple d'appel

  {"name": "delete_api_key", "arguments": {"id": "texte", "name": "texte", "confirm": true}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"key": "texte", "next": "texte", "error": true, "deleted": true, "matches": [], "validation": "texte", "needs_confirmation": true}}

• delete_backup≈ 176 tokens

  Deletes a backup by ID.

  Paramètres, retour & exemple (1)

  Paramètres

  • id · string · requis
    ID of the resource to delete.

  Exemple d'appel

  {"name": "delete_backup", "arguments": {"id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "mode": "texte", "next": "texte", "deleted": true}}

• delete_clickhouse≈ 208 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • id · string · requis
    ID of the resource to delete.

  Exemple d'appel

  {"name": "delete_clickhouse", "arguments": {"id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "mode": "texte", "next": "texte", "deleted": true}}

• delete_cluster≈ 397 tokens

  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.

  Paramètres, retour & exemple (2)

  Paramètres

  • stack_id · string · requis
    Cluster stack id, from list_clusters (id).
  • stack_name · string · requis
    Cluster stack name, from list_clusters (stack_name).

  Exemple d'appel

  {"name": "delete_cluster", "arguments": {"stack_id": "texte", "stack_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "deleted": true, "stack_id": "texte"}}

• delete_database≈ 206 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • id · string · requis
    ID of the resource to delete.

  Exemple d'appel

  {"name": "delete_database", "arguments": {"id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "mode": "texte", "next": "texte", "deleted": true}}

• delete_deployment≈ 309 tokens

  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.

  Paramètres, retour & exemple (1)

  Paramètres

  • id · integer · requis
    Deployment id from list_deployments.

  Exemple d'appel

  {"name": "delete_deployment", "arguments": {"id": 1}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": 1, "mode": "texte", "next": "texte", "deleted": true, "managed_db": "texte", "kept_stores": "texte"}}

• delete_dns_entry≈ 550 tokens

  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.

  Paramètres, retour & exemple (3)

  Paramètres

  • id · ? · optionnel
    The entry's id: `id` in list_dns_entries, or in the names a DOMAIN_IN_USE refusal of release_domain lists.
  • name · string · optionnel
    Or a public name the entry serves (e.g. shop.example.com), when exactly one entry has it.
  • confirm · boolean · optionnel
    Set true ONLY after the user has explicitly approved removing this name (see the confirmation the first call returns). Do NOT set it yourself.

  Exemple d'appel

  {"name": "delete_dns_entry", "arguments": {"id": "texte", "name": "texte", "confirm": true}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "mode": "texte", "next": "texte", "error": true, "names": [], "deleted": true, "matches": [], "validation": "texte", "forwards_to": "texte", "instance_id": "texte", "instance_updated": true, "needs_confirmation": true}}

• delete_instance≈ 184 tokens

  Permanently deletes an instance. This cannot be undone.

  Paramètres, retour & exemple (1)

  Paramètres

  • id · string · requis
    ID of the resource to delete.

  Exemple d'appel

  {"name": "delete_instance", "arguments": {"id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "mode": "texte", "next": "texte", "deleted": true}}

• delete_keypair≈ 177 tokens

  Removes an SSH keypair from your account by name.

  Paramètres, retour & exemple (1)

  Paramètres

  • name · string · requis
    Name of the keypair to delete.

  Exemple d'appel

  {"name": "delete_keypair", "arguments": {"name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "name": "texte", "deleted": true}}

• delete_qdrant≈ 206 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • id · string · requis
    ID of the resource to delete.

  Exemple d'appel

  {"name": "delete_qdrant", "arguments": {"id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "mode": "texte", "next": "texte", "deleted": true}}

• delete_redis≈ 200 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • id · string · requis
    ID of the resource to delete.

  Exemple d'appel

  {"name": "delete_redis", "arguments": {"id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "mode": "texte", "next": "texte", "deleted": true}}

• delete_relational_database≈ 211 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • id · string · requis
    ID of the resource to delete.

  Exemple d'appel

  {"name": "delete_relational_database", "arguments": {"id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "mode": "texte", "next": "texte", "deleted": true}}

• delete_snapshot≈ 177 tokens

  Deletes a snapshot by ID.

  Paramètres, retour & exemple (1)

  Paramètres

  • id · string · requis
    ID of the resource to delete.

  Exemple d'appel

  {"name": "delete_snapshot", "arguments": {"id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "mode": "texte", "next": "texte", "deleted": true}}

• delete_volume≈ 264 tokens

  Permanently deletes a block storage volume and the data on it. This cannot be undone. The volume must be 'available' (detached) - detach_volume it first, and note you cannot detach a running instance's boot disk. A volume left behind after a restore keeps billing, so delete the ones you no longer need. Any BACKUP the volume was restored from is independent and survives this.

  Paramètres, retour & exemple (1)

  Paramètres

  • id · string · requis
    ID of the resource to delete.

  Exemple d'appel

  {"name": "delete_volume", "arguments": {"id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "mode": "texte", "next": "texte", "deleted": true}}

• deploy_app≈ 3958 tokens

  Deploys an app to a VM and exposes it at a public https://<name>-<id>.redu.cloud URL. The container is built ON the VM. PREREQS - run check_deploy_prerequisites first for network_id + keypair_name, then plan_deploy for cost approval. Source can be git repo or prepare_upload source_token. PORT must be the real app listen port. DATASTORES ARE MANAGED BY DEFAULT: each one you reported in send_signals runs as a managed store started at your signal and is wired with no settings (DATABASE_URL and PG*/MYSQL_*, REDIS_URL, QDRANT_URL with QDRANT_API_KEY); without a signal, pass database:'managed' (db_engine 'postgres', or 'mysql'/'mariadb' for WordPress/Matomo/LAMP), redis:'managed' or qdrant:'managed'. For WordPress/WooCommerce cluster intent, do not use generic stateless deploy: pass app_profile, cluster_target:true, database:'managed', db_engine:'mariadb' or 'mysql', cluster_media_mode:'media_space', and either media_space_id or create_media_space:true. Redu mounts the media space into wp-content/uploads and refuses unsafe local uploads. Build+provision takes minutes; poll list_deployments/get_deployment. ROUTE: when plan_deploy returned recommended_route:'compose', do NOT use this tool for that folder: deploy its recommended_compose_file with deploy_compose (compose_file, recommended_service as service, recommended_port as port), for the reason in route_reason. The exceptions are route_next's: this tool builds the folder's Dockerfile instead only if the user asked for a build from source, the user changed the code the Dockerfile builds (check git status and unpushed commits in the folder), or the image cannot be pulled.

  Paramètres, retour & exemple (47)

  Paramètres

  • env · object · optionnel
    Env vars injected into the container at deploy time. Never baked into the image. With a managed store the platform also injects DATABASE_URL and PGHOST/PGPORT/PGUSER/PGPASSWORD/PGDATABASE (MYSQL_* for MySQL/MariaDB), REDIS_URL/REDIS_HOST/REDIS_PORT/REDIS_PASSWORD, QDRANT_URL/QDRANT_API_KEY. If the app reads OTHER names, map them here with references the VM fills in: e.g. {DB_TYPE: 'postgres', DB_HOST: '${PGHOST}', DB_PORT: '${PGPORT}', DB_USER: '${PGUSER}', DB_PASS: '${PGPASSWORD}', DB_NAME: '${PGDATABASE}'}. Check which names the app reads (its docs, its config code): otherwise its managed store sits unused.
  • name · string · requis
    Name for the deployment / VM (lowercase letters, numbers, hyphens).
  • port · integer · optionnel
    REQUIRED in practice: the port the app actually listens on inside the container - pass the port plan_deploy detected / the Dockerfile EXPOSE / the framework default. redu probes THIS port for health, so a wrong value fails the deploy. Defaults to 3000 only if omitted (e.g. a static nginx app listens on 80 - pass 80). IGNORED when worker:true.
  • repo · string · optionnel
    Filled in for you with the repository URL the USER gave (url_given_by_user in send_signals); the VM clones it. Otherwise omit it and pass source_token: the folder you work in is the source, and the platform refuses a repo it was not given. For a PRIVATE repo also pass git_token.
  • db_id · integer · optionnel
    Informational link to a managed Postgres (from create_database/list_databases).
  • dname · string · optionnel
    Custom *.redu.cloud subdomain. For a STABLE, KNOWN-AHEAD URL (needed when the app must be told its OWN url - OAuth callbacks, cookie domain, a frontend that calls its API), generate the FULL auto-gen form yourself: `<label>-<8 lowercase letters/digits>.redu.cloud` (e.g. `myapp-7k2m9x4p.redu.cloud`) - that exact form is used VERBATIM - and wire the app's own URL env to that SAME value. A BARE `<label>.redu.cloud` is NOT used as-is: redu appends a random 8-char suffix for uniqueness, so anything wired to the bare name will NOT match the real URL. Omit to auto-generate (then read the real URL from get_deployment).
  • redis · string · optionnel · none | managed
    Redis wiring (auto-injects REDIS_URL/REDIS_HOST/REDIS_PORT/REDIS_PASSWORD, zero setup): 'managed' = a SEPARATE managed Redis VM on the same private network (data persists across app redeploys; reused on a same-name redeploy). You never call create_redis for an app.
  • qdrant · string · optionnel · none | managed
    Vector DB wiring: 'managed' = a managed Qdrant on the same private network, wired as QDRANT_URL/QDRANT_HOST/QDRANT_PORT/QDRANT_GRPC_PORT/QDRANT_API_KEY (data persists across redeploys). The app must send QDRANT_API_KEY as its api-key; every managed Qdrant requires one. You never call create_qdrant for an app.
  • subdir · string · optionnel
    Build context within the source (e.g. 'demo-go') when the Containerfile/Dockerfile isn't at the root.
  • worker · boolean · optionnel
    HEADLESS WORKER / daemon mode. Deploys a long-running container with NO HTTP server, NO public URL, and NO health probe - ready = the container stays running. The VM still gets a floating IP + SSH stream (so you can SSH in), but nothing is exposed on the web. Use for background workers, a chaos-monkey, an on-infra agent runner, cron/queue consumers. `port`, `dname`, and the injected APP_URL/PUBLIC_URL are ignored. Run plan_deploy with worker:true too.
  • context · string · optionnel
    Build-context dir within the source (default: repo root, or `subdir`). Set when the Dockerfile lives in a subfolder but builds from the repo root.
  • db_name · string · optionnel
    DB name for single_vm/managed (default 'app').
  • db_user · string · optionnel
    DB user for single_vm/managed (default 'appuser').
  • git_ref · string · optionnel
    git mode only: branch/tag/commit to deploy (default: the repo's default branch).
  • runtime · string · optionnel
    Informational: node/python/go/… (e.g. from plan_deploy).
  • approved · boolean · optionnel
    ONLY when send_signals said approval_required (this account approves before anything paid starts): true after the USER said yes to the plan and its cost in this conversation. Never set it yourself, and leave it out in every other case.
  • database · string · optionnel · none | single_vm | managed
    DB wiring (auto-injects the connection env + DATABASE_URL, zero setup): 'managed' = a SEPARATE managed-DB VM on the same private network (data PERSISTS across app redeploys; reused on a same-name redeploy); 'single_vm' = Postgres ON the app VM (data dies when the VM is replaced; Postgres only; with a signal, only when the user asked for one VM). 'none' = no DB. You never call create_database/create_relational_database for an app.
  • db_engine · string · optionnel · postgres | mysql | mariadb
    Managed-DB engine (default 'postgres'). 'mysql'/'mariadb' provision a managed MySQL/MariaDB VM and wire MYSQL_HOST/MYSQL_PORT/MYSQL_USER/MYSQL_PASSWORD/MYSQL_DATABASE + a mysql:// DATABASE_URL - use for WordPress/Matomo/NextCloud/most PHP-LAMP apps. Requires database:'managed' (single_vm is Postgres only).
  • flavor_id · string · optionnel
    Instance size - from list_flavors. Default m1.medium (enough RAM to build on the VM). For a RAM-heavy app whose state is in a managed DB (Next.js/cal.com, Rails, JVM), prefer m1.mem16/m1.mem32: full RAM on a lean 40 GB disk, so it's cheaper and snapshots/clusters far faster than the 160 GB m1.xlarge/xlarge-highmem. If you will CLUSTER this app (upgrade_to_cluster), prefer m1.mem16/m1.mem32 regardless of RAM needs - a lean disk makes clustering and every scale-out several times faster (plan_deploy sizes cluster_target onto a mem flavor for you).
  • git_token · string · optionnel
    git mode only: token to clone a PRIVATE repo. Omit for public repos.
  • data_paths · array · optionnel
    Directories the app WRITES its data to inside its container (e.g. '/var/lib/myapp', '/app/data', a SQLite file's folder, an uploads folder): the data is kept on this machine, in named volumes, together with every VOLUME the image declares (kept without being named here). It survives a step-up, a restart, a reboot and every redeploy of the name, which runs on this same machine. Name the folder, never a file and never the code folder (redu refuses the image's working directory, which would keep the old code). Absolute paths, at most 16; a path once kept stays kept. While the deployment keeps data, a deploy that would need a new machine is refused: another size, port, keypair, hostname, route or worker mode, a single_vm database, or a stopped machine (start it with instance_action). To start fresh, delete_deployment (it deletes the data). A VOLUME the image declares is kept even when it holds code (for example a WordPress image's /var/www/html), so a redeploy does not replace code baked under it. Read the app's docs, Dockerfile or config for where it stores data.
  • db_version · string · optionnel
    DB version for single_vm/managed. Postgres: '16'|'15'|'14' (default 16). MySQL: '8.0'. MariaDB: '11.4'|'10.11'. Defaults per engine if omitted.
  • dockerfile · string · optionnel
    Path within the source to the Dockerfile (e.g. 'scripts/Dockerfile') when it's NOT at the root. Pair with `context` when the Dockerfile is in a subfolder but COPYs from the repo root.
  • machine_id · integer · optionnel
    EXPERIMENT: the prepared machine to run this deploy on, from prepare_machine. Omit: the newest one this session has not used yet.
  • network_id · string · optionnel
    Existing private network id - from check_deploy_prerequisites (auto-selects your default) or list_private_networks. Optional: if omitted, redu auto-selects your default network.
  • app_profile · string · optionnel · generic | wordpress | woocommerce
    Detected app profile from source inspection. For WordPress/WooCommerce pass wordpress/woocommerce so cluster deploys enforce managed DB + shared media instead of treating local uploads as stateless.
  • db_flavor_id · string · optionnel
    managed only: VM size for the dedicated Postgres (from list_flavors). Defaults to the app flavor; m1.small is plenty for most. plan_deploy sizes this for you.
  • db_superuser · boolean · optionnel
    managed/single_vm Postgres only: grant the app DB user SUPERUSER (dedicated single-tenant DB VM, so safe). Use when the app's migrations create extensions/roles themselves.
  • keypair_name · string · requis
    REQUIRED. An EXISTING SSH keypair name - call list_keypairs and reuse one, or import_keypair first.
  • source_token · string · optionnel
    UPLOAD MODE: token from prepare_upload's curl step - deploys an uploaded tarball of your LOCAL working dir (no git, no PAT). Use this to deploy uncommitted code, a fixed clone of a repo you don't own, or private code. Omit `repo` when set.
  • db_extensions · array · optionnel
    managed/single_vm Postgres only: extensions to pre-install (pgvector, postgis, pgaudit, pg_trgm, …). Pass when the app needs one - e.g. langfuse/lantern need pgvector - so you don't have to CREATE EXTENSION by hand.
  • redis_version · string · optionnel · 7 | 6
    managed Redis only: version (default '7').
  • cluster_target · boolean · optionnel
    Set TRUE when the user asked to deploy this app as an autoscaling cluster. For WordPress/WooCommerce this makes the backend require managed MySQL/MariaDB plus media_space/central_media_origin before deployment can proceed.
  • media_space_id · integer · optionnel
    Existing Redu media space id to mount at WordPress wp-content/uploads. Get it from list_media_spaces.
  • redis_password · string · optionnel
    managed Redis only: a specific password to set (otherwise auto-generated).
  • idempotency_key · string · optionnel
  • redis_flavor_id · string · optionnel
    managed Redis only: the dedicated Redis VM size (from list_flavors). Defaults to the app flavor; m1.small is plenty for a cache.
  • media_mount_path · string · optionnel
    Host mount path on the app VM/member. Redu mounts this into /var/www/html/wp-content/uploads.
  • media_origin_url · string · optionnel
    Public base URL where WordPress wp-content/uploads is served when using central_media_origin. Do not put this on the DB VM.
  • media_space_name · string · optionnel
    Optional media space name when create_media_space:true. Defaults to <deployment-name>-media.
  • qdrant_flavor_id · string · optionnel
    managed Qdrant only: the Qdrant VM size (from list_flavors).
  • cluster_media_mode · string · optionnel · local_uploads | central_media_origin | media_space
    Record the WordPress media strategy for future clustering. For real WordPress clusters use media_space by default: Redu mounts a shared uploads filesystem into every member. local_uploads is single-VM only and upgrade_to_cluster will refuse it for WordPress.
  • create_media_space · boolean · optionnel
    For WordPress/WooCommerce cluster_target:true: set TRUE when no suitable media space exists. Redu creates an NFS media VM + persistent volume and mounts it into /var/www/html/wp-content/uploads.
  • dockerfile_content · string · optionnel
    A Dockerfile to write into the build dir before building - pass the Dockerfile that plan_deploy generated when the repo has none, or to override a broken one. (In upload mode you can instead just include the Dockerfile in the tarball.)
  • media_space_size_gb · integer · optionnel
    Media space data volume size in GB when create_media_space:true (default 20).
  • security_group_names · array · optionnel
  • media_space_flavor_id · string · optionnel
    Flavor id for the media VM when create_media_space:true. Defaults to m1.small/backend default.

  Exemple d'appel

  {"name": "deploy_app", "arguments": {"name": "texte", "keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• deploy_compose≈ 3653 tokens

  Deploys a MULTI-CONTAINER app - a repo that ships docker-compose.yml / compose.yaml - onto ONE VM via podman-compose, and exposes one or more services at redu.cloud URLs. Use this instead of deploy_app when the repo is a compose stack. Same prereqs + source modes as deploy_app; always run plan_deploy first. PORT is the HOST port for the exposed service. DATASTORES ARE MANAGED BY DEFAULT: each one you reported in send_signals runs as a managed store; the stack keeps its own settings, and its own copy of each store is replaced by a forwarder of the same name to the managed one (the stack's own user, password and database created there, its init scripts run once). Pass no database/redis/qdrant settings; 'compose' (the stack's own) only when the user asked for one VM. For WordPress/WooCommerce cluster intent, do not leave the compose db service/local uploads as state: pass app_profile, cluster_target:true, database:'managed', db_engine:'mariadb' or 'mysql', cluster_media_mode:'media_space', and either media_space_id or create_media_space:true. Redu writes an override file that points the WordPress service at managed DB env and mounts the media space into /var/www/html/wp-content/uploads. Poll get_deployment until ready. ROUTE: when plan_deploy returned recommended_route:'compose', this is the tool for that folder, even when it also has a Dockerfile: pass its recommended_compose_file as compose_file, recommended_service as service and recommended_port as port (the HOST port the app service publishes, not the port the app listens on inside its container). route_reason says why the platform deploys it that way, and route_next when to build the Dockerfile with deploy_app instead.

  Paramètres, retour & exemple (47)

  Paramètres

  • env · object · optionnel
    Env vars APPENDED to the compose project's .env (for ${VAR} interpolation). We never rewrite your compose file.
  • name · string · requis
    Name for the deployment / VM (lowercase letters, numbers, hyphens).
  • port · integer · optionnel
    REQUIRED in practice: the HOST port the exposed service publishes (the LEFT side of its compose `ports:` mapping) - redu health-probes + proxies THIS port, so a wrong value fails the deploy. When plan_deploy recommends the compose route, its recommended_port is this port.
  • repo · string · optionnel
    Filled in for you with the repository URL the USER gave (url_given_by_user in send_signals); the VM clones it. Otherwise omit it and pass source_token: the folder you work in is the source. Private repo also needs git_token.
  • dname · string · optionnel
    Custom *.redu.cloud subdomain. For a STABLE, KNOWN-AHEAD URL (needed when the app must be told its OWN url - OAuth callbacks, cookie domain, a frontend that calls its API), generate the FULL auto-gen form yourself: `<label>-<8 lowercase letters/digits>.redu.cloud` (e.g. `myapp-7k2m9x4p.redu.cloud`) - that exact form is used VERBATIM - and wire the app's own URL env to that SAME value. A BARE `<label>.redu.cloud` is NOT used as-is: redu appends a random 8-char suffix for uniqueness, so anything wired to the bare name will NOT match the real URL. Omit to auto-generate (then read the real URL from get_deployment).
  • redis · string · optionnel · none | managed
    'managed' = a SEPARATE managed Redis VM: the stack's own redis service is replaced by a forwarder of the same name that authenticates to it (the managed Redis always has a password; the stack's own AUTH, if any, is answered for it), or REDIS_URL/REDIS_* is appended when the stack has no redis. 'none' keeps the stack's own redis.
  • expose · array · optionnel
    MULTI-SURFACE apps: expose several services, each gets its OWN *.redu.cloud URL. The FIRST entry is the primary one redu health-gates (its port overrides `port`). CRITICAL when one surface must KNOW another's URL (a frontend that calls its API - e.g. Lago's front -> API): GENERATE each surface's dname up front as `<label>-<8 lowercase letters/digits>.redu.cloud` (used VERBATIM) and wire the app's cross-surface URL env (LAGO_API_URL, LAGO_FRONT_URL, FRONTEND_URL, NEXT_PUBLIC_API_URL, …) to those EXACT values. Do NOT use a bare `<label>.redu.cloud` - redu appends a random suffix, so config wired to the bare name breaks.
  • qdrant · string · optionnel · none | managed
    'managed' = a managed Qdrant: the stack's own qdrant service is replaced by a forwarder of the same name that adds the managed API key, or QDRANT_URL/QDRANT_API_KEY is appended when the stack has none. 'none' keeps the stack's own qdrant.
  • subdir · string · optionnel
    Directory within the source that contains the compose file (if not at the root).
  • db_name · string · optionnel
    DB name for single_vm/managed (default 'app').
  • db_user · string · optionnel
    DB user for single_vm/managed (default 'appuser').
  • git_ref · string · optionnel
    git mode only: branch/tag/commit (default: the repo's default branch).
  • service · string · optionnel
    The compose SERVICE to expose at the public URL (informational; the exposed port is `port`).
  • approved · boolean · optionnel
    ONLY when send_signals said approval_required (this account approves before anything paid starts): true after the USER said yes to the plan and its cost in this conversation. Never set it yourself, and leave it out in every other case.
  • database · string · optionnel · compose | single_vm | managed
    DB mode: 'managed' = a SEPARATE managed Postgres/MySQL/MariaDB VM. THE STACK KEEPS ITS OWN SETTINGS: its own copy of the store (a service running that store's image) is replaced by a forwarder under the same name, the stack's own user, password and database are created on the managed store and its init scripts run once; a store the stack has no copy of gets DATABASE_URL/PG*/MYSQL_* appended to the project .env. 'compose' = the stack's own db service (without a signal the default; with one, only when the user asked for one VM); 'single_vm' = Postgres ON the app VM. Your compose file is never rewritten.
  • db_engine · string · optionnel · postgres | mysql | mariadb
    managed only: 'postgres' (default) → PG* env; 'mysql'/'mariadb' → MYSQL_* env. mysql/mariadb require database:'managed'.
  • flavor_id · string · optionnel
    App VM size - from list_flavors. A multi-container stack often wants m1.large+; plan_deploy sizes it.
  • git_token · string · optionnel
    git mode only: token to clone a PRIVATE repo.
  • data_paths · array · optionnel
    Directories a service WRITES its data to that the compose file's own volumes do not cover: 'service:/path', or '/path' for the exposed `service`. The data is kept on this machine, in named volumes (an override file adds them; your compose file is never rewritten), and survives every redeploy of the name, which runs on this same machine. The compose file's own volumes, and the VOLUMEs its images declare, are kept as they are and never removed: you need this only for a path no volume covers. At most 16; a path once kept stays kept. While the deployment keeps data, a deploy that would need a new machine is refused: another size, port, keypair, hostname or route, several exposed surfaces, a single_vm database, compose_engine podman, or a stopped machine (start it with instance_action). To start fresh, delete_deployment (it deletes the data). A VOLUME an image declares is kept even when it holds code (for example a WordPress image's /var/www/html), so a redeploy does not replace code baked under it.
  • db_version · string · optionnel
    DB version for single_vm/managed (Postgres '16'|'15'|'14'; MySQL '8.0'; MariaDB '11.4').
  • machine_id · integer · optionnel
    EXPERIMENT: the prepared machine to run this deploy on, from prepare_machine. Omit: the newest one this session has not used yet.
  • network_id · string · optionnel
    Private network id - auto-selected from check_deploy_prerequisites if omitted.
  • app_profile · string · optionnel · generic | wordpress | woocommerce
    Detected app profile from source inspection. For WordPress/WooCommerce pass wordpress/woocommerce so cluster deploys enforce managed DB + shared media instead of treating local uploads as stateless.
  • compose_file · string · optionnel
    Path within the source to the compose file (e.g. 'deploy/docker-compose.yml'). Auto-detected (docker-compose.yml / compose.yaml / …) if omitted.
  • db_flavor_id · string · optionnel
    managed only: the dedicated DB VM size (from list_flavors). Defaults to the app flavor.
  • db_superuser · boolean · optionnel
    single_vm/managed Postgres: grant the DB user SUPERUSER (dedicated DB VM, so safe).
  • keypair_name · string · requis
    REQUIRED. An EXISTING SSH keypair name - from list_keypairs / import_keypair.
  • source_token · string · optionnel
    UPLOAD MODE: token from prepare_upload - deploys an uploaded tarball of your LOCAL dir (no git). Omit `repo` when set.
  • db_extensions · array · optionnel
    single_vm/managed Postgres: extensions to pre-install (pgvector, postgis, pgaudit, …).
  • redis_version · string · optionnel · 7 | 6
    managed Redis only: version (default '7').
  • cluster_target · boolean · optionnel
    Set TRUE when the user asked to deploy this compose app as an autoscaling cluster. For WordPress/WooCommerce this requires managed MySQL/MariaDB plus media_space/central_media_origin.
  • compose_engine · string · optionnel · auto | docker | podman
    Container engine for the compose build (default: the server's choice, usually podman). Set 'docker' to force the docker engine.
  • media_space_id · integer · optionnel
    Existing Redu media space id to mount at WordPress wp-content/uploads. Get it from list_media_spaces.
  • redis_password · string · optionnel
    managed Redis only: a specific password to set (otherwise auto-generated).
  • idempotency_key · string · optionnel
  • migrate_command · string · optionnel
    One-time DB prepare/migrate/seed, run AFTER `up -d` and BEFORE the app is marked ready - redu runs `podman-compose run --rm <migrate_service|service> <cmd>` (Rails `bundle exec rails db:prepare`, Django `python manage.py migrate`, Prisma `prisma migrate deploy`). REQUIRED for any stack whose schema is NOT auto-created on boot (e.g. Lago): WITHOUT it the stack deploys and flips to 'ready' but 502s on real use because the DB schema is missing.
  • migrate_service · string · optionnel
    Compose service to run migrate_command in (defaults to `service`).
  • redis_flavor_id · string · optionnel
    managed Redis only: the dedicated Redis VM size (from list_flavors). Defaults to the app flavor.
  • media_mount_path · string · optionnel
    Host mount path on the app VM/member. Redu mounts this into /var/www/html/wp-content/uploads.
  • media_origin_url · string · optionnel
    Public base URL where WordPress wp-content/uploads is served when using central_media_origin. Do not put this on the DB VM.
  • media_space_name · string · optionnel
    Optional media space name when create_media_space:true. Defaults to <deployment-name>-media.
  • qdrant_flavor_id · string · optionnel
    managed Qdrant only: the Qdrant VM size (from list_flavors).
  • cluster_media_mode · string · optionnel · local_uploads | central_media_origin | media_space
    Record the WordPress media strategy for future clustering. For real WordPress clusters use media_space by default: Redu mounts a shared uploads filesystem into every member. local_uploads is single-VM only and upgrade_to_cluster will refuse it for WordPress.
  • create_media_space · boolean · optionnel
    For WordPress/WooCommerce cluster_target:true: set TRUE when no suitable media space exists. Redu creates an NFS media VM + persistent volume and mounts it into /var/www/html/wp-content/uploads.
  • media_space_size_gb · integer · optionnel
    Media space data volume size in GB when create_media_space:true (default 20).
  • security_group_names · array · optionnel
  • media_space_flavor_id · string · optionnel
    Flavor id for the media VM when create_media_space:true. Defaults to m1.small/backend default.

  Exemple d'appel

  {"name": "deploy_compose", "arguments": {"name": "texte", "keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• deploy_overview≈ 250 tokens

  Orientation for deploying an app on redu.cloud: the end-to-end flow, the two source modes (git vs upload), how to handle a missing Dockerfile or a database, when (and when NOT) to split a deploy across multiple VMs, verifying a deploy functionally, and how to debug a failed build. Call this first when a user asks to deploy/ship/host an app and you're unsure where to start.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "deploy_overview", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"flow": [], "next": "texte", "tips": [], "multi_vm": [], "source_modes": "texte"}}

• deploy_vpn≈ 736 tokens

  Stands up a redu VPN gateway (WireGuard tunnelled over wstunnel on WSS/443) on your PRIVATE network, so you (or your team) can reach the private IPs of the VMs you deployed on redu, over a single https endpoint - no UDP, no extra ports. This is the TENANT VPN for reaching your OWN deployed resources; it is NOT a general internet VPN. GUARDRAIL: the first call does NOT deploy - it returns the plan + hourly cost for approval, because it creates a BILLED VM. Show the user, get their explicit 'go', then call again with confirm:true (required even in yolo mode). The gateway asset is redu's, deployed onto YOUR VM (you can SSH in to read it). Fresh WireGuard keys are generated per deploy; the client PRIVATE key is returned ONCE and is never stored server-side.

  Paramètres, retour & exemple (6)

  Paramètres

  • name · string · optionnel
    Deployment name (default auto 'vpn-<id>'). Becomes the VM name + the wss://<name>.redu.cloud endpoint.
  • confirm · boolean · optionnel
    Set true ONLY after the user has explicitly approved (the first call returns the plan + cost). Do NOT set it yourself.
  • flavor_id · string · optionnel
    Gateway VM size (from list_flavors). The gateway is light; m1.small ('2') is plenty.
  • network_id · string · optionnel
    Private network id (from list_networks). Auto-selected from your default private network if omitted - the VMs you want to reach must be on this network.
  • client_cidr · string · optionnel
    Your tenant PRIVATE-network CIDR (e.g. '10.1.0.0/24') so the client routes it through the tunnel. If omitted, the returned client config only routes the tunnel subnet and you add your CIDR to AllowedIPs yourself.
  • keypair_name · string · requis
    REQUIRED. An EXISTING SSH keypair name (from list_keypairs / import_keypair) for the gateway VM.

  Exemple d'appel

  {"name": "deploy_vpn", "arguments": {"keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "warning": "texte", "deployment": "texte", "validation": "texte", "access_point": "texte", "client_config": "texte", "client_launch": [], "billing_notice": "texte", "server_public_key": "texte", "needs_confirmation": true}}

• detach_volume≈ 461 tokens

  Detaches a block volume from an instance, leaving the volume (and its data) intact and 'available' to attach elsewhere. Unmount it INSIDE the guest first (`umount /mnt/...`) or you risk a dirty filesystem. You cannot detach an instance's ROOT/boot disk while it runs. Use this to move a data volume to another VM, or to free a restore target before restore_backup writes into it. Poll list_volumes until status is 'available'.

  Paramètres, retour & exemple (2)

  Paramètres

  • volume_id · string · requis
    Volume to attach/detach - from list_volumes (id). For a recovery, this is the volume restore_backup created (restore_backup with volumeName makes a NEW volume from a backup).
  • instance_id · string · requis
    Instance to attach it to / detach it from - from list_instances (id).

  Exemple d'appel

  {"name": "detach_volume", "arguments": {"volume_id": "texte", "instance_id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• get_agent_status≈ 247 tokens

  Returns the current status of your controller VM. On a freshly set-up VM also returns the trigger token needed to authorize the fleet and to call trigger_agent_batch. Call this after setup_agent_fleet to confirm the VM is ready.

  Paramètres, retour & exemple (2)

  Paramètres

  • log_token · string · optionnel
    Log token for fetching controller logs (optional - returned by this tool on first call)
  • controller_url · string · requis
    HTTPS URL of your controller VM, e.g. https://redu-controller-abc123.redu.cloud

  Exemple d'appel

  {"name": "get_agent_status", "arguments": {"controller_url": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"status": "texte"}}

• get_container_logs≈ 545 tokens

  THE APPLICATION'S OWN LOGS - what `docker logs`/`podman logs` would show for each container in a deployment. This is the tool for 'it deployed fine but it does not work': a 500, a crash loop, a failed DB connection, a missing env var all announce themselves here and NOWHERE else. ⛔ DO NOT use get_instance_logs for this. That returns the VM's SERIAL CONSOLE (kernel messages and cloud-init), which answers a question nobody debugging an app has - and on this platform it goes permanently silent once the machine finishes booting. build_log does not contain runtime output either; it stops when the build does. Default depth answers instantly from the VM's last report; a bigger `tail` or any `since` asks the VM for a fresh pull and takes up to ~15s. Secret-shaped values (PASSWORD=, TOKEN=, API_KEY=) are redacted in transit.

  Paramètres, retour & exemple (4)

  Paramètres

  • tail · integer · optionnel
    Lines per container (default 120). Over 120 asks the VM for a fresh pull, which takes up to ~15s.
  • since · string · optionnel
    Only logs newer than this, e.g. '30m', '2h', '7d'. Always triggers a fresh pull from the VM.
  • service · string · optionnel
    Container/service name (substring matches). Omit for every container the VM reports. Get exact names from get_containers.
  • deployment_id · string · requis
    A deployment's id, name, or instance_id - all three resolve.

  Exemple d'appel

  {"name": "get_container_logs", "arguments": {"deployment_id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"hint": "texte", "logs": "texte", "reason": "texte", "source": "texte", "message": "texte", "measured": true, "age_seconds": 1, "available_services": "texte"}}

• get_containers≈ 455 tokens

  WHAT IS ACTUALLY RUNNING on a deployment's VM: every container's name, image, state, health, restart count, exit code and published ports - including the ones that have CRASHED, which are the ones you need. Use this the moment a deployment says 'ready' but the URL misbehaves, and before you reach for SSH. get_deployment returns the deployment ROW (status, URL, build log); it cannot see inside the VM, so a stack where one of five services is restarting looks identical to a healthy one there. This is that missing view. It answers from the VM's own report (every 15s), so it costs no SSH round trip. If the VM has never reported, it SAYS SO rather than returning an empty list - 'no containers' and 'I cannot see' are different answers and only one of them means your app is broken. ⚠️ For a deployment that has been turned into a CLUSTER, this describes the original source VM only; autoscaled members are deliberately silent, so use list_clusters for member-level state.

  Paramètres, retour & exemple (1)

  Paramètres

  • deployment_id · string · requis
    A deployment's id, name, or instance_id - all three resolve.

  Exemple d'appel

  {"name": "get_containers", "arguments": {"deployment_id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"hint": "texte", "stale": true, "engine": "texte", "reason": "texte", "message": "texte", "measured": true, "containers": "texte", "deployment": "texte", "age_seconds": 1}}

• get_deployment≈ 826 tokens

  Fetches ONE deployment by its numeric id (from list_deployments). Returns its current status, the public access_point URL, the underlying VM id, AND the build_log - IN FULL when status is 'build_failed' or 'error', which is when it is the diagnosis and you should read it; otherwise the LAST 40 LINES only, with build_log_truncated:true and build_log_total_lines so you can tell a short build from a shortened log. A ready deployment's log is not worth the tokens and used to make this response exceed the caller's output limit. Also returns a reality report_markdown showing the REAL provisioned size + cost (the plan was only an estimate; the user may have up-sized).

  Paramètres, retour & exemple (2)

  Paramètres

  • id · integer · requis
    Deployment id from list_deployments.
  • redu_md · string · optionnel
    ⭐ USUALLY UNNECESSARY NOW: if you POST your current redu.md to the `redu_md_post_url` this tool returns (`curl -fsS --data-binary @redu.md <url>`), redu merges against that and you never paste the file at all - it is 20-29 KB and every byte costs you output. Use this parameter only when you cannot run that command. PASTE the raw contents of the repo's existing `redu.md` if it has one (`cat redu.md`). redu MERGES it server-side - recorded quirks, the pinned dname and the deploy log are carried forward - and returns the COMPLETE new file in redu_md_markdown, which you write out whole. Do NOT merge it yourself. If you OMIT this, redu returns NO redu_md_markdown at all - only redu_md_bootstrap_markdown (for a repo with no redu.md yet) and redu_md_deploy_log_line (to hand-append) - so a forgotten pass can no longer overwrite a repo's accumulated memory. If redu cannot merge what you passed it sets redu_md_merge_blocked and returns NO redu_md_markdown, precisely so there is nothing to overwrite the file with - in that case follow `next` and hand-edit the existing file instead of replacing it.

  Exemple d'appel

  {"name": "get_deployment", "arguments": {"id": 1}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "build_log": "texte", "deployment": "texte", "report_markdown": "texte", "failure_analysis": "texte", "redu_md_filename": "texte", "redu_md_markdown": "texte", "redu_md_post_url": "texte", "redu_md_merge_lost": [], "redu_md_merge_mode": "full", "redu_md_merged_url": "texte"}}

• get_domain_verification≈ 343 tokens

  Starts (or resumes) a claim on a custom domain and returns the DNS TXT record that proves it is the user's: they add it at the domain's DNS provider, then you call verify_domain. Until it verifies, list_domains shows the domain as pending. 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. A name under redu.cloud needs no verification.

  Paramètres, retour & exemple (1)

  Paramètres

  • domain · string · requis
    The custom domain to verify ownership of (e.g. app.example.com).

  Exemple d'appel

  {"name": "get_domain_verification", "arguments": {"domain": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "domain": "texte", "record_name": "texte", "record_type": "texte", "record_value": "texte"}}

• get_env_keys≈ 390 tokens

  WHICH ENVIRONMENT VARIABLES the deployment was actually given, BY NAME - the keys in the env files on the VM (/opt/app-src/.env and friends), never the values. Most of the time the real question is 'did DATABASE_URL get wired, or is the app reading a name I did not set', and the name answers it: you can confirm the DB was connected, spot a typo'd key, and see which of the app's documented variables are missing, without touching a secret. ⛔ VALUES ARE NOT AVAILABLE HERE AND WILL NOT BE. They never leave the VM. If you genuinely need one (a generated admin password, say), SSH in with get_ssh_command and read that single key: `sudo grep '^KEY=' /opt/app-src/.env`. The file is chmod 600 root:root, so it needs sudo. Also reports each file's permission mode, which is how you catch a world-readable env file.

  Paramètres, retour & exemple (1)

  Paramètres

  • deployment_id · string · requis
    A deployment's id, name, or instance_id - all three resolve.

  Exemple d'appel

  {"name": "get_env_keys", "arguments": {"deployment_id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"reason": "texte", "message": "texte", "measured": true, "env_files": "texte", "age_seconds": 1}}

• get_instance_logs≈ 297 tokens

  The VM's SERIAL CONSOLE: kernel messages and early-boot/cloud-init output. ⛔ THIS IS NOT YOUR APPLICATION'S LOGS. For a deployed app - a crash loop, a 500, a failed DB connection - use get_container_logs, which returns what the containers actually printed. Reach for this one only for boot-level questions: the machine never came up, the disk did not mount, cloud-init failed before the app existed. Note that on this platform the console goes silent once a machine is past early boot, so an empty result here says nothing about a running VM.

  Paramètres, retour & exemple (1)

  Paramètres

  • instance_id · string · requis
    ID of the instance to fetch BOOT/console logs for. For app logs use get_container_logs instead.

  Exemple d'appel

  {"name": "get_instance_logs", "arguments": {"instance_id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"logs": "texte", "mode": "texte"}}

• get_resource_usage≈ 369 tokens

  HOW MUCH ROOM IS LEFT on a deployment's VM: total/used/available memory, swap, disk free, load average, CPU count, and OOM kills in the last 24h - plus per-container memory and CPU. Use it to answer 'is this flavor big enough', to size the NEXT deploy of the same app honestly instead of guessing, and to explain a container that keeps dying (an OOM kill leaves no application log at all - the process is shot, so the only trace is the kernel's, and that is why oom_kills_24h is here). A full disk presents as a dozen unrelated failures and is the first thing to rule out. Every one of 34 measured deploy runs got these numbers by SSHing in and running free/df/docker stats; this is the same data with no round trip.

  Paramètres, retour & exemple (1)

  Paramètres

  • deployment_id · string · requis
    A deployment's id, name, or instance_id - all three resolve.

  Exemple d'appel

  {"name": "get_resource_usage", "arguments": {"deployment_id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"host": "texte", "reason": "texte", "message": "texte", "measured": true, "containers": "texte", "age_seconds": 1}}

• get_ssh_command≈ 590 tokens

  Returns the SSH command to connect to an instance via the redu.cloud TCP proxy. ACCEPTS an instance id, a deployment's id / name / instance_id, OR a MANAGED DATASTORE's id / name / instance_id (Postgres, MySQL/MariaDB, ClickHouse, Redis) - it resolves all of them, so you do not have to work out which one you are holding (a deployment's instance_id is a placeholder until provisioning finishes, and passing it used to fail). ⭐ SSH TO THE DATASTORE VM IS HOW YOU REACH A PRIVATE-NETWORK-ONLY DATABASE BEFORE ANY APP VM EXISTS: the datastore's own VM is SSH-reachable and ships the client on PATH (psql at /usr/bin/psql), so you can apply a schema or rotate a seeded admin account without an app VM to tunnel through. For a DEPLOYMENT VM (created by deploy_app/deploy_compose) pass keypair_name - read it from get_deployment - so the command uses `-i ~/.ssh/<keypair_name>` and authenticates with the RIGHT key instead of your default identity (without it, SSH to a deploy VM usually fails). The tool also best-effort looks up the keypair from the deployment if you omit it. Example: ssh -i ~/.ssh/redu-deploy -o IdentitiesOnly=yes -p 22011 ubuntu@myinstance-abc12345.redu.cloud

  Paramètres, retour & exemple (2)

  Paramètres

  • instance_id · string · requis
    An instance id, a deployment's id / name / instance_id, or a managed datastore's id / name / instance_id. All are resolved.
  • keypair_name · string · optionnel
    The SSH keypair the instance was created with (read it from get_deployment for a deploy VM). When given, the command uses `-i ~/.ssh/<keypair_name>` so it authenticates with the right key.

  Exemple d'appel

  {"name": "get_ssh_command", "arguments": {"instance_id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"host": "texte", "mode": "texte", "port": "texte", "user": "texte", "floating_ip": "texte", "ssh_command": "texte", "keypair_name": "texte", "instance_name": "texte", "instance_status": "texte"}}

• import_keypair≈ 372 tokens

  Registers an existing SSH public key on your account. Use this to import your own public key so you can SSH into instances. The private key never leaves your machine.

  Paramètres, retour & exemple (2)

  Paramètres

  • name · string · requis
    Name for the keypair (e.g. 'my-laptop'). Must be unique on your account.
  • public_key · string · requis
    SSH public key to import (the contents of your id_rsa.pub or id_ed25519.pub).

  Exemple d'appel

  {"name": "import_keypair", "arguments": {"name": "texte", "public_key": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• instance_action≈ 318 tokens

  Start, stop, or reboot an instance. action must be START, STOP, REBOOT_SOFT, or REBOOT_HARD.

  Paramètres, retour & exemple (2)

  Paramètres

  • action · string · requis · START | STOP | REBOOT_SOFT | REBOOT_HARD
  • instanceId · string · requis

  Exemple d'appel

  {"name": "instance_action", "arguments": {"action": "START", "instanceId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• integrate_overview≈ 260 tokens

  Orientation for wiring a redu.cloud capability (backups, DNS, extra storage, a managed DB, ...) INTO an app already deployed on redu, e.g. 'add a backup feature to the Supabase I deployed on redu'. Explains the pattern: mint a LEAST-PRIVILEGE scoped API key (with the user's approval via create_api_key), inject it into the app, and call the redu API from the app. Call this when a user asks to add/integrate a redu feature into a running deployment and you are unsure how.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "integrate_overview", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"next": "texte", "pattern": [], "recipes": "texte", "scopes_hint": "texte"}}

• list_api_keys≈ 178 tokens

  Lists the account's API keys: id, name, scopes, when each was created and last used, and when it expires. Never the secret (redu keeps only a hash). Use it to find a key to delete with delete_api_key, or to check what keys exist before minting another.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_api_keys", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"keys": [], "error": true}}

• list_backups≈ 137 tokens

  Lists your volume backups.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_backups", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "backups": []}}

• list_clickhouse_databases≈ 197 tokens

  Lists your managed ClickHouse databases (OLAP / analytics - its own resource, not a relational DB). Once a row's status is 'ready' it carries the private-network connection details (private_ip, ClickHouse HTTP port 8123, db_name, db_user).

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_clickhouse_databases", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "clickhouse": []}}

• list_clusters≈ 140 tokens

  Lists your autoscaling clusters.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_clusters", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "clusters": []}}

• list_databases≈ 175 tokens

  Lists your managed PostgreSQL databases. Once a row's status is 'ready', it carries the private-network connection details (private_ip, port 5432, db_name, db_user).

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_databases", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "databases": []}}

• list_deployments≈ 196 tokens

  Lists your app deployments. Each row carries status (provisioning/ready/build_failed/error), the current build phase while provisioning (installing/source/building/built/starting), the public access_point URL, port, repo, and build_log on failure.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_deployments", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "deployments": []}}

• list_dns_entries≈ 176 tokens

  Lists the public names (DNS entries) on this account: each entry's id, the names it serves (domain_names) and the address it forwards to. delete_dns_entry removes one by its id.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_dns_entries", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"dns": [], "mode": "texte", "next": "texte"}}

• list_domains≈ 233 tokens

  Lists the custom domains on this account with their status: verified (it can be bound with dname on deploy_app/deploy_compose, dns_entries on create_instance, or set_cluster_domain) or pending (its TXT check has not passed: get_domain_verification gives the record, verify_domain checks it). The public names that use a domain are in list_dns_entries. release_domain removes a domain from the account.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_domains", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "domains": []}}

• list_flavors≈ 138 tokens

  Lists available instance sizes.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_flavors", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "flavors": []}}

• list_images≈ 136 tokens

  Lists available OS images.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_images", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "images": []}}

• list_instances≈ 140 tokens

  Lists your compute instances.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_instances", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "instances": []}}

• list_keypairs≈ 153 tokens

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

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_keypairs", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "keypairs": []}}

• list_media_spaces≈ 204 tokens

  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.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_media_spaces", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "media_spaces": []}}

• list_private_networks≈ 142 tokens

  Lists your private networks.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_private_networks", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "networks": []}}

• list_qdrant≈ 181 tokens

  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.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_qdrant", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "qdrant": []}}

• list_redis≈ 195 tokens

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

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_redis", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "redis": []}}

• list_regions≈ 137 tokens

  Lists available regions.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_regions", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "regions": []}}

• list_relational_databases≈ 200 tokens

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

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_relational_databases", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "relational_databases": []}}

• list_security_groups≈ 144 tokens

  Lists your security groups.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_security_groups", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "security_groups": []}}

• list_snapshots≈ 140 tokens

  Lists your instance snapshots.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_snapshots", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "snapshots": []}}

• list_volumes≈ 139 tokens

  Lists your block storage volumes.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_volumes", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "volumes": []}}

• plan_deploy≈ 4421 tokens

  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; unlike Postgres and Redis it is not auto-wired by deploy_app, so the plan tells you to run plan_managed_datastore engine:'clickhouse' -> create_clickhouse and pass CLICKHOUSE_* env yourself. A Qdrant vector DB is managed like the other datastores (vector_engines in send_signals; qdrant:'managed' without a signal); pgvector lives in the managed Postgres. In a session with send_signals the platform sizes every machine by measurement, so heavy_build, memory_heavy and needs_compose change no size there. Any containerizable app works (node, python, go, ...) - it deploys as a container, so the language doesn't gate it. Set serves_http:false for a non-web repo (a library, CLI, or language runtime with no HTTP server) and it returns a clean not-a-web-service verdict instead of a costed VM plan. Set heavy_build:true for resource-heavy builds (compiled-from-source native code, a monorepo/turborepo build, a large Node heap) and it raises the app VM to a build-capable floor so the on-VM build doesn't get OOM-killed. Set memory_heavy:true for a RAM-forward app whose persistent state lives in a MANAGED DB / external store (Next.js like cal.com/cal.diy, Rails, Django, JVM/Java apps) - it sizes onto a memory-optimized SMALL-DISK flavor (m1.mem16/m1.mem32: full RAM, a lean 40 GB disk instead of 160 GB) that costs less and snapshots/clusters far faster; do NOT set it if the app keeps lots of data on local disk. Also returns a brand-named markdown report (Mermaid diagram + cost) to SHOW the user only in guided mode; write no file from it. Every deploy leaves TWO MANDATORY files at the repo root with DIFFERENT purposes, both written ONCE at the end from the deployment that actually ran (get_deployment), after you verified it works: redu-deploy-plan.md = what this run deployed, and redu.md = the DURABLE deploy memory the NEXT deploy reads. If a redu.md exists, READ it FIRST and reuse its known-good plan + recorded fixes; if NONE exists, one MUST be created at the end of the deploy (get_deployment returns redu_md_bootstrap_markdown for exactly that case; when a redu.md DOES exist, pass it as redu_md and write the merged redu_md_markdown). They are SEPARATE files - even if your own memory/notes from a prior deploy call redu-deploy-plan.md 'the record', the durable record is redu.md, so do not skip creating it. ROUTE: from a source_token (pass port too: it tells the platform which compose service is the app) the plan can also carry recommended_route:'compose', the platform's route for that folder, with every recommended_* and route_* field it sent (recommended_compose_file, recommended_service, recommended_port, recommended_image, route_reason, route_next): then deploy that compose file with deploy_compose (compose_file), with recommended_service as service and recommended_port as port (the HOST port the app service publishes, not the port the app listens on inside its container), not deploy_app, unless route_next's conditions for building the Dockerfile with deploy_app hold.

  Paramètres, retour & exemple (34)

  Paramètres

  • port · integer · optionnel
    Port the app's HTTP server listens on (PORT env / framework default / Dockerfile EXPOSE of a real app port - NOT a debug/IPC port). Omit if the repo has no HTTP server.
  • start · string · optionnel
    How the app starts (package.json start script / Procfile / Dockerfile CMD).
  • worker · boolean · optionnel
    HEADLESS WORKER / daemon: the repo runs a long-lived process with NO HTTP server (a chaos-monkey, a background/queue worker, an on-infra agent runner). Set TRUE to plan a WORKER deploy - a private VM with SSH access but NO public URL and NO health probe. serves_http/port are then not required (a serves_http:false repo is NOT rejected). Deploy it with deploy_app worker:true.
  • redu_md · string · optionnel
    PASTE the raw contents of `redu.md` from the repo root if the file exists (just `cat redu.md`). ⚠️ Only needed when you have NO source_token (a git-mode deploy): with a token, redu reads this file out of your upload and pasting it wastes 20-29 KB of output. You do NOT need to read or interpret it - redu parses it server-side and returns only a short digest. This is how a REDEPLOY keeps the SAME public URL and reuses the recorded fixes instead of rediscovering them.
  • runtime · string · requis
    Detected app language/runtime (node, python, go, ruby, ...). Informational - the app deploys as a container, so the language does not gate the deploy.
  • vm_count · integer · optionnel
    Number of app VMs (microservices). v1: usually 1.
  • db_engine · string · optionnel · postgres | mysql | mariadb
    Managed DB engine to plan. For WordPress/WooCommerce clusters use mariadb or mysql.
  • db_flavor · string · optionnel
    Preferred managed Postgres VM size (default m1.small). Resolved against the real flavor list.
  • single_vm · boolean · optionnel
    Force everything onto a single VM if the user prefers.
  • app_flavor · string · optionnel
    Preferred app VM size (default m1.medium). Resolved against the real flavor list.
  • dockerfile · string · optionnel
    PASTE the raw contents of the repo's Dockerfile if it has one. redu scans it server-side for BuildKit heredocs, empty `EXPOSE ${ARG}`, and source-build fetches (go/cargo/npm/pip/apt) that are known to fail, and returns preemptive fixes.
  • app_profile · string · optionnel · generic | wordpress | woocommerce
    Detected app profile. Set wordpress/woocommerce when source inspection finds wp-config.php, wp-content, WordPress/WooCommerce packages/plugins, or wordpress/woocommerce compose images. This is used for cluster safety.
  • deploy_mode · string · optionnel · guided | yolo
    OMIT by default: deploy end to end with no questions asked. 'guided' ONLY when the user explicitly said they want to approve or to be specific about something: the user approves the plan, then you proceed with its defaults. Sticky for the session once set here or via check_deploy_prerequisites.
  • heavy_build · boolean · optionnel
    Set TRUE when the BUILD (not the running app) is resource-heavy - the container is built ON the VM today, so a build that needs more RAM/CPU than the idle app must be sized up or it OOMs mid-build. Signals: compiled-from-source native code (Rust/C++/CGO/Go-from-source), a monorepo/turborepo build, a Node build with a large heap (NODE_OPTIONS=--max-old-space-size), or bundling Chromium. When true, the plan raises the app VM to a build-capable floor (≥ m1.large) so `deploy_app`'s on-VM build doesn't get OOM-killed. The default m1.medium (4 GB) builds light apps fine but OOMs heavy ones.
  • needs_redis · boolean · optionnel
    App uses Redis (deps redis/ioredis/bullmq/celery or REDIS_URL).
  • serves_http · boolean · optionnel
    Whether the repo actually RUNS an HTTP server that listens on a port. Set FALSE for a library, CLI tool, or language runtime that has no web server (e.g. a package you `import`, or a `bun`/`node`-style runtime) - redu can only deploy web services, so a non-server repo is reported as not-a-web-service instead of being costed. Note: an `EXPOSE` of a debug/IPC port (Chrome DevTools 9222/9242, metrics) is NOT an HTTP listener - set false. Leave unset only if you're confident it serves HTTP.
  • compose_yaml · string · optionnel
    PASTE the raw contents of the repo's docker-compose.yml / compose.yaml if it has one. redu scans it server-side for known deploy-breaking patterns (Docker-only `local` log driver, depends_on:service_healthy, profiles:, image+build, service count) and returns preemptive fixes BEFORE anything is provisioned. Costs you nothing to include; prevents whole classes of first-deploy failure.
  • memory_heavy · boolean · optionnel
    Set TRUE for a RAM-forward RUNNING app whose persistent state lives in a MANAGED DB / external store (NOT on the VM's local disk) - so it needs lots of memory but only a lean disk. Sizes onto a memory-optimized SMALL-DISK flavor (m1.mem16 = 4 vCPU / 16 GB / 40 GB; pass app_flavor:'m1.mem32' for 32 GB): the SAME RAM as the big standard flavors but a 40 GB disk instead of 160 GB - so it costs less AND snapshots/clusters FAR faster (a 40 GB snapshot is ~a third the time of 160 GB), which matters a lot if you'll scale the app into a cluster. Signals: heavy web frameworks (Next.js - e.g. cal.com / cal.diy - Rails, Django), JVM/Java apps, apps running several in-process services, or anything holding large working sets in memory, AND it uses managed Postgres/MySQL (needs_postgres with single_vm:false) or an external DB so the VM disk is just the app image. Do NOT set it if the app stores lots of data on LOCAL disk (user uploads, an on-VM database, large on-disk caches) - that needs a bigger standard-flavor disk. Distinct from heavy_build (BUILD-time RAM); mem16's 16 GB also covers most heavy builds, so the two compose.
  • source_token · string · optionnel
    The `source_token` returned by your prepare_upload upload. ⚡ PREFER THIS over pasting: redu reads redu.md, the compose file and the Dockerfile straight out of the upload you ALREADY made, so you do not have to emit a 20-29 KB file as tool input. Run prepare_upload FIRST, then pass the token here. The upload is NOT consumed by this: it stays deployable. Anything you also paste below wins over what is read from the upload.
  • has_container · boolean · optionnel
    Whether the repo already has a Dockerfile / compose file.
  • needs_compose · boolean · optionnel
    Set TRUE when the repo ships a docker-compose.yml / compose.yaml that runs MULTIPLE services (app + its own db/redis/worker containers) as a stack - then deploy with deploy_compose (podman-compose on ONE VM), NOT deploy_app. A single-service compose that just wraps one Dockerfile can still use deploy_app. plan_deploy raises the app VM to a build-capable floor since a multi-container stack needs more RAM.
  • cluster_target · boolean · optionnel
    Set TRUE when the user asked to deploy this app as an autoscaling cluster. For WordPress/WooCommerce this requires managed MySQL/MariaDB plus a Redu media space mounted at wp-content/uploads (or an explicitly configured central_media_origin); local uploads are unsafe.
  • media_space_id · integer · optionnel
    Existing Redu media space id to reuse for WordPress/WooCommerce cluster uploads. Get it from list_media_spaces. Omit when create_media_space:true.
  • needs_postgres · boolean · optionnel
    App uses Postgres (deps pg/prisma/sqlalchemy/drizzle or DATABASE_URL).
  • containerizable · boolean · optionnel
    Whether the app can run in a container. Almost always true (a container is the delivery unit); set false ONLY if the app fundamentally can't be containerized - then redu can't deploy it yet.
  • needs_vector_db · boolean · optionnel
    App uses a vector DB (deps qdrant-client / langchain+embeddings or QDRANT_URL).
  • media_mount_path · string · optionnel
    Host mount path on app members for the shared uploads filesystem. Redu mounts this into /var/www/html/wp-content/uploads.
  • media_origin_url · string · optionnel
    Public base URL where WordPress wp-content/uploads is served when cluster_media_mode:'central_media_origin'. Do not use the DB VM as this origin.
  • needs_clickhouse · boolean · optionnel
    App uses ClickHouse: the ANALYTICS / EVENTS store, a separate tier from the app's Postgres/MySQL. Set TRUE on ANY signal: a clickhouse/clickhouse-server image in the compose, a CLICKHOUSE_* / CLICKHOUSE_URL / CH_ env var, a clickhouse client dep (clickhouse-connect, @clickhouse/client, clickhouse-driver, clickhouse-go), or an `ON CLUSTER` / MergeTree migration. Analytics-shaped products (Plausible, PostHog, Langfuse, Matomo, SigNoz) run BOTH a relational DB for config AND ClickHouse for every event, so needs_postgres and needs_clickhouse are usually both true. Leaving it false when the app needs it under-quotes the user by a WHOLE datastore: measured 2026-08-07 on an analytics app, GBP 53.29/mo quoted against GBP 65.99/mo real, because the events tier was simply absent from the plan.
  • clickhouse_flavor · string · optionnel
    Preferred managed ClickHouse VM size (default m1.medium, a tier above the other datastores, which is what plan_managed_datastore also picks for ClickHouse). Resolved against the real flavor list.
  • cluster_media_mode · string · optionnel · local_uploads | central_media_origin | media_space
    For WordPress/WooCommerce cluster_target:true, use media_space as the default real fix: Redu creates/reuses an NFS media VM backed by a volume and mounts it at wp-content/uploads. central_media_origin is only for an already-configured external origin. local_uploads is refused at cluster time.
  • create_media_space · boolean · optionnel
    For WordPress/WooCommerce cluster_target:true: set TRUE when no suitable media space exists. The plan will include a small media VM + attached volume and deploy_app/deploy_compose will create it.
  • media_space_flavor · string · optionnel
    Preferred media VM size when create_media_space:true. Resolved against list_flavors.
  • media_space_size_gb · integer · optionnel
    Size of the media space data volume in GB when create_media_space:true.

  Exemple d'appel

  {"name": "plan_deploy", "arguments": {"runtime": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "plan": "texte", "reason": "texte", "feasible": true, "pin_dname": "texte", "preflight": [], "deployable": true, "route_next": "texte", "memory_used": true, "route_reason": "texte", "memory_digest": "texte"}}

• plan_instance≈ 210 tokens

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

  Paramètres, retour & exemple (2)

  Paramètres

  • osHint · string · optionnel
  • sizeHint · string · optionnel · small | medium | large

  Exemple d'appel

  {"name": "plan_instance", "arguments": {"osHint": "texte", "sizeHint": "small"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "options": "texte"}}

• plan_managed_datastore≈ 508 tokens

  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.

  Paramètres, retour & exemple (3)

  Paramètres

  • ha · boolean · optionnel
    Plan a highly available datastore (three machines on three different physical hosts behind a load balancer, surviving the loss of a machine with no manual failover) instead of the default single machine. Set it when the user has said they need to survive a machine failure. It prices at roughly 3x the single-machine hourly rate because it runs three machines, so the plan you show the user must carry that number. Available for postgres and clickhouse; for the other engines the plan comes back single-machine with a note saying so.
  • engine · string · optionnel · postgres | mysql | mariadb | redis | clickhouse | qdrant
  • sizeHint · string · optionnel · small | medium | large

  Exemple d'appel

  {"name": "plan_managed_datastore", "arguments": {"ha": true, "engine": "postgres", "sizeHint": "small"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "notes": [], "options": "texte", "suggested": "texte"}}

• prepare_upload≈ 414 tokens

  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.

  Paramètres, retour & exemple (2)

  Paramètres

  • is_git_repo · boolean · optionnel
    If the dir is a git checkout, set true to honor .gitignore (tracked files plus untracked, non-ignored ones). Either way a TRACKED file is never dropped, also one under vendor/, dist/, build/ or target/.
  • project_dir · string · optionnel
    Path to the local app directory to upload (default current dir).

  Exemple d'appel

  {"name": "prepare_upload", "arguments": {"is_git_repo": true, "project_dir": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"next": "texte", "commands": [], "endpoint": "texte", "excludes": []}}

• release_domain≈ 447 tokens

  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.

  Paramètres, retour & exemple (2)

  Paramètres

  • domain · string · requis
    The custom domain to release, as list_domains shows it.
  • confirm · boolean · optionnel
    Set true ONLY after the user has explicitly approved releasing this domain (see the confirmation the first call returns). Do NOT set it yourself.

  Exemple d'appel

  {"name": "release_domain", "arguments": {"domain": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "claim": "texte", "error": true, "names": [], "domain": "texte", "matches": [], "released": true, "validation": "texte", "needs_confirmation": true}}

• restore_backup≈ 563 tokens

  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.

  Paramètres, retour & exemple (4)

  Paramètres

  • backupId · string · requis
    ID of the backup to restore (see list_backups).
  • volumeId · string · optionnel
    Optional: restore into this existing volume.
  • instanceId · string · optionnel
    Optional: restore into this instance's volume (resolved automatically). The target volume must be available (detached), so stop the instance first.
  • volumeName · string · optionnel
    Optional: name for a new volume to restore into. Omit volumeId and instanceId to restore into a new volume.

  Exemple d'appel

  {"name": "restore_backup", "arguments": {"backupId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• scaffold_local≈ 410 tokens

  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.

  Paramètres, retour & exemple (4)

  Paramètres

  • port · integer · optionnel
    Port the app listens on.
  • runtime · string · requis
    App runtime (node/python/go/…) - from plan_deploy.
  • has_container · boolean · optionnel
    Repo already has a Dockerfile/Containerfile (the compose builds it). If false, write the plan_deploy-generated Dockerfile to ./Dockerfile first.
  • needs_postgres · boolean · optionnel
    Include a local Postgres container + wire PG* env.

  Exemple d'appel

  {"name": "scaffold_local", "arguments": {"runtime": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"next": "texte", "files": "texte", "caveats": [], "commands": []}}

• select_surface≈ 814 tokens

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

  Paramètres, retour & exemple (2)

  Paramètres

  • mode · string · optionnel · guided | yolo
    Drive mode; omit to use the session's sticky mode.
  • surfaces · array · requis
    EVERY runnable surface you found (run `find . -name Dockerfile -o -name Containerfile`, open each). Be exhaustive - a missed browser-desktop subdir is the #1 cause of a wrong pick.

  Exemple d'appel

  {"name": "select_surface", "arguments": {"surfaces": []}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "chosen": "texte", "ranked": []}}

• set_cluster_domain≈ 823 tokens

  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.

  Paramètres, retour & exemple (3)

  Paramètres

  • domain · string · requis
    The hostname to bind. Either your OWN production domain (e.g. shop.acme.com) - which must be verified FIRST, see the tool description - or a .redu.cloud label. A .redu.cloud value is NOT taken literally: it keeps a short-id suffix, so read the bound name from `access_point` in the response instead of assuming you got what you asked for.
  • stack_id · string · requis
    Cluster id, from list_clusters (the row's `id`).
  • stack_name · string · requis
    Cluster stack name, from list_clusters (stack_name).

  Exemple d'appel

  {"name": "set_cluster_domain", "arguments": {"domain": "texte", "stack_id": "texte", "stack_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "domain": "texte", "result": "texte", "validation": "texte", "access_point": "texte", "matched_request": true, "requested_domain": "texte"}}

• set_managed_backups≈ 523 tokens

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

  Paramètres, retour & exemple (4)

  Paramètres

  • id · ? · requis
    Numeric id of the managed service (from list_databases / list_redis / list_relational_databases / etc.).
  • enabled · boolean · requis
    true = turn ON nightly AUTOMATED backups for this service; false = turn them off.
  • service · string · requis · postgres | mysql | mariadb | redis | qdrant | clickhouse
    Which managed data-service type the id belongs to. A managed Postgres from create_database/list_databases is 'postgres'; MySQL/MariaDB from create_relational_database; plus redis/qdrant/clickhouse.
  • retention · integer · optionnel
    How many days of nightly backups to keep (optional; keeps the current setting if omitted).

  Exemple d'appel

  {"name": "set_managed_backups", "arguments": {"id": "texte", "enabled": true, "service": "postgres"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte"}}

• setup_agent_fleet≈ 819 tokens

  Complete one-shot setup: validates prerequisites, creates a controller VM + worker VMs, auto-creates a public HTTPS URL on port 7070, seeds a starter ROADMAP.md into the repo if absent, and returns the trigger token. Call this when a user says 'set up autocoding agents for my repo' or 'I want agents to work on my codebase'. HOW THE AGENT WORKS: each worker runs Claude Code inside the repo, implements one task, runs the test suite, and opens a pull request. It excels at focused, single-PR, testable units of work - add an endpoint, write tests for a module, fix a specific bug, add a UI page - and is poor at vague/large tasks, design decisions, or anything needing external credentials. TASK FORMAT (strict, one line each): `- [ ] **Title** - short description *(agent-ready)*` - the `- [ ]` checkbox, `**bold title**`, ` - ` separator, and `*(agent-ready)*` are ALL required; `##` headings and plain bullets are ignored. After this returns, the user needs to: (1) authorize the fleet by running the authorize.sh one-liner it returns (it runs `claude setup-token` for a long-lived token installed on the controller) - agents use the user's existing Claude Max/Pro subscription, NOT an API key. This is a shell command the USER runs in their own terminal; do NOT try to read or push the user's credentials yourself. The controller takes ~7 min to boot, so PREFER to poll get_agent_status until it reports the controller is reachable and present the authorize command only once it's ready - that way the user doesn't run it into a long wait. (The command also waits on its own, showing a live progress counter, so a user who runs it early is fine too.) (2) add well-scoped tasks in the format above to ROADMAP.md; (3) call trigger_agent_batch.

  Paramètres, retour & exemple (3)

  Paramètres

  • repo · string · requis
    GitHub repo to run agents on, e.g. 'owner/my-app'. Must be accessible with the PAT.
  • github_pat · string · requis
    GitHub Personal Access Token with repo + workflow scopes. Used to clone the repo and open PRs.
  • worker_count · integer · optionnel
    Number of parallel worker VMs (default 3). Each works on a separate task simultaneously.

  Exemple d'appel

  {"name": "setup_agent_fleet", "arguments": {"repo": "texte", "github_pat": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "repo": "texte", "fleet_id": "texte", "ssh_user": "texte", "log_token": "texte", "next_steps": [], "worker_ids": [], "instance_id": "texte", "ssh_key_name": "texte", "trigger_token": "texte", "controller_url": "texte", "controller_host": "texte"}}

• setup_agent_session≈ 262 tokens

  One-shot tool that guides you through the complete agent setup: checks prerequisites, creates the controller VM, and returns next steps. Ideal for first-time setup. Call this when a user says 'set up autocoding agents for my repo'.

  Paramètres, retour & exemple (2)

  Paramètres

  • repo · string · requis
    GitHub repo, e.g. 'owner/repo'
  • github_pat · string · requis
    GitHub Personal Access Token (repo + workflow scopes)

  Exemple d'appel

  {"name": "setup_agent_session", "arguments": {"repo": "texte", "github_pat": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"repo": "texte", "ready": true, "next_tool": "texte"}}

• trigger_agent_batch≈ 368 tokens

  Starts the autonomous agent batch on your controller VM. Agents read agent-ready tasks from your ROADMAP.md, implement them in parallel, and open PRs. No VPN needed - runs over HTTPS; the controller stays running after you disconnect. Each ROADMAP task MUST be a single checkbox line `- [ ] **Title** - short description *(agent-ready)*` (the `- [ ]`, `**bold title**`, and `*(agent-ready)*` are all required; `##` headings and plain bullets are ignored). If this returns 'No agent-ready tasks', the tasks are mis-formatted - fix them to that exact format and retry.

  Paramètres, retour & exemple (2)

  Paramètres

  • trigger_token · string · requis
    Trigger token from the controller
  • controller_url · string · requis
    HTTPS URL of your controller VM

  Exemple d'appel

  {"name": "trigger_agent_batch", "arguments": {"trigger_token": "texte", "controller_url": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"ok": true, "message": "texte", "fleet_id": "texte", "finalize_note": "texte", "workers_ready": true}}

• update_cluster≈ 760 tokens

  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.

  Paramètres, retour & exemple (4)

  Paramètres

  • stack_id · string · requis
    Cluster stack id, from list_clusters (id).
  • stack_name · string · requis
    Cluster stack name, from list_clusters (stack_name).
  • instance_id · string · requis
    The 'hero' VM to snapshot and roll to every extra member: the source/master VM you upgraded to a cluster and SSH into to make changes. It is your cluster's always-on baseline member. Its CURRENT disk state becomes the new member image, so make your changes on it FIRST, then call this.
  • idempotency_key · string · optionnel

  Exemple d'appel

  {"name": "update_cluster", "arguments": {"stack_id": "texte", "stack_name": "texte", "instance_id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• upgrade_to_cluster≈ 3630 tokens

  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 members are ASG-managed and self-healed). If you need always-on redundancy, keep the app under enough load to hold >=1 extra member, or use a separate always-on setup. BILLED - at rest it costs just your source VM (which you already run) plus the load balancer; under load it adds up to max_size EXTRA members at the member flavor (flavor_id), billed only while they run. In guided mode show the cost that way (now: source VM already running + the LB; under load: up to max_size x the member flavor) and get the user's explicit go first. redu automatically repoints the extra members from the old single-VM URL to the load-balancer URL across app config. It REFUSES a STATEFUL VM with 409 cluster_needs_stateless unless confirm_stateless:true. To have redu help with a stateful VM instead of refusing, pass auto_restructure:true: for a single_vm Postgres the fully automatic move is switched off for now (409 auto_restructure_unavailable: move the database yourself first, then confirm_stateless:true); for a compose-stack DB it provisions the matching managed DB (set restructure_engine, e.g. 'mysql'/'mariadb' for WordPress) and returns migration commands to run from the app VM. WordPress/WooCommerce is not generic autoscaling: managed DB alone is not enough because wp-content/uploads is file state. Use app_profile:'wordpress'/'woocommerce', cluster_media_mode:'media_space', and either media_space_id or create_media_space:true so all members mount the same uploads filesystem; otherwise the backend refuses with 409 cluster_needs_media_space. PUT THE CLUSTER ON THE SAME private network as the managed DB and media space. HA: cluster members are spread across DIFFERENT physical hosts automatically, and an autoscaled member that is destroyed is REBUILT AUTOMATICALLY in 1.5 to 5 minutes depending on how it failed with no action from you (the always-on source/hero VM is a plain VM and is NOT covered by that). CRITICAL for members: the app must start on EVERY boot (systemd unit or container restart policy) - if it only starts from a first-boot cloud-init script, a rebooted or resized member comes back with no app, silently never rejoins the load balancer, and the cluster quietly loses capacity with nothing reporting an error. Pass startup_command if the app does not already auto-start on boot, and have it bind its port only once it is genuinely ready to serve (the health check can only see whether the port is open). SEQUENCING - this catches people: the snapshot is taken IMMEDIATELY, and every member boots from it, so the source VM's app must already be RUNNING before you call this. Clustering a freshly-created VM whose cloud-init has not finished captures an image with no enabled service, and all members then come up ACTIVE while failing the load-balancer health check forever - a cluster that looks built and serves nothing. Verify the app answers on its port first (get_ssh_command, or just fetch the VM's URL). The snapshot upload can take several minutes; poll list_clusters until CREATE_COMPLETE.

  Paramètres, retour & exemple (26)

  Paramètres

  • name · string · requis
    Name for the cluster (lowercase letters, numbers, hyphens).
  • port · integer · optionnel
    Port the app listens on / the load balancer forwards to (default 80). Your source VM must actually serve on this port - the load balancer health-checks it.
  • dname · string · optionnel
    Optional public DNS name for the cluster's load-balancer access point (a .redu.cloud name is auto-generated if omitted).
  • max_size · integer · optionnel
    Peak member count under load (default 5). In the default mode this is EXTRA members added on top of your always-on source VM, and the floor is 0 extra. With high_availability:true the group runs between 3 and this number, so set it >= 3.
  • flavor_id · string · requis
    Member VM size - from list_flavors. Every autoscaling member uses this flavor. STRONGLY prefer m1.mem16/m1.mem32 (memory-optimized, 40 GB disk): clustering snapshots the source disk, so a lean disk makes cluster-create and every scale-out several times faster than a 160 GB standard flavor (and costs less for the same RAM). The member flavor's disk must be >= the source VM's disk, so the biggest win comes from the SOURCE VM being on a mem flavor too - if it is on a big-disk flavor, migrate the app onto a mem-flavor VM before clustering. The user can override with any flavor.
  • network_id · string · requis
    Private network id - from list_private_networks. Use the SAME network the app's managed DB / other services are on, so members can reach them by private IP.
  • app_profile · string · optionnel · generic | wordpress | woocommerce
    Set wordpress/woocommerce when upgrading an older deployment or raw VM that the backend has not profiled. WordPress/WooCommerce clusters require managed MySQL/MariaDB plus a media_space or explicitly configured central_media_origin.
  • instance_id · string · requis
    The instance to turn into a cluster (from list_instances, or the VM of a deploy_app/deploy_compose deployment). It is snapshotted, and the autoscaling members are booted from that snapshot.
  • keypair_name · string · requis
    SSH keypair name - from list_keypairs.
  • media_space_id · integer · optionnel
    Existing Redu media space id to mount on every WordPress/WooCommerce cluster member.
  • idempotency_key · string · optionnel
  • startup_command · string · optionnel
    Single-line shell command to (re)start the app on each fresh member if the snapshot's own services do not auto-start it. For a podman-compose app: 'cd /opt/app && podman-compose up -d'. Omit to rely on the image's own auto-starting services.
  • auto_restructure · boolean · optionnel
    Instead of just refusing a stateful VM, have redu get its co-located database OFF the VM first, then cluster. For a single_vm Postgres (redu deployed it) the FULLY AUTOMATIC move is SWITCHED OFF by the platform for now: the call is refused with 409 auto_restructure_unavailable (done automatically it could lose writes in rare cases). Tell the user, then move the database first: create a managed database, copy the data into it, point the app at it and redeploy, then upgrade with confirm_stateless:true. (When it is switched on it needs high_availability:true.) For a compose/unknown DB, ASSISTED: redu provisions the matching managed DB (see restructure_engine) and returns the exact dump/restore/repoint commands to run FROM THE APP VM (response restructure.mode='assisted') - redu will not run an unattended dump against a database it does not own. Only addresses the co-located-DB refusal (cluster_needs_stateless); it does NOT bypass the WordPress media guard. Writes to the OLD VM during the (several-minute) upgrade are not migrated; cut traffic over to the cluster URL once it is up.
  • media_mount_path · string · optionnel
    Host mount path on cluster members. Redu mounts this into /var/www/html/wp-content/uploads for WordPress/WooCommerce.
  • media_origin_url · string · optionnel
    Public base URL where WordPress wp-content/uploads is served from the central media origin. This should be a separate media origin, not the DB VM.
  • media_space_name · string · optionnel
    Optional name for the media space when create_media_space:true. Defaults to <cluster-name>-media.
  • confirm_stateless · boolean · optionnel
    Override the stateful-VM safety refusal. redu REFUSES to cluster a VM that holds its own data (deployed with database:'single_vm' or a compose 'db' service) - a cluster clones the VM into members, so on-VM data diverges and is lost on scale-in; it returns 409 cluster_needs_stateless + a restructure_plan (move the DB to managed, repoint, redeploy, then cluster). Set true ONLY when the VM is genuinely stateless (state in a managed DB / external store, e.g. database:'managed'), or a raw VM you have made stateless.
  • high_availability · boolean · optionnel
    Set TRUE whenever the user asks for HIGH AVAILABILITY, redundancy, 'no single point of failure', 'survive a host/node failure', or 'stay up if a VM dies'. This is the ONLY way to get an HA cluster and you should pick it yourself when the user's intent is availability rather than load-scaling - do not make them discover it. It runs 3 permanent members spread across 3 DIFFERENT physical hosts; a member that is destroyed is rebuilt AUTOMATICALLY in 1.5 to 5 minutes depending on how it failed (both ends measured), with no action from anyone; updates roll one member at a time, keeping the cluster serving throughout (measured: about 2% of requests blip as each member is swapped, capacity never below 2 of 3, URL unchanged). Trade-off to state in the plan: 3 members run continuously (so 3x the member cost, versus 0 idle members in the default mode), and the source VM is retired once every member passes the load balancer's health check and no other web address (a custom domain, another port) still points at it; otherwise, or if the cluster is deleted meanwhile, it is kept serving, still billed, and the user is told why. Default false = load-scaling mode: the single source VM serves at rest and is NOT auto-replaced if it dies.
  • cluster_media_mode · string · optionnel · local_uploads | central_media_origin | media_space
    For WordPress/WooCommerce, use media_space as the default real cluster fix. local_uploads is refused because wp-content/uploads would diverge across members.
  • create_media_space · boolean · optionnel
    Set TRUE when upgrading a WordPress/WooCommerce deployment that has no media_space_id yet. Redu creates a small NFS media VM + volume, records it, and mounts it on all members.
  • restructure_engine · string · optionnel · postgres | mysql | mariadb
    For the ASSISTED path (a compose-stack database), which managed engine to provision. WordPress/WooCommerce = 'mysql' (or 'mariadb'). Required when auto_restructure is set and the DB runs inside the compose stack; ignored for a single_vm Postgres (always Postgres).
  • scale_in_threshold · number · optionnel
    Average CPU fraction (0-1) below which a member is removed (default 0.2).
  • media_space_size_gb · integer · optionnel
    Media space data volume size in GB when create_media_space:true (default 20).
  • scale_out_threshold · number · optionnel
    Average CPU fraction (0-1) above which a member is added (default 0.7).
  • media_space_flavor_id · string · optionnel
    Flavor id for the media VM when create_media_space:true. Defaults to the cluster member flavor.
  • restructure_db_flavor_id · string · optionnel
    Optional VM size for the provisioned managed database (from list_flavors). Defaults to the member flavor; pick a smaller one (e.g. m1.small) if the DB is light.

  Exemple d'appel

  {"name": "upgrade_to_cluster", "arguments": {"name": "texte", "flavor_id": "texte", "network_id": "texte", "instance_id": "texte", "keypair_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte", "machine": "texte", "request": "texte", "duplicate": true, "plan_tool": "texte", "needs_plan": true, "validation": "texte", "needs_keypair": true, "idempotency_key": "texte"}}

• upgrade_to_ha≈ 1216 tokens

  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 table and no error. If their app ships plain-MergeTree migrations (Plausible, PostHog and Langfuse all do), those migrations will fail after the upgrade and they should stay on the single machine. For the app tier rather than the database, use upgrade_to_cluster instead.

  Paramètres, retour & exemple (6)

  Paramètres

  • id · ? · requis
    Numeric id of the EXISTING single-machine database (from list_databases / list_clickhouse_databases). It must be status='ready'.
  • service · string · requis · postgres | clickhouse
    Which managed database type the id belongs to. 'postgres' for one from create_database/list_databases; 'clickhouse' for one from create_clickhouse/list_clickhouse_databases. MySQL, MariaDB, Redis and Qdrant have no HA option and this tool cannot make them highly available.
  • flavor_id · string · optionnel
    Only needed for an old database whose build settings were not recorded; the API says so if it is missing. Otherwise the cluster reuses the machine size the database already has.
  • network_id · string · optionnel
    Only needed for an old database whose build settings were not recorded. Otherwise the cluster joins the same private network.
  • keypair_name · string · optionnel
    Only needed for an old database whose build settings were not recorded.
  • acknowledge_write_loss · boolean · optionnel
    REQUIRED, and you must tell the user this in your own words and get a yes BEFORE you set it true. The upgrade copies the data while the old machine is still serving, so anything the application writes to the old machine AFTER the copy starts, and before you repoint the app at the new address, is NOT copied and cannot be recovered afterwards. This was measured on a real upgrade: one row written mid-copy was missing (5001 rows on the old machine, 5000 on the cluster). For a quiet database that is nothing; for one taking live orders it is lost orders. The safe sequence is: pause or drain writes, upgrade, repoint the app at the new address, resume. Never set this true on the user's behalf to be helpful.

  Exemple d'appel

  {"name": "upgrade_to_ha", "arguments": {"id": "texte", "service": "postgres"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "error": true, "result": "texte"}}

• verify_deployment≈ 414 tokens

  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.

  Paramètres, retour & exemple (1)

  Paramètres

  • id · integer · requis
    Deployment id from list_deployments.

  Exemple d'appel

  {"name": "verify_deployment", "arguments": {"id": 1}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": 1, "next": "texte", "probe": "texte", "status": "texte", "changed": true, "message": "texte", "ready_at": "texte", "ready_signal": "texte", "previous_status": "texte"}}

• verify_domain≈ 392 tokens

  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.

  Paramètres, retour & exemple (1)

  Paramètres

  • domain · string · requis
    The custom domain to verify ownership of (e.g. app.example.com).

  Exemple d'appel

  {"name": "verify_domain", "arguments": {"domain": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"mode": "texte", "next": "texte", "domain": "texte", "result": "texte", "status": "texte", "verified": true, "verified_at": "texte"}}

• wait_for_deployment≈ 518 tokens

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

  Paramètres, retour & exemple (2)

  Paramètres

  • id · integer · requis
    Deployment id, from the deploy call or list_deployments.
  • timeout_s · integer · optionnel
    Seconds to wait in this call before returning timed_out:true: at most 50 (the default); a larger value waits 50, because an MCP client cuts a call at about 60 s (ROADMAP 7). Call again until it is terminal.

  Exemple d'appel

  {"name": "wait_for_deployment", "arguments": {"id": 1}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"next": "texte", "note": "texte", "evidence": "texte", "terminal": true, "timed_out": true, "deployment": "texte", "waited_seconds": 1}}

• whoami≈ 177 tokens

  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.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "whoami", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"next": "texte", "user": "texte", "quota": "texte", "verified": true, "auth_type": "texte"}}

C'est votre serveur ?

Revendiquez-le sur l'espace créateur (preuve GitHub, domaine ou npm) pour afficher le badge « propriétaire vérifié » et lancer un pentest comportemental à la demande afin d'obtenir le badge « Vérifié ».

Créer un compte / revendiquer →

Source

https://mcp.redu.cloud/mcp