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.